Summary of "Best Code Architectures For Indie Games"

Summary of "Best Code Architectures For indie games"

Key Points on Game Code Architecture

Reality of Indie Game Code: Most indie games are built on "spaghetti code" — messy, tangled code that works but is hard to manage. This is common and acceptable if the game functions well.
Reusable Code Modules:
- Create isolated, reusable systems (e.g., player movement, health, enemy spawner).
- These systems should be independent, low complexity, and reusable across projects.
- Example: In the game Thronefall, an "auto attack" script is reused by many objects (units, buildings, enemies).
Avoid Direct Cross-References Between Systems:
- Systems should not hold direct references to each other (e.g., health system referencing movement system and vice versa).
- Instead, use "glue code" or engine features (Unity events, exposed fields) to connect systems without tight coupling.
- Glue code can be scripts or game managers dedicated to connecting systems but not reused elsewhere.
Glue Code and game managers:
- About 70% of your code can be reusable modules ("Lego bricks"), and 30% glue code to tie them together.
- Glue code often includes multiple small, specialized game managers rather than one large monolithic manager.
- Example: Thronefall uses around 30 small game managers, each handling specific tasks (enemy manager, day-night cycle manager, etc.).
Combining Systems When Necessary: If two systems need to reference each other heavily (e.g., health and attack), combine them into one system to avoid tangled dependencies.
Design for Reuse: Write systems as if you will reuse them in future projects, even if you don’t. This encourages modularity and tidiness.

Data Management

Separate Code and Data: Keep gameplay data (especially immutable data like balancing parameters, translations) separate from code. Store data in centralized databases or spreadsheet-like structures (can be scriptable objects or engine-specific equivalents). Avoid scattering data across multiple locations to improve usability and maintainability.
Benefits of Organized Data:
- Easier for game designers to tweak and balance the game.
- Facilitates modding and content expansion.
- Example: Translations should never be hardcoded but stored in external data structures.
Design Data Structures First: Sometimes start by designing the database and data layout before coding game systems. This ensures a clean, well-thought-out data architecture.

Managing Time and Execution Order

Time as an Unavoidable "Spaghetti": All systems depend on time (update cycles, execution order). Poorly managed execution order leads to messy and unpredictable behavior.
Control Execution Order Explicitly: Use a central script to call update events in a controlled sequence. Avoid relying on random or default engine execution orders, especially for gameplay-critical code.
Be Cautious with Events: Events can cause unpredictable execution order; fine for visuals but less ideal for gameplay logic.

Separating Gameplay and Visuals

Simulation vs. View Architecture: Treat the game simulation (game state, logic) as separate from the visual representation (rendering, animations). The view observes the simulation as a real-time database, pulling current state to render. The simulation is independent and unaware of the view.
Benefits:
- Easier to manage and debug.
- Allows swapping or upgrading visual systems without touching gameplay logic.
- Both simulation and view have their own glue code and data sets (e.g., gameplay data vs. animation data).