Game Design, Programming and running a one-man games business…

Category: ridiculousspacebattles

Challenge code and UI almost done!

Posted on August 26, 2026

So…I am still working on the online multiplayer(asynch) code and UI and UX for Ridiculous Space Battles, but progress has been pretty good, and certainly way quicker than the first time I attempted to do all this sixteen(!) years ago… So I am happy to say that apart from a few small things I need to fix, and a few minor things to add (like rankings and victory counts), the online challenge portion of everything is kinda in and done! Here is the current challenge list screen:

UI code is fiddly and takes ages, but what really took a while on that screen was the filtering and order sorting. You can sort by any column, which is pretty cool, and all the filters at the bottom work correctly now! There is a manual ‘refresh list’ button which grabs a new dump of all the challenge data from the server. Right now its super-dumb and just grabs the first 1,000 challenges from the server. The original game (Gratuitous Space Battles) was so popular that this would have been useless, and in an ideal world, where I get a lot of players, I maybe need to redo that so it multi-threads, and gets the ones that have changed only, and so on…but that is probably something worth saving for refinement during early access… Anyway here is a totally NEW screen:

This is what you get when you click on a challenge. It shows you the enemy deployment thumbnail (although their ship positions obviously get inverted when you hit play and fight against it), some data about it, the description and name entered by the challenge author…and today’s mornings work, which is the list of challenges that were issued as a ‘retaliation’ to that challenge.

So a ‘challenge; is basically a player designed fleet, formation and orders that is designed to beat all opponents. It gets uploaded to my server (its only a 10kish text file) along with a small jpg of what the deployment screen looks like. Anyone and everyone (including the challenge author) can then design a fleet and fight against that challenge. If you WIN against it…you see an extra button on the game-over screen that lets you submit your victorious fleet as a ‘retaliation’. Here is what that currently looks like (It might be easily missed I think…)

That gets attached to the existing challenge, with that challenge as its parent. These are the challenges you can see in the ‘retaliations’ list above, which are normally filtered out. You will be able to hit ‘replay’ to watch the two fleets fight, and the idea is that you get to see how an enemy managed to beat you.

Now this is just my first go at the UX and gameplay for this, so it will likely evolve. Right now if you win against a challenge with an amazing victory, there is no way to break that challenge out into its own fresh challenge, and maybe I do need that. And I definitely need to put in a voting for difficulty and fun system like I had with the original game. But its progress! and eventually I’ll get back to working on less UI code and more awesome battle stuff like this screenshot:

Anyway… I signed up the game to be in the next NextFest with a demo, so I have a hard deadline at last. Kinda scary. But if this sort of game appeals to you, please add it to your steam wish list using the widget below:

Challenge UI for Ridiculous Space Battles

Posted on August 19, 2026

If you played the original Gratuitous Space Battles game about 500 years ago, you will recall that the online challenges were a very popular part of the game. If not, let me explain: GSB was the first autobattler, so its a game where you set up a fleet of space ships (that you designed), give them orders, and then use that fleet to defeat the enemy in a mission (which I called a skirmish) that was designed by me (the developer). HOWEVER, there was also the option to just design a fleet that you thought was a good all-rounder against all foes, and submit a ‘challenge’ to another player (or everyone) and let them fight against your fleet.

To do this, there was an online system where you logged in, and designed the fleet, typed a ‘taunt’ for your enemies, and submitted that challenge. It got stored on my server as a small text file, along with a small thumbnail preview image showing the fleet formation. Other players could browse available challenges, download them, and enjoy designing fleets to beat them. There were ratings system, message systems, and ability to view all of the fleets that were sent to battle against your fleet. It was so cool, and so popular, it crashed the server. The challenges were stored as individual files, and there was something silly like 500,000 of them (or more), and the whole back-end basically collapsed eventually!

So lets not let that happen this time eh? (hardly a risk, as I doubt this game will be as popular).

Anyway, I am re-coding the whole thing from scratch, like I have done for the whole of Ridiculous Space Battles, so it means completely re-thinking the UI, the UX, and the back-end code. The previous layout of the challenge browser looked like this:

