Let’s start with some design discussion. Possibly the most useful thing you can do with your game engine is modularize it. This means that you have a separate class for each “thing” you will have in the game. For example, you will have a terrain class that only works with terrain, and a sky class that only works with the sky. You can then add and remove these components from the scene at will.

These components should be built off of a base class that the engine knows how to work with. For example, we will have a base class called “Component” which provides all the functionality a component needs to exist in the scene and interact with the engine, editor, game, and player. Each component we build will inherit from this class so that they in turn will already be set up to work with the engine.

This can be compared to XNA’s “Game” class; it provides you with all the functionality you could need to build a game: the ability to get content, input, etc. as well as to update and draw your game. XNA knows when to call those functions and your game just has to fill in that functionality. Our components will work similarly. They will have Update and Draw functions that the engine will call when it needs the component to do those things. It will also provide access to some of the engine’s helper classes: the content manager, service container, etc.

This is a common practice in computer science called “abstraction”. We are separating the functionality of the components and the engine through a “layer of abstraction”. The Component class is the interface between the two layers; providing access to the limited functionality we want the components to be able to see. This is good design practice, as it helps keep code organized and easy to understand. It also makes it very easy to add functionality to the engine, simply by creating a new component that derives from the Component class.

Abstraction in the Innovation Engine

The actual design of the engine will be slightly more complicated. We will have the Engine class, which will keep track of all the components and a few services. Those services are the GraphicsDevice (which works with the graphics card), ContentManager (which allows the game to load content like models and textures), SpriteBatch (which handles all of the 2D drawing), and ServiceContainer (which provides access to certain services to all components, for example: a Camera to draw with). There are a few other services which are listed in the diagram below but we won’t talk about them until later in this section.

The Engine class won’t actually track components directly – it will do so through the GameScreen class. The GameScreen basically keeps a list of components that belong on that “screen”. It also keeps track of the order those components should be drawn in, for transparent objects, etc. These GameScreens are meant to be stackable – ie you can have one for the main menu, the game itself on top of that, and the HUD on top. This makes it very easy to pop screens on an off as necessary; to pause the game we just push a pause menu GameScreen onto the top of the stack. To un-pause it, just pop it off again. To quit back to the main menu, just pop off the main game’s GameScreen. These screens can have certain properties like blocking the update of the screens below them – like a pause menu would want to do.

Innovation Engine Structure

In the first chapter of this section, we will start writing the code for the Component class.