Oldcode Archive

OldCode (Manta-X) July 2017 Roundup

July 2017 Roundup

Wow, it’s been a month already? I’ve not written an update for a while, but it doesn’t mean that activity has stopped on the OldCode / Manta-X project.

Name Change

The last thing I did in July was to change the “internal” branding (namespaces, project names, etc) from “Manta-X” to “OldCode”.

Manta-X was always a code name, and one from the original days of the project (pre-rediscovery & updates, I may add). As a result, it feels ‘old’ in a way that I can’t really relate to anymore. I no longer remember the original premise or idea of the game, and there’s very little left that resembles the excavated piece.

I’ve come to associate this project as being “Old Code”, even though it’s now very different to it was when I unearthed it.

July Recap

Let’s go through the changelog and recap on the main areas of work last month…

Bye Bye 3D

At the start of the month I followed up on my promise and swapped over completely to a sprite-based approach using SDL_Texture. As a result, almost everything ‘3D’ was removed from the game. Models, vertices, OpenGL, the lot.

It took 8 checkins over 2 days to remove 3D and swap to sprites. Not bad, really.

Math Types

I changed how I do my basic ‘Vector’ stuff; removing the other Vertex class and adding templated Vector2<T>, Vector3<T> and Rectangle<T> classes. These are much simpler to work with and can be int or float-based (or any other type, really).

I also trashed my Matrix class as it wasn’t used; when I need matrix maths I’ll create a new one.


Now I’m committed to SDL2, I removed the Win32 filesystem I added to replace PhysFS and replaced it with one based on SDL_RWops. It was crazily simple to do.


I created an eventing system as a standalone git repo hosted (privately, for now) on bitbucket. I integrated this into OldCode and hooked up basic GameObjectSpawned events. It was nice as it let me immediately start decoupling code that was interested in entity spawning.

Level Loading

A big change I made was to make the game initialize entirely from data using a json-based level file. This was great as it allowed me to remove some hard coded stuff from the C++ code.

A result of doing this meant that I re-introduced a archetype or class based system that allowed an entity type to be specified in a json file and then spawned from the class type.

Game Services

I started to bring in the notion of game ‘services’ to work with entities that have specific components. This allowed me to move logic out of components and into services, meaning that my components are now totally data-only.

A result of this is that I now how a generic Ticker system that ticks things that are registered with it.

Game Services aren’t really generic yet, but I can see them evolving that way.

GameObject System

A huge change I made was to remove std::shared_ptr use in my GameObjects. I now have a GameObjectHandle that is basically a weak reference handle to an object. The handle is exchanged for a GameObject by the GameObjectService. By the handle being weak, I can basically despawn stuff and have handles invalidate automatically. The implementation of this is a post in its own right.

Dynamic Spawning

As a result of all this stuff, I changed the way spawning of GameObjects works; objects are created and then spawned - at which point they’re renderable, updatable, etc. Crucially, they can also be despawned now - which means they’re removed from any systems that care about entities. If an object is despawned, any handles pointing to it become invalid, meaning that systems that are interested in them have to discard the handle. Of course, they receive a GameObjectDespawnedEvent to give them an instant notification of this.

Because I can now spawn and despawn entities, I added WeaponFire, which is the player firing bullets. They travel until they exit the level bounds and despawn.

Next Month

That sums up the stuff I did in July (and the start of August). My next goals are:

  • Get collisions implemented. This would let me detect weapon collisions with enemies (and the player) and react to that. The beginnings of a real game will drop out of this.
  • Unit tests. I’ve gone on too long without automated testing and have made some stupid mistakes that tests would pick up. So I’m going to integrate my upptest project and add unit tests around the core systems.
  • Add multiple enemies. Let’s start making a game, not a tech demo.

Until next time.

Manta-X: 2d or bust!

Why 3D is bad for me

The goal of this project was always to make a game. Specifically, to make a top-down, side scrolling shump type of game. The previous old code entries talked about ripping out superflous stuff and pulling the project back to the essence of what 2004 me was trying to achieve.

I started looking into modernizing the codebase to a newer version of OpenGL, one that moves away from immediate mode and into the realm of shaders. I created a new branch called opengl-upd and set to work, ripping out the current stuff and adding in magical things that I was basically learning as I went from a ‘modern’ OpenGL tutorial.

It turns out that for me, someone who hasn’t touched graphics programming of any kind since the late 2000’s the leap is huge. Rendering was broken for a very long time in that branch. Getting a triangle up took a while and I eventually got the (untextured) models loaded and showing - however the camera system was totally screwed.

As part of this update, I realised I’d broken one of my core tenants in this project - that of refactoring - keeping the existing stuff working as I evolved the code. The old rendering system just wasn’t compatible with the newer code so I had a black screen for a long time - something which wasn’t desirable.

Sitting back and reflecting on this I realised that I was spending a lot of time learning OpenGL and not actually progressing with the original goal of having a working game. This was compounded by my lack of 3d tools knowledge (MilkShape 3D is defunct now) and I realised I’d have to learn Blender and other tools. It got me thinking, if I was doing all this - I could just quit and use Unreal or Unity as it has all the 3D features I’d want, for free.

Stripping it back

With this in mind I decided to abandon the OpenGL update branch and go back to something more basic. I want to get some simple game built here, not mess about with tech and tools forever.

Not only am I abandoning ‘modern’ OpenGL, but I’m going to abandon OpenGL entirely in favour of a sprite-based system using SDL2.

Swapping over to sprites allows me to crudely draw my own graphics and render them up relatively quickly, allowing me to focus on building out the game itself instead of worrying about graphics tech.

Implementation Plan

The goal here is to be able to rip out the 3D stuff and swap to sprites without breaking what’s there - thankfully there’s actually very little there right now.

I could approach this in two ways; the first would be to have a combined approach, whereby sprites are rendered alongside the 3D stuff. The second would be to keep them completely separate. I decided that for my own sanity, I’m going to keep the concepts totally separate - I’ll keep the 3d stuff running until the sprite systems are at parity, then I can remove the 3d stuff entirely.

To do this, I’ve implemented a runtime toggle - basically when the game starts up it reads a configuration file and runs in OpenGL mode or SDL (Sprite) mode.

Based on this mode, we now instance either a GLRenderWindow or a SDLRenderWindow. Both of which are entirely separate and deal with their own types of rendering.

We still have a problem, however. A lot of the old code that was ported over to the component system means that components are responsible for rendering themselves. So the Camera, Model and even the Collision components have some OpenGL code in them. This code is easily lifted and shifted into a specific Renderer system for the type of stuff we’re doing. It also means that the rendering code becomes consolidated in one place and that components lose their awareness of how they get rendered. This is a good thing.

