If you download the code package for this chapter, you will find three projects that illustrate the use of the Marmalade functionality we have learnt about in this chapter.
The ITX project demonstrates use of the ITX text parser and the CIwManaged class.
The example first creates custom instances of our own class by parsing an ITX file, then serializes those instances out to a file. All the instances are then destroyed and re-created by loading the serialized file back in.
The example also demonstrates the use of two more parts of the IwUtil API, which we haven't covered in depth, but are very useful to know about. First is the class CIwManagedList, which is used for maintaining a list of objects derived from CIwManaged, and the second is the IwTrace system that allows us to log information to a file (and to the standard output) in order to aid debugging.
The Graphics2D project pulls everything we've learnt in this chapter together to render a rotating, textured polygon on screen. The following screenshot depicts this project in action:
Throughout this book, we will be building up an entire game example that puts the things we have learnt into real practice. The game in question will be a simple version of that old favorite, the slalom skiing game, where the player guides a skier down a mountain, attempting to pass through as many flags as possible while avoiding obstacles.
In this chapter we kick things off by having a skier graphic at the top of the screen that moves from side to side, while some random trees scroll up the edges of the screen.
The following screenshot shows the project as it currently stands:
While this book is not intended to teach you the ins and outs of programming a game (it's assumed you already know how to do that) it might still be worthwhile providing a few notes on how the sample game is put together.
The GameObject class is the base class for anything that makes up a part of the game world. Currently there are two classes which inherit from this class, Skier and Tree. No prizes for guessing what they represent!
GameObject provides two virtual methods that can be overridden by child classes to implement the behavior of an in-game object. The GameObject::Update method provides support for changing the position of an object by applying a velocity to it, while the GameObject::Render method allows a size and a material to be defined, and it will draw a textured polygon at the object's current position using this information.
The main flow of most games is often represented internally as some kind of state machine. Even the simplest game will normally have at least a title screen and the main game screen, but add to this things such as pause modes, high score tables, options screen, and the like, and you soon end up with a large number of states that your game could be in.
Often these states are completely mutually exclusive, but sometimes we might want several states active, or at least visible, at the same time. For example, quite often the pause mode will appear on top of the game screen. Only the pause mode will be accepting input, but both it and the game screen need to be drawn.
One approach (and this is purely my own personal preference; your own may vary wildly) is to create a separate class which handles a single part of the game. For want of a better word, I represent these using a base class called Mode.
The Mode class is similar to the GameObject class in that it provides two virtual methods called Update and Render. A mode can be made active, which means its Update method will be executed in each frame, and it can be visible, which means its Render method will be called. These two states are completely independent of each other.
When a Mode instance is created, it is automatically added to a list maintained by a singleton class called ModeManager. The ModeManager class uses the list of Mode instances to update all active modes and render all visible modes on each iteration of the main game loop.
Currently the project only consists of a single mode called ModeGame, which is responsible for loading and freeing the required resources and also initializing, updating, and rendering all the GameObjects that make up the game world.