Back to the main site

Game Engine Architecture

Posted on by Malcolm

It’s been awhile since I updated my blog. Truth be told I’ve had enough work to keep me up at night but I’d really like to start making these blogs more regular. Today’s topic is Games Engine Architecture and its aimed at people who have learnt C++ and want to progress onto the next stage: making a game. Making a full game can be a daunting task and, to those who have yet to do their first game, it is easy to get overwhelmed by just how much code even a simple arcade shooter or pong contains. Like anything else, it’s best to build up the foundation knowledge (which, in this case, is learning a language) and work up to what you want to achieve in small steps.


Before you even start coding your first line, you want to be thinking about how you’re going to structure your game in terms of how the actual application is going to work. I’ve been taught to implement a modular, component based approach for several good reasons:

But before I go on, look at this exemplary piece of programmer art:


Game Architecture Diagram


Here is what passes as a diagram showing the concept of what I’m talking about. When you create a game, whether it is Space Invaders or Skyrim, you are creating a world for the player to interact with. This world keeps on turning because of its components. Above are some common components found in every game; other games might have components for a user interface (think of a heads up display [HUD] found in first person shooters such as Call of Duty) or networking for multiplayer games.


So, building on what I’ve gone over so far, each component has a responsibility; it knows what it can do and how it does it. But it’s important to enforce the concept that each component is only aware of what it can do (for example, the graphics/visualisation component only knows how to draw things). Other components may be aware of others, such as the world knowing it can draw things with the graphics component, but it does not know how it draws things. In other words, the world knows the interface of the graphics component but not the implementation. This is why it is easy to replace components; so long as the world sticks to the interface it is given you can, for example, switch your graphics from Direct3D to OpenGL without having to rewrite any of the code in the world.


Here is my implementation of a visualisation component:


Game Architecture Class Diagram


Some things are obvious, like how the Entity (which could be any object in the world) has an x and y position. Other things may not be too obvious. For example, why does the player have an integer variable named ‘m_gfxid’?


Working from the bottom of the diagram; every texture is a sprite. When an entity (such as a player) loads a texture which will represent itself it loads a sprite which stores its texture data. The sprite knows how big it is and how to draw itself (this is where the low-level code will be to actually write the texture data to the screen which the user will see).


Meanwhile the Visualisation component has a vector of these sprites. The reason why the entity had a variable called ‘m_gfxid’ (which I will call ‘graphics id’ from now on) is because the graphics id is the position of the sprite in the CSprite vector of the Visualisation class. The entity will call its DrawEntity() function which will, in turn, call the DrawSprite() function of the Visualisation class. The Visualisation class then finds what sprite needs to be drawn in the vector of CSprites and calls the Blit() function of that CSprite.


With this chain of message passing you don’t have to worry about each entity, or instance of a particular entity, holding its own texture data. Going back to the beginning of this article; you can chop and change the Visualisation or CSprite class as much as you want and, so long as it holds to the interface which the Entity knows about, you can be safe in the knowledge that the Entity class will not require any complicated modifications (if any at all). It is important to note that there should only be one instance of the Visualisation class and it is entirely reasonable to have it as a singleton to enforce this.


So there we have the beginnings of a game engine. Every entity uses the Visualisation component to draw itself which in turn uses the CSprite class to render the texture on to the screen. There’s certainly a lot of work ahead of this but I think that this is a good start.


Hopefully this has been useful. If you are indeed a programmer who has just learnt C++ and you’re looking to work on something like this then perhaps you might find SDL to your liking to act as an intermediary between your game and the hardware.


Thank you for reading; if you’re looking for more distraction on the internets then may I direct you to this website which is reaching the limits of absolute cuteness.


This entry was posted in University Work and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>