Next up, we need a set of classes and components to mirror the current 3D components. These will be:

  • Sprite - To hold the sprite info (equivalent to Model)
  • SpriteManager - Equivalent to ModelManager, allows loading of sprites from config
  • SpriteComponent - Associates a Sprite to a GameObject
  • Camera2Component - A 2D camera component
  • SpriteRenderer - Renders sprites

Time to get cracking on all this. Hopefully I’ll have something to show soon.

Updating Manta-X (Part 3)

Updating Tech

Whilst I have have stripped out a lot of cruft and slowly begun bringing the project up to date, remember that a lot of the technologies we’re currently based on are very old - even after the update from a couple of years ago when I brought in SDL 1.2, TinyXml 2 and Visual Studio 2012.

I decided that whilst things are fairly simple, I should upgrade some of the foundations - it’ll be easier to do it now before things get more complex.


The first thing I wanted to do was get onto SDL2 as it is the current branch that replaces the old 1.2 branch. The biggest reason for me doing this is that at some point, I’d like to upgrade to OpenGL 3 and that they’ve improved a lot of things, including controller support.

First thing to do was to look at the really handy SDL2 migration guide and get an overview of the main changes. For me, it was mostly around creating the window and handling keyboard input.

I tackled it head on:

  • Downloaded SDL2 version 2.0.4 to deps
  • Updated premake to reference it instead of 1.2 (folder paths, link objects)
  • Compile
  • Fix resulting errors

The errors were exactly as the SDL2 Migration guide suggested. The window creation & OpenGL context stuff was slightly different, which meant changing the RenderWindow. Keyboard input needed to use scancode - so that got changed in KeyStates and PlayerControllerComponent. Once I’d changed a few minor things to handle these changes I was up and running on SDL2 without any side effects. And that was it. The upgrade was committed in a single CL that migrated to SDL2 and removed SDL1.2 entirely.

Visual Studio 2015

Visual Studio 2012 is good, however the toolset supports a very limited version of C++11. There’s a bunch of stuff in the C++11 standard that I like plus I generally perfer to be on a fairly recent compiler version where possible. As a result, I wanted to upgrade to Visual Studio 2015.

Turns out that my prior changes of upgrading to SDL2 and using premake made this as trivial as updating my premake.bat file to pass the argument vs2015 instead of vs2012. And that was literally it. Clean, build, run - it all went through without a single issue.


I used to be a huge fan of XML. Nowadays I don’t touch it if I have a choice. Like all the cool kids out there, I use JSON. I use it professionally and it’s a lot more familiar to me on a hand-authoring and parsing point of view. A couple of months ago, I wrote a JSON Parser for fun to practice my TDD skills. It turns out that this exercise will be useful.

Being that I wanted to transfer a lot of the component initialization code to be data-driven, I decided to start this work by using my JSON library.

Over several commits, I gradually migrated away from XML to JSON, loading components from a JSON file. The cumulated in me removing TinyXML from the build. Like everything, premake has made this sort of thing very easy so far. I’ll write more about the migration to JSON in another post.

If you’re not using it - go use premake now. It’s excellent.

Old Tech - Next Gen

There’s a bunch of old technology in this project still.


I’m using a really old-skool, immediate mode OpenGL renderer. This style of renderer was old-hat back in 2004 and in 2016 it’s prehistoric. I want to upgrade to using shaders, vertex buffers and all that. The thing is, I don’t know anything about it. I’m going have to learn it - this project would be a nice way of learning this stuff as it’s small and could be done pretty quickly. I’ll be looking at this in the future as it’s something that interests me.


I ripped out my own texturing and image loading system as it wasn’t used. I had a basic (uncompressed) TGA loader and that was it. I’m sure that when I need it, there will be a bunch of libraries out there to use. I’m confident that’s not going to be a concern.


The 3d assets in this game are created in Milkshape3d and loaded from the source format. They’re low-poly and untextured - I’m happy with low-poly although this was 2004 low-poly, not 2016 low-poly!

The real problem is that there hasn’t been an update to Milkshape3d since 2009. That’s 7 years ago. It’s abandonware. I could keep using this tool or I could migrate to another tool. Having asked on Twitter, the three main recommendations are:

  • Blender
  • Wings3d
  • Maya LT

They’re all viable (although Maya is a a harder justification due to cost), but the biggest blocker is the tool itself and time. Modern tools seem to have a super-complicated interface compared to Milkshape3d. All of these will take a lot of time to learn to achieve stuff as basic as I have now. However, if I ever wanted to add more content to the game, I’m going to have to decide whether to battle on with a dead tool or to dedicate time to a newer tool.

When it comes to deciding on the tool, the export format will be important - this will basically be my import format, or something I use to derive it. I’m pretty confident that I won’t need to roll my own importer and that assimp or similar libraries will help.


The game currently loads raw source assets without processing. Currently the “conversion” to game format is done at load time. For now, this is acceptable - however at some point in the futre, I’ll likely need to build in a conversion pipeline. I’ll do this when I need to - definitely bottom of the pile for now.

Build Improvements

I’m a HUGE advocate of testing and continuous integration. One huge gap right now is that my only test strategy is to run the game and manually verify the results. This is not a scalable approach. As I add new features and the code gets more complex, things will break. Things will break. And I won’t know about them until it’s too late. Adding a level of testing (unit tests & integration tests) will help here. I’ve been using my own test framework upptest for various other projects, so it’d be easy to add this here.

The next thing that would be useful would be to hook up a system such as Visual Studio Online or Travis CI to ensure that the project builds on a machine that isn’t my laptop. It’d also help for initial non-Visual Studio compilation verification (eg: clang). Again, this could be easy to set up now whilst things are simple - it’s worth considering if I indend to treat this as a proper project.

Wrapping up

There’s a whole bunch of other tech improvements or decisions I can make, however I’m defintely not make them now. I’ll tackle each problem as it comes, making the choice using the information I know at the time.

The next post up, I’ll be talking about how I ripped out the XML ShipClass system in favour of a JSON-based component initialization approach.

Until next time!

Updating Manta-X (Part 2)


Last time around we devolved the hierarchy into a component-based model. I wanted to clean that up a bit to make creating and accessing components a bit simpler.

At this point I’m not interested in exploring ‘pure’ entity-component models or arriving at a super-optmized solution, I’ll just implement something that makes working on the current system a bit more convenient whilst not closing off any future avenues.

Here’s the current GameObject class:

class GameObject final
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;
    std::unique_ptr<class ModelComponent> modelComponent;
    std::unique_ptr<class ShipComponent> shipComponent;
    std::unique_ptr<class CameraComponent> cameraComponent;
    std::unique_ptr<class ControllerComponent> controllerComponent;

