Funky Boss

A quick one this time. I'm heading towards getting collision into the game, but before I do that I need to get the game objects better managed. So this time I'm going to refactor the code a little bit to add an object manager. It's going to mean several small changes across the codebase..

Partitions

The point of the object manager is to partition the objects into different types. This will make it easy to, say, collide the player against all of the bullets without it also colliding against the spawners. To do this I'll create one list for each object type. This will be in contrast to the old code which only had one object list for all objects.

The code for the ObjectManager class will hopefully feel pretty familiar as most of it has been lifted from the old mainLoop(). The only obvious difference is the use of multiple object lists. You'll see these being created in the constructor, then being used in the update() and render() functions.

At the end of the ObjectManager class you'll see the add0 function, which adds objects to the appropriate object list based on their type. This means that I've added a new variable, called type, to the Object class:

..and then each object passes in their type to the Object base constructor, like the player does here:
Now we need to call the object manager's add() function instead of just adding the objects directly to the old objects list:
Finally, we plug the object manager into the main loop:

Wrapping Up

In this step I refactored the object manager to make it easier to manage the game objects. There was no real change in the way that the game plays or looks, only to the behind-the-scenes code that makes it happen. The benefit of this change was to make object management easier and more efficient for the changes that will come next.

As always, the code is available in the git repo, and the game can be played online with this direct link.

I could have written the object manager in one of the earlier steps, but it would have made the earlier steps more complicated - and that would have made them harder to follow. The point of this blog is to make a game in an iterative manner - adding new features and refactoring old ones as necessary. It's good practice to start simple and build up complexity only when it is required, and only when you know you have a good idea of what you want. There's nothing worse than spending time writing a complex feature only to realise some time later that you don't actually need it. Over-engineering up-front is a painful path to follow.

Coming Next

Next step is going to be a bit bigger than this one - I'll be adding collision.