Game Systems Interaction Design

Question

Intro

I'm writing an FPS game in c++. There is a timed game mode, players run around a map shoot from a variety of weapons which are either hitscan or projectile based, when a shot connects, based on information about the game state players are assigned points, when the time is up the player with the most points wins.

I am currently working on the client side, where we use opengl for graphics, glfw for input and window, and other libraries for physics and sound. In each of the designs I've thought about there are always systems: Graphics, Input, Physics, Sound, Gameplay which store their own state and can be interacted with through methods they expose.

Design 1

In this approach in int main() { ... } we initialize the systems and store them in variables which reference the respective systems, whenever a function is called which needs a certain system we pass it in as an argument.

For example, we have character.update_velocity(delta_time, Input, Sound) and then inside we have the input object is needed to be passed into this call because we check Input.forward_pressed etc... in order to change their velocity depending on what keys are pressed. if (Input.jump_pressed) { Sound.play_sound("jump") ... }.

Apparent Benefit: You're focusing on telling the computer on what to do to make the game happen rather than other things.

Apparent Downside: Your function signatures get cluttered with systems. You need to work around callbacks with fixed signatures because you can't pass systems directly as parameters into them.

Design 2

We use the same approach, but instead of passing the systems that are needed to specific function calls, we instead make each of the systems global which means that the functions don't need to take them in as arguments, but the code inside these functions stays the same as design 1.

Apparent Benefit: The signature of functions is not cluttered by a bunch of systems. Fixes the callback thing mentioned in Design 1.

Apparent Downside: It's not immediately obvious what systems a function call will use by looking at its signature

Design 3

In this design we use an event system to separate concerns. Now instead of passing in the systems into the respective function calls that need them, the function calls emit signals which then call the code. There is a class called SignalMediator which contains all of the systems and then sends signals to respective systems whenever certain events get triggered.

For example, we have character.update_velocity(delta_time, Input) when a jump occurs we call SignalMediator.emit_signal("jump_occurred") now the Sound object subscribes to the SignalMediator's jump_occurred signal and defines what should occur when this happens.

Apparent Benefits: Our code becomes easier to read because separate functions only interact with a single system at once.

Apparent Downside: The code that makes the game happen is now spread out over more files so it's harder to see all of the functionality at once

Question

I've started writing the game following design 1, but I'm heavily considering design 3 and I've frozen myself up because I'm not sure how design 1 will scale over time as opposed to design 3. I'm also curious if any of the designs I've listed have performance overheads that I'm not considering.

If anyone has insight into these designs or other designs that keep performance, code complexity and maintainability in mind could you share your experiences?

Answer 1

What strikes me first when reading your question is that a character object seems to require a direct dependency to the Input system. This applies to all three of your design alternatives and looks wrong to me (ok, "wrong" is surely opinionated, lets say it would not be my first design choice).

I think it is unlikely a character object in a game needs to know the player uses a keyboard to control it, and which keys will make it "move forward" - that is not it's concern, that's too much knowledge about the technical environment. This kind of dependency also makes it hard to unit test the methods of the character, since you cannot test it without an Input system (or at least a more-or-less complex mock for it).

Note this is not just an issue of "function signatures", it is an issue of dependencies. The issue stays the same in design #1 or #2. The function signatures are just a symptom of the desease. Worse, design #2 will hide these symptoms, but not eliminate the cause - the dependency stays the same, but is actually harder to spot.

So design #3 - using events - is clearly a step into the right direction. It already eliminates the dependency from the Sound system, which is almost the same like the issue with the Input system.

I would, however, recommend to go a step further:

• the Input system should emit signals whenever something like a "key pressed" event occurs

• there could be a middle man object like a "KeyProcessor" (or maybe a "GameMoveController") which subscribes to these events and translates technical key-press events to domain actions. This could include picking the right character object from whereever the character objects are stored in your program, and then calling methods which tell the character how to change their state.

  Of course, your character objects may provide high-level methods for moving forward or jumping, which may cause a complex internal state update. Still I would avoid those methods to depend directly on some Input object, which may contain 150 other methods or properties from which the character will only need 3 or 4.

This is just a start (and not the only possibility to design such a system), but I hope you get the general idea. Try to narrow down the dependencies, which are caused not just by the parameter lists of functions, but also by global dependencies. Your design #3 is a first step into the right direction, but don't stop with that.

(Regarding performance: as we have written this in more than hundred other questions: don't think too much of it as long as you don't observe any real, measurable performance problems. It is unlikely any of the suggested alternatives will have a noteable impact on this).

Answer 2

Design 3 is very popular, however there is an obvious missing design in your list. OOP.

With OOP you could inject the sound system into your Character object on construction and keep your method parameters clean.

Design 3, the mediator pattern is popular because most games are written for an engine framework. The framework provides a generic way of scripting objects in the game, but this also limits how the objects can interact. Using a mediator gets around that limitation. So you can keep your scripting simple.

A mediator doesn't give you the same compile time help with your method signatures as a direct function call would. Say you need to pass the position of the sound, and maybe some other parameters when the sound is played. this means you need to pass some event object to the mediator with that data in and you won't get compile time checks that you have sent a everything you need.

I think you need a mix of both. Events can help with all sorts of simple problems, "give a bonus when you have shot ten people!", "stop the game after three flag captures", more complex stuff that everything uses, like sounds, can benefit from an injected dependency with a compile time checked interface