My goal here is to remove the specialized std::unique_ptr and replace with a std::vector with some creation and accessor methods. In order to do this, I needed to create a lightweight baseclass for components - GameObjectComponent. At this point, it was just en empty struct.

GameObject then became:

class GameObject final
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;
    std::unique_ptr<class ModelComponent> modelComponent;
    std::unique_ptr<class ShipComponent> shipComponent;
    std::unique_ptr<class CameraComponent> cameraComponent;
    std::unique_ptr<class ControllerComponent> controllerComponent;

    std::vector<std::unique_ptr<GameObjectComponent>> components;

In true refactoring spirit, I tackled the problem one component at a time, adding things to the GameObject and GameObjectComponent as I went. The first thing that was required after adding the second component was that I needed to be able to determine the component type. I added this to the base component:

struct GameObjectComponent
    virtual ~GameObjectComponent() {}

    virtual int componentType() const = 0;

I added the getComponent method to GameObject:

GameObjectComponent* getComponent(int componentType) const;

I ended up adding a quick macro to implement this method and define a static const int ComponentType member; this allowed me to then retrieve a component by class type (eg: getComponent<ModelComponent>()).

template<class TComponent>
TComponent* getComponent() const
    return reinterpret_cast<TComponent*>(getComponent(TComponent::ComponentType));

Gradually refactoring things out, I discovered that some components needed to access others via their parent object - so I ended up putting a GameObject member on the base component. As well as accessor methods, I created some creation methods on GameObject to allow me to add components byt type:

template<class TComponent>
TComponent* addComponent()
    if (getComponent<TComponent>()) return nullptr;
    auto* cmpt = new TComponent(this);
    return cmpt;

template<class TComponent, typename TArg1>
TComponent* addComponent(TArg1&& arg1)
    if (getComponent<TComponent>()) return nullptr;
    auto* cmpt = new TComponent(this, arg1);
    return cmpt;

I’m still on VS2012 so I don’t have all the C++11 features available - as a result, I can’t use variadic templates.

At this point in time, I’m wondering whether this current component design is going to cut it. It’s not very data-oriented and is really a slightly more devolved version of the inheritance structure that was present. Having to put the back-pointer to the owning GameObject was telling that the design isn’t quite right - components still refer to each other directly whereby it should likely be a manager or system class that is dealing with these inter-dependencies. Additionally, sharing components between GameObjects may be something I want to do.

But right now it’s fine for my purposes so it’ll stick around until I need to change it.

Adding a Bad-guy

I wanted to test this out by adding a new feature - an enemy ship. The first new feature in 12 years!

This basically meant duplicating the code that creates the player and changing the rotation and position. When I start up the game, I see the enemy in the level, facing the player. Because they both have a PlayerControllerComponent they both move in response to my input. However, I realised that as I moved forwards, the enemy moved backwards. Essentially, the rotation of the enemy wasn’t being taken account of. In fixing this I’ve been wondering about whether to treat these objects as 3d space transforms, or screen-space 2d transforms. This is 2d game using 3d assets. There will be pseduo-3d in here in the forms of layering, so it’s more of a 2.5d game. Rotating an object will mean that the directions are relative to the object, not the screen. So I put in a simple “facing” concept to handle this. Now, the up/down is still in screenspace, but forwards/backwads is relative to the facing of the ship. Still not ideal, but it’ll do for now until I have something more concrete.

With all this fixed up, I removed the PlayerControllerComponent from the bad guy and now he just sits there like a duck waiting to be shot at.

At this point I’m really not happy with the code that initializes the game objects, so I wanted to make the system a little more data-driven (eg: loading data from file, not code).

First up though, there’s some cleanup work to tackle.

Until next time!

Updating Manta-X

Old Code, New Code

The last 8 posts have focussed on the past, bringing an old dog back to life. Now it’s time to look to the future. We’re no longer stripping things away, we’re now in the process of refactoring, modernising and - Horus forbid - adding new features.

The process of iteratively refactoring something is a skill you seem to pick up with experience. I clearly didn’t have this skill 12 years ago, as I left the game in a broken state, with a bunch of things ripped out and not working. Refactoring isn’t about razing it to the ground and building it back up again, it’s about deliberately evolving a codebase over many many small steps whilst keeping the thing working. Sure, you may introduce some ugliness during the process, but you’re doing it knowingly, with the end goal in mind. Anyone who’s interested in this technique should read Martin Fowler’s Refactoring book.

Project Structure

I always find that dealing with C++ in Visual Studio is a royal pain in the ass. Adding new classes is never quite as fast as you’d like. It didn’t help that I had a whacky src and include split.

I decided to port the project over to Premake5 to allow me to better iterate on the build system. Premake is good because it’ll generate my VS files for me at any time and it’s often a lot easier to work in premake than trying to configure the build in Visual Studio’s property editor.

I have two build projects - the game itself and TinyXml. It took me about 30 minutes to get this working with Premake, ensuring I was linking to everything correctly and using the right runtime libs.

With premake in place, I can now rapidly add new files or change folder locations for things. So the very first thing I did was to merge all the code from include into src, tweak my premake file and regenerate. It all worked perfectly.

Devolving GameObject’s Hierarchy

The Entity/GameObject system in the codebase is based on inheritance. If you remember the last post, I’d removed a bunch of junk from the GameObject hierarchy (including Entity), but I want to make things more composable.

There’s only two GameObject types at the moment - the GameCamera and the GameShip (player).

Here’s a summary of the current state:

      /            \
     |              |
GameCamera      ModelEntity     <--- ICollidable

Over the last few years, I’ve been using component based architectures for game objects. This concept isn’t new and I’m not going to talk about the benefits of them in length except to say that assembling lots of smaller components makes creating behaviours and working with objects a lot simpler than trying to wrangle an ever increasing inheritance graph.


The first thing to do here is to introduce a break and remove the ICollidable from ModelEntity. I do this by refactoring the code into a CollisionComponent over several small steps.

  1. Create CollisionComponent that inherits ICollidable
  2. Add member to GameObject which holds CollisionComponent
  3. Move all references over to the new CollisionComponent instead of assuming they’re inherited members
  4. Remove the inherited ICollidable from ModelEntity
  5. Collapse the ICollidable code into the CollisionComponent

With that process, we retained the exact same functionality throughout whilst migrating to something more structurally sound.

The inheritance graph now looks like:

        GameObject      <>--- CollisionComponent
      /            \
     |              |
GameCamera      ModelEntity

The CollisionComponent is reusable in that it will let me attach it to any future game objects.

The GameObject class now looks like this:

