I'm building a video game with several distinct modes: normal interaction with the world, using an in-game computer, and entering mini-games such as chess. These modes still need to affect the main world. For example, ordering pizza through the computer should eventually create a delivery in the world, while winning a chess match might award money. A chess piece could even leave the board and become an object the player can pick up or sell.
The player should be able to exit any mode at any time without leaving systems in a broken state. I also need high-priority events, such as the player dying, to interrupt whatever mode is currently active.
What kind of architecture would you use to switch between these modules safely while allowing them to communicate with shared game-world data?
3 Answers
At a high level, this is mostly a combination of state machines and events. Give the overworld and each mini-game their own state controllers, then use a coordinator to activate, pause, resume, or cancel them.
The tricky part is shared resources such as inventory, currency, and quest progress. Those should live outside the individual modules, ideally behind well-defined services. Whether you keep the overworld loaded underneath a mini-game or swap it out depends on memory and performance needs. A stack of active states works well when the underlying world should remain available; loading and unloading modules is better when they are expensive.
A stack-based state machine is a good fit here. Keep the normal world as the base state, then push the computer or chess state on top of it. Exiting a mode simply pops it from the stack, which makes interruption and returning to the previous mode straightforward.
For communication, keep modules decoupled with an event bus or message system. A chess game could emit something like “player earned 500 coins,” while the world or player-data system handles the actual reward. The pizza computer could emit an order event that the world later turns into a delivery.
Keep shared data such as money, inventory, and player stats in a central service with a clear interface. Modules should use that interface rather than modifying unrelated systems directly. Finally, handle events like player death in a small, high-priority interrupt layer that can cancel or clear active states.
Thanks, this gives me several useful ideas to research before I start implementing it.
A plug-in style architecture can work as well. Treat each mode as a self-contained module with a known lifecycle, such as initialize, activate, update, deactivate, and dispose. The central game controller decides which module is active and can stop one cleanly before starting another.
Each module should depend only on shared interfaces, such as an inventory service, economy service, or event dispatcher. That way, replacing or interrupting a module does not require the rest of the game to know its internal details. In Unity with C#, this could be represented with interfaces and a central mode manager.
Is this plug-in approach one of the standard solutions for this kind of problem, or is it mainly useful in certain situations?
I’d also lean toward an event bus. It keeps the mini-games from needing direct references to every system they can affect.