I am writing this blog post from an apartment in Girne, enjoying a week off of work (the day job!) with my wife in Northern Cyprus. We spent the day today on a boat trip cruising around the coast, swimming at various points along the way and enjoying the sun. Being off of work of course also allows me time to work on the game in my own spare time, so I thought I would do a quick post detailing progress on the project this evening. One of the major improvements and milestones I have reached recently is the addition of object pooling to the game. For anyone working on any decent kind of bullet hell / shoot-em-up game, this design pattern is a must if you wish to maintain decent performance. I started off the project not using object pooling, and soon started noticing small performance hiccups when instantiating and destroying some object types. My guess is that this was either to do with memory allocation during the expensive game loop creating large groups of enemies, or when the GC was cleaning up objects that were being destroyed.
Well, I’m happy to say that I have finished work on an object pooling system. Whilst fairly basic, it does a good enough job, and allows for dynamic expansion if the objects that are pooled at the start of each game are not enough during gameplay. Bullets, projectiles, enemies, and other objects of which there are usually many, are pooled, and the system ensures they are disabled when “destroyed” and returned again when needed. Apart from object pooling, the following is a high-level list of what else I have been working on:
- Level system, allowing the user/player to create and edit levels via XML configuration files – each level that is created is listed in the game menu to play. Everything is customisable – from the enemy types, wave sizes, properties, pickups that are dropped, to the cosmetic stuff like space junk and asteroids that fly around. Previously, the game started with just a single level, of which I have been testing all game elements in.
- Menu UI – I am using Daikon Forge for the GUI parts of the game. I picked this up on special, and must say it has been well worth the money I paid, even if I had bought it at the normal price. I have been using a daikon forge example menu, but am heavily modifying it for my own use, especially for the next feature…
- Custom games – giving the user the option of starting a custom, randomised level – the player can select parameters for each system in a game of which to randomise, then play this level. My idea is that this will be an “endless” mode. Players choose size ranges for things like enemy count per enemy wave, pickups to drop, cosmetic stuff to use in the level etc…
- Bug fixes – some enemy projectile bugs came up recently due to the fact that I was now re-using objects rather than destroying and re-instantiating them. Some of the bug fixes I have been working on relate to this.
My aims at the moment are the following:
- Continue work on the GUI elements in the game
- Introduce new projectile systems for enemies and player alike
- Start developing a single-player campaign using the new “level system”
- Possibly add dialogue and a bit of cutscene interaction to the single-player levels
Here are a couple more screenshots showing a bit of level variation which is now possible via XML configuration. 