class GameObject
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;


Next up is to take care of ModelEntity, collapsing it down into a ModelComponent. Its job will be to render the model.

The process is pretty much the same as it was for the CollisionComponent - take a series of small steps towards the goal.

  1. Created ModelComponent that inherits ModelEntity
  2. Add member to GameObject which holds ModelComponent
  3. Move all references over to the new ModelComponent
  4. Make GameShip inherit GameObject instead of ModelEntity
  5. Collapse the ModelEntity code into the ModelComponent

The inheritance graph now looks like:

        GameObject      <>--- ModelComponent
      /            \
     |              |
GameCamera      GameShip

And the GameObject class is now:

class GameObject
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;
    std::unique_ptr<class ModelComponent> modelComponent;

GameShip & GameCamera

The next thing is to apply the same refactoring process to GameShip, creating the ShipComponent and to GameCamera, creating the CameraComponent.

I now have no specialized GameObjects, so I mark the class as final.

class GameObject final
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;
    std::unique_ptr<class ModelComponent> modelComponent;
    std::unique_ptr<class ShipComponent> shipComponent;
    std::unique_ptr<class CameraComponent> cameraComponent;

Player Input

The final thing to do was to relocate the current logic that takes player input from the place it currently lives (the Game class) and create a new component, ControllerComponent which does exactly the same job. I’m not too keen on the name but can’t think of anything better yet. InputComponent perhaps?

The job of this component is to inspect the controller (in this case, keyboard) and create an action to poke at the ShipComponent. If I had an AI ship, I could create a similar component that would control the ship in the same way.

Here’s our GameObject:

class GameObject final
    Vertex3 position;
    Vertex3 rotation;

    std::unique_ptr<class CollisionComponent> collisionComponent;
    std::unique_ptr<class ModelComponent> modelComponent;
    std::unique_ptr<class ShipComponent> shipComponent;
    std::unique_ptr<class CameraComponent> cameraComponent;
    std::unique_ptr<class ControllerComponent> controllerComponent;

You’ll notice that there’s a bunch of members on here that only apply to some objects. Obviously adding new components will mean bloating this class out further. I’ll take a look at this next time.

Until then!

Manta-X Code (Part 7)

Entity System

One thing that has bugged me on this whole project is that crappy entity messaging system. Now that things are simpler, leaner, I feel happy enough to get rid of it.

Removing it was fairly simple; the only 4 messages used now are Update and PreRender, Render and PostRender. Realistically, the way they’re used right now is that I have Update and Render. So I decided to collapse these down.

cloc 2120

Having dug through the entity system and fix a couple of bugs that fell out of removing the messaging system, I’ve realised that the game is simple enough to not even use the Entity class at all. I don’t have this deep object graph and if I needed it, I’d likely do it in a different way.

So, controverisally, I deleted it.

If you remember one of the earlier posts, the object graph looked like this:

  Entity        <--- IMMO
GameObject      <--- ICollidable

Now it looks like this:

ModelEntity     <--- ICollidable

GameObject is basically the Entity class now.

I could probably collapse GameShip into ModelEntity, but I’m ok with how it is.

I moved ICollidable to the model - the only reason it’s even around is because the bounding box is being rendered and I didn’t want to remove that ‘feature’. If anything, it show how broken the hierarchy was in the first place. It’s still broken, but if I were to fix it, I’d write a basic component system instead.

Some final cleaning up of more junk, I’m left staring at the cloc.

cloc 1998

Less than 2000. From a starting point of almost 6000.

Journey’s End

I’m pretty much done with the cleanup of this old code. There’s nothing really I can do to it to strip it back and keep the same features.

And with that, we’re at the end of our old code journey. There’s a bunch of stuff I could do to this, but it’d be new code from there on, written in response of a new feature or requirement.

I’m going to sit back and consider what to do next. Do I use this as a test bed to reboot the project? Do I put it back in the box and leave it for another 12 years? I just don’t know at this point.

I have really enjoyed the ride - the insight into one’s own past and constrasting it with the current version of me.

I’ve enjoyed writing about this experience as much as the exploration itself. I hope you’ve enjoyed reading.

Old code is dead. Long live old code.

Manta-X Code (Part 6)

You Didn’t Need It

You Ain’t Gonna Need It is pretty much a guiding principle of mine in more recent years. The concept of ‘future coding’ is very easy to fall into. You anticipate a need for something so you try and cater for it early; kind of like risk mitigtion. The problem with all of this is that things change. The age old philosophy that Change is the only constant in life cannot be avoided. You find new ways of doing something, an assumption you made turned out to be wrong, a new feature is required, an old one is thrown away - all this stuff has happened during the years I’ve been a profressional programmer and they will continue to happen long after I’ve hung my keyboard.

My mindset, however, wasn’t always like this. I used to believe it was the job of a software engineer to anticipate all of these things and create something that was generic for all of time. Future coding was a core concept and it’s very evident in this old codebase.

With this project I’ve got the unique opportunity to revisit the past and see of the future coding decisions I made. We are in the future right now and none of those decisions and ideas have stood the test of time. There is very little to be ‘proud’ of in this codebase, except that maybe something is visible and moving around the screen. It’s rough, but it’s a rudimentary 3d game whereby I load raw assets and display them in response to a user’s input. These days, that’s an achievement given you could accomplish the same thing in 10 minutes with Unity or Unreal.

Minimum Viable Product

THe MVP is a concept you hear a lot about in the agile circles. It’s essentially about creating the bare minimum you need to in order to achieve a goal.

With this in mind, I’ve decided that I’m going to set my current goal on stripping back everything that doesn’t contribute to the current active featureset of the game. All the stuff that was there in spirit but commented out because it doesn’t work, or is missing will go.

The current featureset is therefore:

  • Load model
  • Load ship data
  • Render model on screen
  • Model has a bounding box (I’m keeping it because it’s visible)
  • Move model in response to keyboard input
  • ‘Animate’ model on movement

If it’s not in that list, it’s not in the live codepath. If it’s not visible or materially contributing to the current features, it will be removed. If it’s an over-abstraction of a concept, it will be removed.

If you’re skeptical about lean development principles, look away now - I’m not taking any prisoners. Perfectly ‘good’ code will be removed.

Out with the old

Some stats before we begin:

cloc    | Complie time
4168    | 00:00:56.54


First up, the finite state machine that is a baseclass for the entity class. It’s a strange decision to have made anyway, especially considering it’s not actually used anywhere. Chopped.

cloc 4012

Particle System

I came across this when I was cleaning out the smart pointer system. It’s total trash. Essentially a CPU particle system that treats particle as an object. And each particle is allocated on the heap. Each particle used to be an IMMO. The only way this could have been any worse would have been to have treated each particle as an entity.

