It’s usually the most senior engineers who bring all of this stuff together. They have a good understanding of how the various game systems work and how to build those systems to work within the way the program itself works. Every game system has three major elements in common - whether to do the thing, when to do the thing, and what “do the thing” entails.

Whether to do the thing is the set of conditions under which the thing happens. Each system usually has a set of necessary conditions under which they start - leveling up requires crossing certain XP thresholds, which necessitates checking for things like how much XP the character has and what level he already is.

When to do the thing is how the game handles task performance timing. For example, we probably don’t want a fireball spell to generate a fireball specifically when the player presses the cast button - we want the character to perform a casting animation that ends with a specific pointing animation, and then we want the fireball to appear from the character’s hand when the character points. The animator needs to mark the animation frame at which the fireball appears, and the bone (pointing finger) as the position to make the fireball appear.

What “do the thing” is pretty much handling the event when it happens. Most games usually have some kind of core event system where the game will fire a specific kind of event on a given frame with relevant context (who did it, who the target is, where, any other necessary context, etc.) and event handlers are set up to listen for specific event types, see the event, and do what they are set up to do when that event happens. This can mean “do damage”, “play vfx”, “save the game”, or whatever. Event handlers can also fire off their own sub-events with their own conditions and timings (e.g. “cast a spell” can fire off “play this animation”, which can fire off a “spawn VFX (fireball)” event).

Essentially, the senior engineers that are familiar with how game systems work and interact with each other are the ones who ensure that all of the work plays nicely with how the software is built. It’s kind of like visualizing a flow chart and making sure that each sub-section works the way it should on its own and within the greater context of the overall game flow.

[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
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