Which has not aged THAT badly, although it certainly does not fit the more clean and white-space loving UI of the new game. The original game went with an ‘industrial physical’ theme for the UI, and that feels very 1990s to me now. The new design currently looks like this:

A bunch of stuff has changed. I am now listing the challenge ID, and also a title as well as a description. I do not have difficulties in there yet, or ratings for fun, but I might include that again. The big problem is getting the balance right between ‘I have a lot of information to display here’ and ‘do not look too cluttered’. This is something I struggle with a lot in design, because I feel like my tastes are the opposite of most web designers and game designers these days.

I am an autistic, numbers-obsessed data-loving geek who loves nothing more than a super-complicated dashboard of data. (Its a miracle I only worked on the software on trading floors and did not become a trader myself) This means I am pre-disposed to a data-rich UI layout. But these days its apparently ILLEGAL to update any software without saying its a ‘cleaner’ look, which means that the whitespace has gone from 90% of the layout to 95% of the layout. Absolutely every ‘designer’ seems to assume the only UI in the universe is a mobile phone, and the only customer is someone who is mentally incapable of seeing two pieces of information on a single screen. By Kahless I hate this trend… but anyway, nobody gets to tell me how to design my own game, so why do I care :D.

Anyway, there is a lot more to do. I have a different UI almost complete for actually submitting a challenge:

…but I still need to do the code that downloads the challenge from the browser, and then launches the deployment screen with it as a battle to be fought, and resolve all that at the end (Telling the challenge there was an attempt, and if it was a victory… logging what the attempting fleet was, etc). I also need to stress test everything, and set things up so you cannot create multiple users etc etc.

Doing all of that means writing a bunch of web client code (I use the WinInet win32 API) and also server code in PHP and SQL. This is where I have found working alongside Claude (Anthropic’s AI) has been great. I do NOT (yet) use ‘Claude Code’, but what I am doing (with a £15/month sub) is occasionally asking for Claude to write some php, or some SQL or an WinInet function for me, that I then read through and check. This, in my opinion is a great way to use AI to make you a more productive coder, without worrying that its doing random stuff. I use Claude very sparingly to write general C++, but for this part of the game, I’m using it a lot.

Why? Because frankly I do not enjoy SQL or PHP and am not an expert. I can code in C++ with my eyes closed (you would expect that after 29 years right?), but I have written very little php or SQL, and this stuff is web server stuff so its DANGEROUS. If I screw up the .exe, the game might crash, but screwing up database code and php could let someone hack the server and wipe things. I REALLY need expert help on the php/sql stuff, and Claude certainly seems to be amazing at this. FWIW I use Opus 4.8 (High) right now. Anyone who has used SQL will appreciate being able to say “Write me the correct SQL to do this…”.

Anyway… things are progressing! And I hope to actually have the game in a shippable (to Early Access) state around October at the latest. All I have left to do is this challenge stuff, then a bunch of ship designing and fleet designing for the levels and campaign (already done, but definitely need another pass), and a tutorial, and then its basically very playable. Early access will hopefully be a period of optimisation, any bug fixes, and responding to player suggestions about balance, gameplay tweaks and new features. I think I *am* just going to re-use the GSB2 music for this game, and all of the art is done, so I am not waiting for anybody else (and this is proudly a solo project anyway).

If you want to be notified when the game is finally released, you can add it to your steam wish-list using the widget below, or maybe bookmark (and share!) the games website link. Thanks :D.

New battle video from Ridiculous Space Battles

Posted on July 5, 2026

I have actually still been working on my game all this time, but have been a bit distracted with some technical stuff, and life diversions, and also not feeling there was much of a visual change to show off, but enough is enough, and I thought I’d just quickly throw together a short 2 minute campaign battle video to show you the current state of the game.

For those new to this blog, Ridiculous Space Battles is my ‘spiritual successor’ to ‘Gratuitous Space Battles’ which I made around 2011. I’ve really enjoyed working on it, and I think its better in every way. Here is the video of a battle I quickly filmed and slung onto youtube:

The thing some people do *not* like, is that ships fight in fixed formations, basically in ‘lanes’, and some people who loved GSB dislike this change. Personally I find it to be vastly *better* and makes the battles feel more cinematic and more like an old school naval battle, than the ‘random scrum’ that many large-scale battle games descend into.

I should point out this is battle #4 in the campaign, using a mixture of ships that survived the previous battles, and some reinforcements. Its a fairly small battle. I am not sure I am happy with the contrast of the background nebula, but obviously this is a work in progress. Anyway, I’m quite proud of the general space laser mayhem :D. If you are interested in the game, you should add it to your wish-list on steam using the link below. It will also hopefully make it to GoG. But not epic or other stores. And only on PC. Fuck apple :D.

Building a deterministic space auto-battler

Posted on June 7, 2026

This was not part of the plan. When I made Gratuitous Space Battles, it was not a deterministic sim. Multiple runs of a battle could lead to slightly different results. It was not ideal. And I was not even thinking about it with Ridiculous Space Battles, until I started to do balance testing and started designing campaign levels. And in that testing I started to really appreciate how infuriating a lack of determinism was. That was more than a week ago. Maybe two weeks…

To explain: Ideally if you do two battles in RSB with the exact same deployments, you should get the same result. Not just victory or defeat, but the exact same score. This is is the whole core of the game. The smaller the fleet you win with, the more points you score. So running the whole battle again with just ONE less squadron, is definitely worth it for the meta-game (and bragging rights). But that might mean fielding 99 squads instead of 100. In other words, the game has to be accurate down to that 1%, and actually that means 100% deterministic.

Here is the problem. A missile fired from a frigate drifts 0.0001 units to the left compared to the previous run-through. That means it actually hits its target VERY slightly later, but that ‘later’ means just *after* its target fires its massive mega-gun that takes out a crucial enemy cruiser. Without that cruiser, the fleet will narrowly lose. With it, the fleet will narrowly win. So that missile MUST hit its target in the exact same frame, every time…

…and its worse. That missile might even be a dummy missile. It might even miss! it does not matter. Because in theory that 0.0001 units means its the nearest target for a point defense laser, or not. That could still lead to a chain of events that results in the whole outcome of the battle being changed. In practice, if you want the outcome of a big battle to be predictable, and repeatable you need a 100% deterministic simulation. Thats not 99.99999% deterministic. Its absolutely 100%. And that is… hard.

I’m not a n00b coder. I know this problem is hard, AND I know in theory how to avoid it. Have a constant simulation rate, and detach the frame rate from the sim rate. Do not use any truly random numbers, but precalculated ones based on a fixed random seed. You can use true randoms for UI, but never for the sim. The sim is the sim. The UI is the UI. They never get confused. Simple right? And I am sure coders who haven’t worked on it before already think its an afternoon’s work. It is not!

It would have been WAY easier if I had worried about this right at the start of coding the game, but I did not, and so I had to take a huge existing game and MAKE it deterministic, and its taken weeks and I’m not yet 100% sure I’ve cracked it. I have definitely made it much better, but am I at 99.99999% or 100%? Lots of testing tomorrow will answer that for me. But briefly, this is what was involved:

Step 1 was to move from a variable frame rate (capped at 60 fps) to a dual system where the sim runs at a constant interval, but the frame rate is independent. This is complicated by the fact that the game has 5 speeds, from 1/4 speed to 4x speed. Actually to be fair this part of the work was quick and easy. I still have a ton of macros in the code referring to SIMTIME that actually should now just be ‘4.0f’, but thats the beauty of macros. There was a fair bit of find/replace to change a lot of calls in the code to either use SIMTIME or FRAMETIME, but that was simple. Now every tick assumes 4ms has passed, and the ratio of ticks to frames simply depends on the current game speed. This does mean I have kind of lost the ‘frame-smoothing’ for when the GPU is under more or less strain, but TBH the game runs so fast its ludicrous anyway, and for super low spec GPUs the game has a ton of graphics detail settings.

