I’ve been recently reading about an architecture design strategy for games described in Game Coding Complete 4th Ed. I've been resigned to design a game engine in pure C and I started to try and do it here: SDL and stuff and while I didn't go into much detail, it became clear then and more so now that describing and managing architectures are more suited to an object orientated language like C++. So I've started piecing what my C++ code will need to represent. Here is an architecture that really shines in an object orientated world mostly because it uses some well-known patterns from OOP.

It's very much like MVC if you're familiar with this pattern. I’m very much interested in system architecture and when I have the opportunity to design and see these architectures in play, it fills me with child-like glee. No seriously, it does!

Anyway, here is a drawing I put together to demonstrate the simplicity of an MVC-like architecture:


Game engine architecture

The main crux of this model is two-fold:

  1. It is separated into one set of view components which are both event consumers and command producers.
  2. Events occur in the game logic when world state change occurs.
  3. Commands are instructions from views to the game logic.

This has a few powerful results. Firstly, you have de-coupled the game logic with the views: Views speak Commands and Game logic understands commands. Many different views that speak commands can interact with the game logic in a uniform way without themselves manipulating game logic code. Simply put, The command system is an interface to the game logic. Particularly when coming from views and going to the game logic. Events that occur in the game logic trickle up to the consumers of these events, which are the views. So that going from the game logic to the view, whereas the commands go from the views to the game logic.

The 3 boxes above represent the 3 layers, much like layers in the layer pattern. They layers talk to each other view commands and events such that the layers are coupled to the event/command bus/channel so that the components within the layers don’t talk directly to other components in other layers(no coupling).

Some obvious links in the picture are that the script interpreter like the views communicates with the game logic through the commands mechanism. So hooking up a scripting language into the game engine that issues commands works with the same commands the other views would (AI view and the Human views).

State changes to game objects emit event triggers and event subscribers/consumers get those events and can deal with them.

This is a nice decoupled system which simplifies coordination and communication. This is quite important as games are real-time, multithreaded systems much like an OS kernel that doesn’t inherently have a logical flow of execution that one can follow or reason about easily.

I’d like to talk a little about the Command Interpreter in the Game logic as it gets hot being the central point of communication between it and other layers, particularly the game views and the script interpreter.

The script Interpreter would read tokens from the script its given and translate the tokens into commands like this:

if(command == Fire):
    gameLogicLayer.ProcessFireCommand() 

 which in turn would call the firing logic which would no doubt raise some events with the event manager and those events would get to the game view which would then depict shooting of say a weapon graphically as well as sending a sound to the speakers.

Next time I'll talk a little more about the various layers and components and their interactions that make up the layers.


Comments powered by CComment