Code systems are code systems. Good code architecture tends to follow pretty universal principles, regardless of whether the system is governing loot tables or lighting systems. Constructing software systems is about seeing the general rules at work and using those to write code that adheres to those rules.
It really helps to take a larger view of what a game is from a software engineering perspective. A game (or any major piece of software) is a bunch of systems comprised of smaller subsystems, and how those individual systems interact with each other. All code systems all need to do three things:
- Determine when the system needs to do its work
- Return the processed results from that internal work to external systems that need those results to do their own work
- Do their own internal work to process and handle requests correctly
When planning out what a system will do, it helps to divvy up the work into these three buckets. Once you know what the system needs to do, the engineer can break down the individual functions and data members she'll need in order to actually do that work.
Let's move forward with an example - say that I wanted to build a stealth takedown system in my action adventure game. The design document says that I want the player to be behind an unaware enemy, press a button, and then play a paired animation that kills the enemy. Using the three buckets mentioned previously, let's break it down.
When does the system need to do its work?
- Player and enemy position
- Player and enemy facing direction
- Enemy awareness state
- Game controller input state
What results do I need to provide?
- I need to know when the player meets the conditions of being behind and facing an unaware enemy (call the UI system to show the button prompt)
- I need to call the animation system to play the animations on the player and the enemy (call the animation system to play the animation)
- I need to kill the enemy (call the damage system to kill the enemy)
What do I need to do the internal work to provide those results?
- I need to calculate whether the player is behind the enemy
- I need to calculate whether the player is facing the enemy
- I need to determine whether the enemy is aware of the player
- I need to know when the player presses the attack button
As each of these elements is built and works, we can use them to interact with each other. Logical checks like whether the player is behind the enemy will determine whether the action can be taken. Actions like performing the takedown animations are then attached to the conditions. These combine to form the rules from the designer and a system is born.
[Join us on Discord] and/or [Support us on Patreon]
Got a burning question you want answered?
- Short questions: Ask a Game Dev on Twitter
- Short questions: Ask a Game Dev on BlueSky
- Long questions: Ask a Game Dev on Tumblr
- Frequent Questions: The FAQ