Removing it was trivial. I deleted the whole src\fx and include\fx directories and compiled. Nothing changed. It is completed unreferenced.

cloc 3635

That’s 500 lines of shitty code gone. I’m glad that this whole system is consigned to the garbage heap.


The log system is initialized and never written to. Not on error, nothing. It’s completely unused. The code is garbage; it’s an unbuffered log that writes directly to the filesystem.

It’s going. And with it, the Singleton class, as that’s the only use of the singleton.

cloc 3484


The game runs at 700 fps; when I need to profile I will. The profiler system was removed. Wasn’t used - don’t need it at this point.

cloc 3236


My nice speedy optimization of hashing strings into ints for blah blah blah. Didn’t need it.

cloc 3180

Weapon Fire

The whole system for firing weapons isn’t hooked up. If you remember from a previous post, the weapon system didn’t seem to have survived the migration to this current codebase from an older one, so it was commented out and referenced missing classes.

I’ve deleted the whole thing, including pulling out any references to it in comments or update loops.

cloc 3098


File containing random utilities that aren’t used. Deleted. The Quad class. Deleted.


The Game class has a concept of a IGameState stack - states can be pushed to and popped from the stack, triggering enter or leave logic. The problem is that there is only one GameState, which is the PlayState. As a result, the stack isn’t required.

Furthermore, after removing the stubbed methods that are called on this state, the only one that actually did anything was the updateState method. Looking at this code, it does nothing that can’t be done inside the Game::update method, it’s a pointless abstraction. So I refactored the logic from PlayState into Game and deleted it.

cloc 2914


As it stands right now, we load a couple of textures into the game and do nothing with them. The models aren’t textured; there’s no particles and no UI. As a result, the whole texture and image system can be stripped out completely without affecting anything. If I need this in the future, I would likely do it in a different way - using stb or SDL for image loading and likely using shaders in the rendering pipeline.

As a result, I removed the entire texture and image loading system. Turns out that the rendering system didn’t even handle textures anyway - there was no OpenGL code to remove.

cloc 2655

Removing Dead Code

There’s a bunch of code that deals with ‘managing’ objects. Loading them, retrieving them, removing them. The problem is that this isn’t called anywhere, so it’s dead and can go.

I had a Timer class that wasn’t used anywhere. Gone.

The Entity class has a bunch of dead code. Message handlers that are wired up but do nothing. Gone.

Remember I talked about the entity id “freelist” concept that was in here? The code was bugged and it’d end up picking the next id anyway. That whole thing can go.

What followed is just a general cleanup of methods that never got called, or if they did, were completely empty. Interestingly, a bunch of the cleanup code can be removed because I’m handling lifetime of objects correctly now.

Wrapping up

Here’s the stats after the cleanup exercise:

cloc    | Complie time
2284    | 00:00:29.46

I’ve almost halved the lines of code and reduced the compile time by a further 25 seconds.

What’s more, the ‘game’ is exactly as functional as it was before. Sure, we’ve lost a bunch of systems and engine type code, but it was all doing absolutely nothing. It had no point in existing other than to take up compile time.

What’s fun is comparing where we were at the start of this series with where we are now:

        | Start         | Now         | Difference
cloc    | 5863          | 2284        | -3579
Compile | 00:03:00.35   | 00:00:29.46 | -00:02:31

I’ve removed over 3500 lines of code and shaved 2 minutes and 31 seconds from the compile time, whilst retaining the same playable version of the game.

Makes you think, huh?

There’s a couple of small, mechanical things I want to clean up before I think about what to do next. But that’s for another post.

Manta-X Code (Part 5)

Unfinished Business

It’s been fairly cathartic to go back and clean some of this code up - almost feels like some unfinished business. Still not sure if I want to continue working on it, but I thought I’d at least cull some of the garbage in here to unmuddy the water a bit.

Let’s take away the easy stuff. All those classes that aren’t used or do nothing I’d want to take forward.

GUI Gone

First up, the GUI subsytem. It looks like I was building out a GUI system - it wasn’t hooked up to anything except an empty “editor game state” (or the code was commented out). The GUI system can handle bitmap font display, text labels and ‘windows’. I looked at the code and decided to remove it. The whole thing. If I need a GUI in the future (probably), there will be better solutions than this half finished thing - dear ImGui is one such system that I could pretty much drop into place when I need it.

That’s quite a lot of code to remove. Past-me would have kept it around because of that reason - current me thinks YAGNI and points out that it’s still in the git hitsory if I need it (I won’t).


The Entity subsystem had the DTIClass (from Game Programming Gems 2) and PropertySet stuff to provide a runtime type information and metaclass system. It was probably here for automating script binding and data loading. Well it’s not used, so it’s going.

I could pretty much delete this stuff straight up without affecting anything. Gone.

Path Navigation

I was building some rudimentary node-based path navigation system that’s not hooked up or used. By the looks of it, it wasn’t going to work anyway. Gone.


I had an exception handling system in here that seemed to track the callstack of methods to the site of the exception. Well none were thrown anyway and this looks like it is just going to be problematic. Gone.

Goodbye, IMMO

I thought I’d tackle the old nemesis, the IMMO & MMOPtr combo. The IMMO system is basically a simple reference counted pointer system that tracks all ‘managed’ objects in a global list (eg: if you inherit the IMMO base). The reference counter is incremented/decremented by the scoping of the MMOPtr object. Each frame, we ‘clean’ up the dead list by iterating it and deleting any objects.

There’s a couple of sets of problems with this system. The first is that the IMMO system itself has a few mechanical flaws:

  • global static list of objects
  • cleaning all dead on each frame
  • no custom allocation strategies (heap or gtfo)
  • and more fundamentally, an IMMO cannot be a stack object

The ‘easy’ route to fixing this would be a blanket find/replace of the IMMO system with something like std::shared_ptr.

However, the second set of problems is common to all smart pointer style systems (including std::shared_ptr):

  • easy to create circular reference groups of objects
  • easy to disregard object ownership and lifetime concerns

That second point is a huge one. You’ll recognise it when you see public method signatures that pass around std::shared_ptr for everything. What you’re essentially saying here is “I don’t know who owns this anymore” and as a result, an object’s lifetime becomes less deterministic.

In languages such as C# this is fine as the garbage collector is sophisticated and the memory is managed - C# was designed around this very concept. In C++, and in games specifically, this can become a problem.

