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.

FileSystem

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.

Messaging

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.