So that sim/graphics decouple was a big step, and an easy step, but after that the real problems began. Basically there were mistakes somewhere in the code. There were circumstances where things drifted out of synch, and it took a ton of detective work to find them all. Things went much quicker when I realised there was no escaping just writing a big ‘Determinism’ class that analysed data across two runs. I made a ton of mistakes here, and they are stupid, but thats coding for you :D. The most embarrassing one was this: I collected a TON of information for every tick, in huge arrays, and then on the second playthrough, I built a second bunch of arrays and kept cross checking them to spot errors. Sounds reasonable right?

Firstly like a muppet, I was checking for ‘drift’ of values every frame, but storing all this data a second time. Stupid. I only need the PREVIOUS playthrough’s data. I just need to collect *this* frames data, and compare against the past. But thats a ‘current-frame’ snapshot. I don’t need to store that! Secondly I was stupidly searching for a matching tick’s data in the previous playthrough. Madness. I KNOW what tick we are on. I can just index it, and do a super quick compare ffs…

You might think thats stupid worrying about optimisation in pure-debug code…but this is a 32 bit app, so limited to 2GB (or maybe 4GB depending on settings), and although my game stays nicely at about 6-700MB, storing 80,000 frames of simulation data for every ship, missile, drone, mine and bullet very rapidly hits that limit. I needed super comprehensive simulation snapshots, but memory-efficient ones. This proved tricky. You might think ‘store everything’ but trust me, its just NOT an option for a long, large battle with this level of complexity and 240 ticks a second (60fps but possibly 1/4 speed so 240 sim ticks per second).

Oh BTW if you think ‘cliff that’s dumb. At 4x speed you still only need 1 tick, just make it a tick thats 4x as long’. NO. This is because in code, a missile moves every tick. If it hits the target, stuff happens then, and in the following ticks. If you bundle 4 ticks into 1, then the missile ‘hits’, but nothing else, whereas it may hit in tick 1, and then ticks 2,3,4 the affected shield slowly regenerates. In other words my sim is discrete tick based, not variable time equation based. Its just simpler this way :D.

So what other really stupid mistakes took me days to sort out? Well they are all kinda dumb, but in a code-base this big, I think I should cut myself some slack. And actually in TWO of the big cases, in the back of my mind I knew as I coded them that they were flaky as hell. Normally my code is VERY cleanly split between simulation and graphics. In fact all my classes are called SIM_Thing or GUI_Thing, to make that super clear, and make sure I don’t do anything dumb like change the sim from the GUI, which would be really bad software engineering that obviously I shouldn’t do and obviously I did in two places :D.

The first one was a bit obscure. When ships ‘escape’ the battle, they quickly zap off the screen like they are entering hyperspace. To make it seem cool, every ship zaps-away at a slightly different speed, because then it looks like the rebel fleet going into hyperspace in return of the jedi… And thats all well and cool, but it used a proper random number in the GUI code, and at the end of the warp-jump, it then told the SIM the ship had escaped at last… What terrible code. This was the GUI setting times for the SIM. Madness. And a determinism destroying bug. Very rarely that extra 50ms was long enough for an enemy ship to get just one extra enemy-destroying shot off…

The second one is even more obscure. I have classic graphics-distorting shockwaves when big ships explode. They look cool, AND they also move debris, hulks, escapepods and (it turns out) missiles, slightly in space as the ‘wave front’ hits them. I coded this with the GUI determining what SIM objects to move when… because it was way easier. I know in the GUI code the radius of the shockwave, so I can detect anything I need to move in the GUI code, and apply a physics force to them. The trouble is…thats the GUI lecturing the sim again, and because speeds can vary we cannot ensure the sim tick / frame rate ratio, which means in one playthrough a shockwave moves a missile maybe 4ms before another playthrough, and that tiny difference is determinism-destroying. For now, I just stopped missiles reacting to shockwaves. The rest is just UI and doesn’t matter.

So thats where I am now. I have run 6 consecutive tests on 2 different (smallish) levels, and its 100% deterministic. It was HARD. All the mistakes were dumb ones by me, which is basically the definition of coding alone. It took a lot of detective work, and really focusing on the very first deviation from known values to track it all down. (There were many other minor causes). One of the side effects of working so hard on all this is that it really has reminded me how much I love the TV show devs. Which if you have never watched… why the hell not?