16:10
Best Code Architectures For Indie Games
Jonas Tyroller
Overview
This video discusses effective code architectures for indie game development, moving beyond the common "spaghetti code" to create more maintainable and scalable projects. It emphasizes building reusable modules, using "glue code" to connect them without tight coupling, and separating game data from game logic. The presenter advocates for designing systems with future reusability in mind, organizing data logically, and carefully managing script execution order, especially the "time spaghetti." A key advanced technique is separating gameplay simulation from visual presentation to further enhance modularity and ease of development. The core message is that while "if it works, it works" is acceptable for small projects, adopting these architectural principles leads to cleaner, more efficient, and easier-to-manage codebases, ultimately saving time and effort in the long run.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- Most indie games suffer from "spaghetti code," which is disorganized and difficult to manage.
- While "if it works, it works" is a valid approach for small projects, it hinders long-term development and scalability.
- The goal is to move towards more structured and maintainable code architectures.
Understanding the pitfalls of spaghetti code helps developers recognize the need for better architectural practices from the outset.
The "spaghetti code" analogy itself, where interconnected code is like a messy plate of spaghetti that's hard to untangle.
- Create highly reusable code modules (e.g., an object spawner) that can be used across projects.
- Isolate systems (like player movement, health) so they are independent and can be easily replaced or modified.
- Use "glue code" or in-engine mechanisms (like Unity events or exposed fields) to connect these independent systems, avoiding direct, tight coupling.
- Some systems, like health and attack, are so intertwined they should be combined into a single system.
Reusable modules and well-defined connections reduce redundancy, improve code quality, and make it easier to manage complexity as the game grows.
In Thronefall, an "auto attack" script is reused for all attacking entities (enemies, player units, buildings), simplifying changes and additions.
- Keep immutable game data (balancing, translations) separate from mutable code logic (object positions, speeds).
- Organize data in a centralized, accessible format like spreadsheets or scriptable objects for easier management and updates.
- This separation makes data easier to modify, expand, and allows for better modding support.
- Consider designing the data structure first, then building code systems on top of it.
Organized data leads to happier game designers, faster iteration, and a more accessible game for players and modders.
Storing all game text in a spreadsheet for easy translation, rather than hardcoding it directly into the game's code.
- Time is an unavoidable spaghetti element, as all scripts execute based on time.
- Default execution orders in game engines can lead to unpredictable behavior and complexity.
- Tightly control script execution order using a dedicated manager script to ensure predictable updates and avoid gameplay bugs.
- Avoid relying heavily on events for gameplay-critical logic due to their unpredictable execution order.
Controlling execution order prevents subtle bugs and makes complex game logic more predictable and easier to debug.
A single script that explicitly calls update functions for other systems in a specific, desired sequence.
- Divide the game into two main parts: the simulation (gameplay logic and data) and the view (visual presentation).
- The simulation operates independently, unaware of the view, and the view simply renders the current state of the simulation.
- This separation allows for easier replacement of either the simulation or the view, and breaks down systems into smaller, focused pieces.
- Gameplay systems handle logic, while visual systems handle rendering, animations, and meshes, with their own respective data.
This advanced technique creates highly modular and clean code by ensuring systems are solely responsible for either gameplay logic or visual representation.
The simulation tracks an object's position, and the view component then reads that position to draw the object on screen, without the simulation needing to know about the drawing.
Key takeaways
- Prioritize creating reusable code modules to build a library of game development assets.
- Connect independent systems using 'glue code' or engine features to maintain modularity and avoid tight coupling.
- Separate game data from game logic to improve organization, iteration speed, and moddability.
- Actively manage script execution order to prevent bugs and ensure predictable game behavior.
- Consider separating the gameplay simulation from the visual presentation for enhanced modularity.
- Even if systems aren't reused in future projects, designing them for reusability leads to cleaner code.
- The ultimate goal is to reduce complexity and make games easier to manage, debug, and expand.
Key terms
Spaghetti CodeReusable ModulesIsolated SystemsGlue CodeTight CouplingImmutable DataMutable DataScriptable ObjectsExecution OrderSimulationView
Test your understanding
- What is the primary drawback of "spaghetti code" in game development?
- How can "glue code" help in connecting independent game systems?
- Why is it beneficial to separate game data from game logic?
- What does the term "time spaghetti" refer to, and how can it be managed?
- What are the two main components when separating gameplay simulation from visuals, and what is the role of each?