The use of the IMMO system in Manta-X is a huge abuse of this type of pointer. Almost every method signature has an MMOPtr reference which means that every object in the game has this problem. Therefore a blanket replacement of the IMMO system with std::shared_ptr may address some of the mechanical problems with IMMO, it does not solve the architectural issues of the codebase. Instead, removing IMMO means going through each system, one at a time and making decisions about ownership and lifetime and changing it to reflect this.

So that’s what I did.

Removing IMMO

Over the course of 10 or so commits, I went through and extricated the IMMO system from the codebase. Here’s the order, from first to last:

  • GameState
  • Image Loading
  • Texture System
  • Model System
  • Ship ‘class’ system
  • Particle system (I discovered that this whole system was total junk)
  • GameData (analogous to UE4’s GameInstance)
  • Entity System
  • Remnants
  • IMMO deleted

What was very clear was that the use of IMMO in the majority of these systems was replaced by holding onto a std::unique_ptr and doling out a raw pointer to anything that needed it. In the future, this may get replaced in some systems with a handle, but right here, right now, this works.

Cleaning up

In removing IMMO, I ended up poking around almost everything in the project. As a result, I’ve decided that the next goal for me is to remove everything in the code that isn’t been exercised by the current running state. So if it’s not part of a live codepath, it’s going.

After this cleanup, cloc is 4168 (down from 5990) and compile times:

Time Elapsed 00:00:56.54

That’s down from 00:01:13:00.

Until next time.

Manta-X Code (Part 4)

Up and Running

Now that the code compiles quicker, my iteration times will be faster in this codebase. The first thing I want to do now is get the game “running” and “playable” to the point that it was. I won’t add any new features, but just try and plumb together whatever’s there.


First thing to do is get the render loop running. The game currently uses OpenGL and used to use GLFW for windowing. The last time I touched this code, I brought in SDL, commenting out stuff to do with GLFW. The first thing to do is to start pulling all that stuff back in.

It was missing:

  • SDL_Init (heh)
  • SDL Event pumping
  • SDL Video mode setup

After uncommenting the creation and update of the render window, we finally have something displayed!

That screen is the last thing I saw before I closed my IDE on the project all those years ago. It’s like looking back in time and seeing the face of someone you once knew.

I can’t remember what I was doing at the time, but that’s it.

At this point, input is all disabled. This is fine, I’ll add it later.

I remember having at least a background in there and some enemy ship. Time to go and find how to turn all that back on.

//      MMPtr<BackgroundNode>   bkgNode = new BackgroundNode( MMPtr<Texture>(bkg) );
//      bkgNode->initSceneNode();

//      MMPtr<StarFieldNode>    stars = new StarFieldNode( 50, MMPtr<Texture>(particleTexture) );
//      stars->initSceneNode();

After prodding it for a bit, it looks like the code to turn back on no longer exists. BackgroundNode and StarFieldNode don’t exist. They did exist looking at the huge weight of evidence in the place they would have been hooked up.

And then it dawns on me that perhaps this codebase was in a transitionary state from an older one. This was meant to be the improved version. I can only imagine the trash that was there before. Back then I didn’t use version control software, so my codebases always got trashed in situ, with no backups. I often used to ‘fork’ by starting a new project and copying files over, changing them to fit the new ideas.

The older game with these features looks to be completely lost in time (unless I can find another archive).

The only way to go back and add these features is to write them again. sadface.


I can at least attempt to get the input working, to at least say I have something working. This should be a straight swap of GLFW’s handling with SDL’s key events.

Or so I thought.

Looks like there’s two layers of input handling here. One via GLFW (commented out), the other using DirectInput 8. I’m going to assume that the DX version is the canonical one that needs porting to SDL.

Ripping out the DX8 code was pretty quick as it was self contained. I run the code and start pressing the keys and… nothing. Nothing happens.

Turns out there’s an error in the code that calculates the frame tick, essentially meaning that the game update doesn’t get ticked at all. I replaced this with the SDL_GetTicks function and we’re away!

The ship is moving around with the arrow keys - rolling slightly when it moves up or down the screen.

I press the spacebar to fire the weapon and… nothing. Again.

int GameShip::fireWeapon()
    if (m_fireTimer <= 0)
    //  SmallLaserFire *p = new SmallLaserFire();

    //  p->position = this->position;
    //  p->position.x += 20.0f;
    //  p->velocity.x = 150.0f;
    //  m_level->addWeaponFire( MMPtr< IWeaponFire >( p ) );

        m_fireTimer = 0.25f;

    return 0;

And guess which class doesn’t exist? Screw you, past me.

lol comments

Some of the stuff in the code amused me highly - mostly the use of comments to document functions. Check out this gem from the Game.cpp file:

// Method:      isRunning
// Returns the current run status of the game. If this is
// false then update should not be called
// Access:      public
// Prototype:   bool isRunning()
// Parameters:  None
// Returns:     bool
// History:     20/06/2004 - Created
bool Game::isRunning()

That’s from the cpp file, not the header where you’d expect. That just gets this:

// Method:      isRunning
// Returns the running status of the game
bool isRunning();

Seriously - that stuff is worse than useles…

Past-me was a Jerk

When I took this investigation on, I didn’t really know what I’d find. I’ve unearthed a lot of really bad code, with “comment out stuff” being the modus operandi for source control. There’s at least 3 or 4 layers of legacy in this code - you can tell by the technologies and style (hell, some of the comments refer to a completely different namespace).

At one point in the past, this thing was playable and now it’s not even that. This code is either the start of a new ‘improved’ fork of the game or perhaps an old one that was ripped to pieces during an ‘upgrade’.

What bugs me the most about this code isn’t that the code is bad (that was expected), but that in ‘upgrading’ the code I threw away the useful bits (eg: the game) and implemented a bunch of crap that isn’t needed or doesn’t contribute anything to the game. I literally threw away the product to sit in the wrapping paper. And it’s not even good wrapping. It’s the brown paper and string type-stuff.

Perhaps that’s the benefit of experience talking, but I do things fundamentally differently now. When I refactor, I do it iteratively and keep the old thing working. You can’t afford to just ditch the old and have code that is fundamentally broken for months (or 12 years). Unless something is no longer required, I don’t factor out old behaviours or logic during the upgrades. That’s just idiocy - something which I had in spades.

I want to go back in time and tell past-me to make better decisions around how to go about building stuff.

Next Steps

This has been a fun journey so far and I’m really not sure where to go next. It was my intention to get this game up and running and then perhaps start working on it. I’ve got it running to the extent that it ever will and now need to decide what to do next. Working on this has exposed some basic architectural flaws that would need working through (literally, everything is fucked). It may be a fun refactoring project to move this to a better architecture and keep the nugget of the ‘game’ there (‘game’ being a huge airquote). I can at least delete the commented out junk code to see what there actually is left. Or I could just close the door on this and come back to it in another 12 years.

