There are some game engine mechanisms that are needed in almost any game, and this article will cover exactly that. As I stated in the last article, the work on this common set of features started before we even knew what game we were making. While I have worked on large chunks of a
complex system, this was my first time as a lead programmer and building an engine from scratch. So I consulted my favourite books, adapted some ideas from there to fit our needs and was ready to start.
At the very low level we were free from having to develop a memory management system, as we used C# and could let the garbage collection take care of that. Sometimes however the garbage collection can cause hiccups, so special care need to taken. The garbage collection runs fastest when it doesn't run at all, so we had almost no dynamic memory allocation after a level has been loaded. On way we tried to enforce this was to have our low level stuff like math, physics, collisions, render jobs and such as value types. Declaring a structure (struct) instead of a class in C# is not enough, as the garbage collection is a
bit more complicated and sophisticated than that, so we made sure that variables are statically scoped whenever possible. Additionally, we passed by reference all bigger structures to avoid copying memory around.
XNA is mostly a 3D rendering framework, so The 2D math that is part of the framework was in my opinion not a good match to what we needed for game. So, we implemented a 2D vector and a matrix class, as well as some helper methods for transformations. These can be lifted from any book in the field. Because we didn't do much rigid body physics or angular interpolation, there was no special class for rotations. In future I would prefer to use
spinors (2D equivalent of
quaternions) or complex numbers for the purpose.
The game structure itself was kept very simple. Everything in the game was derived from
GameEntity and all the entities were kept in the
GameWorld. The game world had no hierarchy, just a list of level of entities. What follows is a piece of code from the
GameWorld class and BaseGameEntity class that I will elaborate on.
// Gameworld.cs
public class GameWorld
{
// some code ...
// All the entities in the world
public List<BaseGameEntity> Entities
{ get; set; }
// Adds an entity to the world. This can be anything.
public void AddEntity(BaseGameEntity entity)
{
AddQueue.Add(entity);
}
// Removes an entity from the world
public void RemoveEntity(BaseGameEntity entity)
{
RemoveQueue.Add(entity);
}
public void Update(float dt)
{
// Add entities
foreach (BaseGameEntity bge in AddQueue)
Entities.Add(bge);
AddQueue.Clear();
// Update entities
foreach (BaseGameEntity bge in Entities)
if(bge != null)
bge.Update(dt);
// Remove entities
foreach (BaseGameEntity bge in RemoveQueue)
{
// Call cleanup on the entity
if (bge is IDisposable)
(bge as IDisposable).Dispose();
Entities.Remove(bge);
}
}
// more code ...
}
// BaseGameEntity.cs
[Serializable()]
public class BaseGameEntity
{
// Refence to the world
protected GameWorld world;
// Unique ID of the enitity.
[XmlAttribute]
public int ID
{
set {
this.id = value;
// Make sure their are unique
if (id >= nextValidID)
nextValidID = id + 1;
}
get { return id; }
}
//each entity has a unique ID
private int id;
// Every entity has a type associated with it (health, troll, ammo etc)
public EntityType Type
{ get; set; }
// Called when loaded
public virtual void Initialize(GameWorld gameworld)
{
// init code ...
}
// some code ...
}
The flat structure and very simple sequential update are not very flexible, an interactive character on a moving platform might be difficult to implement for example, but was sufficient for our needs. Additionally this approach can be memory coherent, which is very good for cache, which is very important performance. The update method of each entity handles everything from physics and game-play to animation. I opted for simple floating point time in seconds as parameter instead of the XNA's GameTime structure as I it doesn't require every class to calculate time, which can bring inconsistencies, and it allows for easy time manipulation like bullet time or pause. So that there is no inconsistency during the execution of a single world update, entities could only be added and removed at the begging and end of it. Queues of such entities are kept for this reason.
From the piece of code from the BaseGameEntity class we can see few things.
- Every entity has a reference to the game world and that is how it communicates with other entities and can be aware of its soundings.
- A unique ID is kept to help identify the entities. This ID is persistent and stored in the level.
- We have a game entity type for different things in the level, mostly used for game-play and collisions. This is different from the .NET object type, as there can be many different enemies but they are all of the same class.
- We are using the .NET framework XML serializing support for writing and reading data, so our executable classes are also our data containers. This can be seen from the many annotations throughout the code.
This last bullet point was not all that straight forward to implement as it may seem. Firstly, the game scene has a general graph structure, while an XML file has a hierarchical structure and cannot represent the scene properly. Secondly, when reading an object from an XML file, the no arguments constructor is always called. These are remedied by calling an initialization method on all entities after streaming, that has a similar role to a constructor. For cross-reference unique entity IDs are stored in the XML and during the initialization references to the actual objects are obtained by querying the world.
When a level grows to contain couple of hundred entities, it's obvious that you would like to change properties in bulk, and that is where a settings file comes in. This is just another XML file which can be referenced by an entity. We decided settings to be strongly typed so settings for a jelly are different from settings for a blow fish even if the contents are the same. Settings are implemented as simple classes so they can be inherited when needed. So if a MovingEntity extends BaseGameEntity, MovinEntitySettings can extend BaseGameSettings, simplifying the maintenance. The settings are applied in the Initialize method and all entities have a GetSettings and SaveSettings methods. The classes extending the entity class must handle all the details of saving the settings, as it's the only class that knows the type of the settings class. This approach puts a bit of extra work for every type that needs to have settings, but it's flexible and can even allow for structured settings, like a blowfish settings having different sprite settings for all the animations.
These settings files might need to be read frequently during the game, as each created rocket or a bullet might need their settings for example. Reading from disk can do some bad hiccups and there is the added slowdown of parsing the file, allocating memory. For this purpose we cache the settings, which a usually very small data structures and more over, are shared among entities with the same settings. We simply use the file name as a key in a dictionary. The same caching is in fact used for all resources to avoid duplicate data in the game. Our resource manager handles this internally, so it's completely transparent for the rest of the code.
There is always room for improvement, so I'll mention few things. For a future project I might opt for a different streaming solution or make macros that do most of the tedious work for me, but the overall performance and flexibility during the development was quite good. We had a inconsistent way of using the entity types, which lead to some funky bugs. A more structured update method that can handle different priorities and different logical steps might also be beneficial.
The next article will be on tools and the world editor.
