Its been a while since I blogged… Anyway I have not been completely idle. As well as booking a long-desired holiday to CHINA (oh yes!) I have still been working on this weird project that I cannot decide if its a retirement hobby or a proper serious game launch, and that would be my pretentious re-imagining of Gratuitous Space Battles, which I am appropriately calling ‘Ridiculous Space Battles’.
The game is very playable right now. It has a ton of content, and it runs great, and it looks fab. But it does not have data for the campaign games, and does not have the challenge system coded into it yet. I might at some point decide to put the challenge system off for a bit, and release it with skirmish and campaign games into Early Access. I really do keep changing my mind on that. This game has been very cheap to make, and I am under no pressure to release, so to be honest it feels kinda weird being able to do anything I like with it!
Anyway, something I have always wanted for my games was a pre-release debug build functionality to have them run hundreds or thousands of games and automatically provide data that would let me balance the initial stats before actual humans start to play it. Now if you are a relatively new developer, its easy to just sling out lines like “Yeah just code a headless mode that randomly designs ships and fleets and have them fight each other a million times to collect stats”. This is the sort of thing swaggering indie devs throw out in a reddit thread as advice, as though that single sentence contains all the required skill, code and effort.
Its not that simple.
Now if you have a much simpler ‘problem-space’, then it gets massively easier, but just the process of coding random ship designs and random fleet deployments is a major engineering effort in itself. Getting the game to be able to put together a ‘legal’ in game-terms design isn’t too tricky, but ensuring it produces sensible designs is another things entirely. There is nothing to stop the entire deployed fleet consisting of a hundred ships that only have anti missile defence weapons and zero offensive capability, for example. That would be a valid fleet design, but useless for auto-balancing. Worse, it would imply in the stats that missiles are useless, without the caveat of ‘yup but that strategy can never win a battle’.
Its a massive minefield of issues like this, an frankly I have not addressed any of them yet. My current code designs each ship in a fleet individually right now, so the chances are such anomalies would be highly unlikely. However, the point stands that a ‘random’ fleet design is not ideal. And thats before we start placing those ships in formations, and assigning orders to them based on their designs. I’ve done a bunch of wok on that, but its still not ideal.
The actual easy bit was the stats collection and amalgamation into a nice spreadsheet at the end. My game is very stats-based (its an auto-battler after all), so the code to track all those stats was already in game. What took a bit longer was the wrapper code to run through a battle with a random fleet, record stats, and then do the next battle. This *sounds* easy, but when a game has been designed on the basis of the user clicking buttons, circumventing that without errors can be buggy. I didn’t just simulate mouse clicks because I needed to totally skip the deployment UI for each battle. Otherwise I am flushing a ton of textures and loading a whole pointless UI between every battle, slowing down the auto-run process.
The real delay in this stuff has been two-fold. I need to code some sort of basic genetic algorithm for ship design, and I also encountered loads of bugs. Lets do the bugs first. Its easy to think ‘dude, you shouldn’t have bugs in your code’, but harder to make that a reality when you have a game as complex as RSB. There are over 720 source files for the game and the same amount again for the engine, and the code is fiendishly complex. Plus the actual GAME is fiendishly complex. For example, I encountered a crash bug while typing this (The game was churning auto-balance in the background). It was a crash bug where the game lost focus, then recovered focus (I had moved to another window), and it crashed in the shader for Target Painter weapons.
You might think ‘what a noob, you obviously dont re-init your shaders’, but nope, I do. This is obviously something specific to THAT shader. I have tested the game a lot, but apparently never alt-tabbed away exactly when the game was drawing a target-painting effect. Given how many different systems and visual effects the game has, its no wonder I have not churned through all the possibilities yet. This is one of the major benefits of writing this autobalance code. I am soak-testing my game, running thousands of battles and trying every permutation possible, and it throws up a ton of asserts and warnings and crashes, all in obscure and exciting places. I DO test new features when they are added, but testing them in every permutation of battle is impossible. I’d need 50 people working in QA.
So the last aspect of all this is genetic algorithms. I intend to try a bit of this but no go mad. Right now, I can only tell if ‘fast missiles’ are overpowered by looking at the amount of damage they do, over 100 battles, compared to their cost and weapon module size. If they DO look a bit overpowered, then maybe they should be selected more, to assess whether they are clearly a super-weapon, or if thy just happened to always get matched against fleets that had poor missile defence. Perhaps I need a system that takes the top ten weapons from the previous 100 games and biases towards them so I can concentrate on collecting data for them. Perhaps also do the same with the BOTTOM ten weapons so I can see if they were just badly represented due to random match-up.
And of course all of this is ignoring non-weapon modules. I should probably test the ‘survival rate’ or ‘survival time’ of ships with each armour and shield module or other defensive module like a decoy projector or cloaking device. Maybe these are hugely overpowered? I have not even begun to look at that yet.
One piece of excellent news though. My game is VERY good at pruning its memory usage and definitely has no leaks. I’m watching the area chart in the visual studio debug view as I type and its currently using 234MB (lolz) and rarely goes above 400MB in big battles. This is a vast improvement on my other games, or early builds of RSB that were leaky.
So there you go, I AM still coding, but not in a hurry, and I hope the end result is worth it :D. Don’t forget to add RSB to your steam wishlist if the game sounds interesting to you!