I’ll have a think about it.

Manta-X Code (Part 3)

Improving Compilation Time

Compile times on this 6094 loc project is much slower that it should be.

A full rebuild (including TinyXml):

Time Elapsed 00:03:00.35

There’s a bunch of reasons, but one of them is poor header discipline.

The all-emcompassing header

In every header file (and therefore every cpp file), there is #include "StdHeaders.h" at the top.

This StdHeaders.h file is some stupid include file that has a bunch of “common” junk in it. This is:

  • SDL headers
  • OpenGL headers
  • Windows headers
  • Tiny XML headers
  • A load of standard library headers
  • Singleton.h
  • IMMO.h
  • …and more!

So a whole bunch of crap in every file, regardless if it’s needed or not.

The first thing to do is just jump in and delete this damn file, then fix any compilation errors.

This took about an hour of removing all references to this header and including the right headers in the files. Note, I’m currently not forward declaring anything - I’ll do that in the next pass.

Compile time now:

Time Elapsed 00:01:53.19

We’ve shaved just over a minute off the compile time by cleaning up the “god header”, cloc says that at 6056 we’ve also shaved off some code.

The thing to look at next is to start removing unnecessary includes from the headers themselves.

Forward declarations & Unnecessary includes

The easy win here is to tackle the rendering system. It seems all of these files like to directly (or indirectly) include Reader.h, which in turn includes windows.h, gl/gl.h and gl/glu.h - rather large files to be bringing in every time.

Removing Render.h including only what is needed in just the texture rendering code improves the compile time somewhat:

Time Elapsed 00:01:25.33

That’s almost 30 seconds faster.

Clearing out some more in the model system:

Time Elapsed 00:01:18.18

And some more in the Entity system:

Time Elapsed 00:01:15.47

And pretty much everything else:

Time Elapsed 00:01:12.81

Using proper header discipline reduced the compile times of this ~6000 loc project by more than half.

It goes to show that best practices are there for a reason.

In cleaning out the code, I removed some unreferenced headers (that wouldn’t compile) - so cloc is now at 5990. Ideally, I’d not be counting the TinyXml build time in this at all - so perhaps that’s another avenue.

Next Time

Next time, I’ll go about actually getting this thing rendering again. The code is all there, but commented out. Not sure why, possibly due to the transition to SDL.

Manta-X Code (Part 2)

Removing PhysicsFS

I wanted to get the game running so I thought I’d go and remove the PhysicsFS dependency. I didn’t really need it at this point and can’t be bothered with another 3rd party library for the sake of it.

Turns out it was used in 3 classes:

    ModelManager (for loading Milkshape3d models)
    ShipClassManager (for loading XML data about the ships)
    TGAImage (for loading texture data)

Each of these essentially did the same series of operations:

  1. Check the file existed
  2. Allocate a buffer
  3. Read contents into the buffer
  4. Close file
  5. Do stuff with the buffer

As a side node, back then I was doing a lot of heap allocation and looking over the code, it was very easy for these buffers to be leaked when an error occurs. Now I’ll just use a std::unique_ptr until I can come up with a better allocation strategy.

I quickly hit the fact that my FileReader class I talked about before wasn’t implemented. I seemed to do a lot of this stuff back then, have code started and just not used or finished sigh. Anyway, it was farily trivial to implement a Win32 version of the FileReader and replace the PhysicsFS code. I’m not injecting the dependency still, so the classes are currently just creating their own FileReader and going from there.

The problem with removing PhysicsFS is that I added the dist\data directory to my search path using PhysicsFS. I wrapped up the file name in an immutable FilePath object which starts out as the root data directory. Now, instead of passing raw strings around to file load routines, I pass the path object. Seems to work ok.

With that all done, I can remove PhysicsFS (sorry Icculus!).

Current cloc 6092, that’s up by 200 lines or so. Not too bad considering I removed a huge dependency.

Also, the game compiles and starts now… but doesn’t run.


So digging into the file loading was pretty useful as it exposed me to how the manta.xml file is loaded. At first glance, this appeared to be a file thet describes the properties of the player.

The player’s ship is an instance of the GameShip class, which has the following inheritance hierarchy:

  Entity        <--- IMMO
GameObject      <--- ICollidable

Every entity in the game has a finite state machine - wtf? As expected, they all base on that awful IMMO object.

So what is an Entity? It looks like it’s a graph of other entities (like Unity) - they have parents and children.

Entity Messaging

Entities also have a messaging system built into them. It’s not a game wide messaging system, looks like it’s specifically for entities.

    // Message handling interface
    IEntityMessageFunctor *RegisterMessageHandler( long pMsgId, IEntityMessageFunctor *pHandler);
    IEntityMessageFunctor *GetMessageHandler( long pMsgId );
    int HandleEntityMessage( sEntityMessageInfo *msg );
    void SendMessageToChildren( sEntityMessageInfo *msg );

The signature of of RegisterMessageHandler is weird, but looking at the implementation it essentially returns you the old handler for a message, replacing it with the one you just registered.

long pMsgId is badly named (looks like a pointer) and is essentially a constant defined in an enum:

enum EntityMessages


I guess it’s a long instead of an enum EntityMessages to avoid including headers? I doubt it, as I had a huge header include issue anyway. Perhaps just another bad decision. There’s plenty here.

The IEntityMessageFunctor is essentially a message handler with the following definition:

class IEntityMessageFunctor
    virtual int operator()(sEntityMessageInfo *msg) = 0;  // call using operator
    virtual int Call(sEntityMessageInfo *msg) = 0;        // call using function

This has a couple of obvious flaws in that handlers can mutate messages. I’m going to assume that they’re all heap allocated and the same instance is shared. Will have to confirm. Not sure why the message handler defines the call operator, probably thought it was cool back then. It’s obviously pointless.

I was wondering why I had a special baseclass for the messages, assuming that perhaps I just did some downcasting in the handler based on the message type… but no. Something weird.

The definition of the sEntityMessageInfo is:

struct sEntityMessageInfo
    sEntityMessageInfo( long pMsg, Entity *pFrom, bool pRelay );

    long msg;
    Entity *from;
    bool relay;     // Relay to children?

    std::vector<sEntityMessageParam>    params;

WTF. Looks like the sender provides a flag to determine if the message is passed to the receiver’s children (how would it know?). Also, what the hell is sEntityMessageParam?!

I take a look and… yeah.

struct sEntityMessageParam
    enum msgType

    msgType Type;

        std::string     *m_string;
        size_t          m_long;
        int             m_int;
        bool            m_bool;
        float           m_float;
        void            *m_user;
    } Data;


