2025
Arcade
A C++ gaming platform loading games and graphics libraries dynamically at runtime, with nCurses, SDL2, and a third graphics backend.
- Role
- Developer
- Tags
- game, C++, graphic, system-programming, 2year
- Team
- Noé Caillaud — Developer
- Amos Almacin — Developer

A retro gaming platform written in C++: a core program that loads graphics libraries and games as shared objects at runtime, with zero compile-time dependency on either. Switch renderer, switch game, all without restarting the binary.
The problem
The core arcade program must never know, at compile time, which graphics library or
which games it will run — no linking against SDL2, nCurses, or any game logic directly.
Everything has to be resolved at runtime through dlopen/dlsym, with a single generic
interface that treats every graphics library and every game the same way, so a library
built by a completely different team can be dropped into ./lib/ and just work. On top
of that, ldd on the core binary must show none of these dependencies, and game logic
must stay entirely blind to rendering and low-level input.
What We did
- Designed a generic plugin interface shared identically across all graphics and game
libraries, so the core loop never differentiates between implementations — genuine
polymorphism enforced through
dlopen/dlclose/dlsym/dlerrorrather than C++ virtual dispatch across a binary boundary. - Implemented the nCurses and SDL2 graphics backends as
.soplugins, plus a third backend, each exposing only rendering and input — never touching game state. - Built at least two games (e.g. Snake and Minesweeper) as fully engine-agnostic
.solibraries, with all logic — movement, collisions, scoring — decoupled from any rendering or event-handling code. - Handled runtime library switching, game switching, restart, return-to-menu, and clean exit through a consistent key-mapping layer, plus argument validation and proper error codes (84) on invalid or incompatible libraries.
- Wrote the Makefile with
core,games,graphicals,re,clean, andfcleanrules to build the core binary and every plugin independently. - Documented the plugin architecture so external teams could implement compatible graphics or game libraries, and validated real interoperability by swapping libraries with another group's launcher.
- Pacman Game !
- Snake Game !
- Fire Emblem Game !
- Minesweeper Game !
- Geomtry Dash Game !
- Implemented graphic library : Vulkan, NCURSES, SFML, SDL2
Outcome
A working arcade platform where graphics backends and games are fully interchangeable plugins — proof that a clean dlopen-based plugin boundary can keep rendering, input, and game logic completely decoupled while still shipping a smooth, at-runtime-switchable player experience.