It’s a variant type. Why? Why? WHY?!

I presume there was some legit reason, although right now I can’t comprehend what it might be. Perhaps scripting? shrug

I just noticed that every entity subscribes to a bunch of messages on construction, regardless if they consume them:

    Erase(); _allocateID();
    RegisterMessageHandler( ENT_MSG_CREATE, new TEntityMessageFunctor<Entity>(this, &Entity::OnCreate) );
    RegisterMessageHandler( ENT_MSG_DESTROY, new TEntityMessageFunctor<Entity>(this, &Entity::OnDestroy) );
    RegisterMessageHandler( ENT_MSG_SHUTDOWN, new TEntityMessageFunctor<Entity>(this, &Entity::OnShutdown) );
    RegisterMessageHandler( ENT_MSG_UPDATE, new TEntityMessageFunctor<Entity>(this, &Entity::OnUpdate) );
    RegisterMessageHandler( ENT_MSG_ATTACHED, new TEntityMessageFunctor<Entity>(this, &Entity::OnAttached) );
    RegisterMessageHandler( ENT_MSG_DETACHED, new TEntityMessageFunctor<Entity>(this, &Entity::OnDetached) );

Also, it looks like the next entityId (returned by _allocateID()) is a static… and that there’s a freelist of ids:



The weird thing is that Entity also seems to have the concept of rendering in it:

virtual int OnPreRender( sEntityMessageInfo *msg );
virtual int OnRender( sEntityMessageInfo *msg );
virtual int OnPostRender( sEntityMessageInfo *msg );

But the implemenations do nothing.

It’s a symptom of the inheritance structure that is in place. I’d assume I’d be adding all sorts of gubbins to this Entity if we continued.

Entity has both a position and rotation property, with a comment saying that they’re relative to the parent. When I look down the hierarchy, I also notice that GameObject has a postion and rotation which seems to be used. Essentially, I have no idea what the stuff on the base entity does - if anything.

Wrap up

Looking into this Entity code has been somewhat frustrating. There’s a lot of trash in here and a lot of stuff that doesn’t do anything. The first thing I’d look at doing is ripping out the message handling stuff and putting something a little cleaner in there - Ok a lot cleaner. After that, start breaking this idiotic hierarchy into components.

The first goal, however, is to get something rendering. The game runs but doesn’t show anything.

Manta-X Archaeology

Manta-X: Uncovering a relic

I’ve been digging around in my visualstudio.com projects and came across Manta-X Game. This was a real blast from the past for me - a game dev project that I was working on back in 2004.

The goal of Manta-X was to essentially recreate the Andrew Braybrook C64 classic Uridium for the PC. I remember the ambition was to have 3d graphics instead of sprites, so I was using OpenGL. 2004 is a long time ago now and technology was very different back then. I also have no idea how far along the game got - what features it has or whether it’s even playable at all.

As a bit of fun, I’m going to explore my old codebase and blog about it. I’ll dig through the past and see how my old brain went about things and ask myself whether I’d still do things the same way now. I have been programming for a long time (long before 2004) and so my knowledge and professional development experience in the intervening 12 years has shaped my skills. This will be a fun exercise - I can remember literally nothing about the code or structure of the project at this point in time, so perhaps a few surprises will crop up :)

This is not the first time I stumbled across Manta-X; in 2012 I found it on an old hard drive and threw it up to visualstudio.com. In 2014 I found and got it compiling again, swapping out GLFW for SDL 1.2 and bringing in the latest versions of PhysicsFS and TinyXml (the versions I used were no longer around).

Today I pulled down the code from the TFS repository into git using git-tf (thanks to Chris Kirby’s blog) and uploaded it to bitbucket. Now I can start exploring and changing things.

Digging in

The first thing to note is the folder structure:


build contains the intermediate build files deps is where the third party libraries live. Currently physfs 2.0.3, SDL 1.2.15 and tinyxml 1.2.4. dist contains the built binaries and my game assets. doc contains a bunch of random text files, ideas, todo lists and other junk that was probably useful 12 years ago, but is totally meaningless to me now. include and src is where the code lives. Back then I kept .h and .cpp files separately. The visual studio solution and project files live in the root directory.


I thought it’d be interesting to explore the dist\data folder to see what assets I had. It turns out not many - a handful of tga files, Milkshape 3d models and xml specifications for entities and GUI layouts. Interestingly, I was loading up raw, loose assets and had no packaging process. The lack of assets is very telling too - the game obviously isn’t very far along. A couple of enemy models, the player model and a handful of basic textures.

I opened up the file entities\manta.xml and found this.

<?xml version="1.0" encoding="utf-8"?>
<model id="manta" file="manta">

    <feature xpos="" ypos="" zpos="" type="WEAPONMOUNT" />
    <feature xpos="" ypos="" zpos="" type="WEAPONMOUNT" />
    <feature xpos="0.0" ypos="0.0" zpos="9.0" type="ENGINEFLARE" />

        <point xpos="-10.0" ypos="-5.0" zpos="-8.5" type="MIN" />
        <point xpos="10.0" ypos="5.0" zpos="8.5" type="MAX" />

    <motion direction="LEFT" velocity="100.0" maxtilt="15.0" />
    <motion direction="RIGHT" velocity="100.0" maxtilt="15.0" />

    <motion direction="THRUST" velocity="100.0" maxtilt="0" />
    <motion direction="BRAKE" velocity="100.0" maxtilt="0" />

    <setting name="AUTO_TILT_CENTER" value="1" />


Of course, it means very little to me now - especially the magic “AUTO_TILT_CENTER” setting :) I was also clearly specifying the entity as a whole, rather than using a more component based model. I bet that looking in the code I find an inheritance graph for entities that starts with a class called Entity and ends with Manta, likely with some abstraction of Ship somewhere in the middle.

There’s a scripts\startup.gm file with the contents:

// Load models for game
Game.Models.Load( "manta", "models/manta.ms3d" );

// Create a player ship using the 'manta' model
player = Game.CreatePlayerShip( "manta" );

player.y_rot = 90.0f;
player.x_pos = -50.0f;

Looks like I was using the GameMonkey Script system to implement the “game”. Quite why there’s a split between xml configuration and script for similar reasons is unknown to me - there probably isn’t a sensible reason!

The textures folder is also very telling about the state of the game. There’s a nice background texture, a particle texture, a bitmap font and… that’s it. The models have no textures at all!

The lack of an audio folder confirms that not adding audio to my projects goes back a long way :)

Currently the game compiles but doesn’t run due to missing dlls (SDL runtime and physfs.dll). In my next post I’ll focus on getting the game running and then dig into the code and start exploring.

Until next time!