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

Is this game you designed actually any fun?

Posted on June 1, 2025

When you develop an entire game by yourself, there is a staggering amount of work to do. Coding, business stuff, marketing, testing, balancing, designing. And I think that the majority of people who ‘want to make video games’ tend to over focus on the design bit. The whole ‘I have an idea for a cool game’ bit. It might surprise people to know that this is the bit that I am least fond of. In many ways I am a cross between an AI/Engine coder and an entrepreneur who realizes he has to design games to sell that code inside. The whole ‘working out how the game will play’ side of things has always been hard and frustrating for me.

You might find this an odd thing for me to say for two reasons: Firstly, I’ve made a bunch of (I think) pretty innovative games. Kudos was the first turn-based life-sim game (AFAIK). Democracy was the first commercial game designed around a neural network and based on the aesthetics of infographics. Gratuitous Space Battles was the world’s first auto-battler game. There is no shortage of innovation there. Secondly, not many game developers would ever admit they don’t enjoy the game design bit. Thats the bit we are supposed to excel at right? Admitting you don’t enjoy that bit as much is almost blasphemy.

As is probably obvious, I’m autistic, and one of the ways this manifests is that I like, and even need… data. You can tweak your ad campaign or marketing strategy and see if sales go up or down by 1%. You can re-engineer your code and check that performance has gone up or down by 1%. But game design? How on earth do you know the game is fun? How do you measure if you are making the game BETTER with all those changes… or worse? And in the absence of such data, what the hell are you doing?

I think most fulltime game designers seem insecure, as they are always asking other people if what they are doing is any good! We have to, because its very very hard to tell. In some ways, designing a game is like writing a joke. You can put a lot of effort in, have some skill, lean on prior experience, but by the time you are finished working on the joke, it stopped being funny to you personally ages ago. If you spend your entire day staring at spreadsheets of weapon characteristics until your eyeballs are sore, the question ‘Is this spreadsheet fun?’ feels almost insane. There is a good reason many game designers are NOT avid players of their own games after release. We are too close to it, too aware of the mechanics, too aware of the areas we are not sure about. We saw the sausage being made, and we do not want a sausage sandwich for breakfast.

This might sound a bit depressing, and it would be more so if this was my first rodeo, but I’ve experienced it before as a musician. For probably 20 years, I was unable to just ‘enjoy’ music. I would listen to it from a technical point of view. I might marvel at the clean guitar tone, the incredible timing, the complexity of the arpeggios, but I was listening to it from a teacher and student point of view, not as an audience member. I can now mostly just enjoy music, but I’m still aware of the keys and scales and techniques…

Being ‘too close’ to your own work will always be a problem. You will not be sure your joke is funny, your novel is gripping, your music is cool or your game is fun. Its just impossible for someone so close to the system to evaluate it in the same way a customer would. There are however, ways to get around this!

One is obviously to ask a lot of people. Friends, family, fellow game devs. The trouble is that these people are normally pre-disposed to worrying about hurting your feelings. Not many people will say to me “Cliff, this sounds boring as fuck”, although over the years I’ve managed to find people who know me well enough to be aware they can be more honest with me than other people. Even so, its not disinterested feedback, and if all your friends are game designers too, you are hardly getting a representative slice of the consumer base.

A second technique is time. Take a weekend off, or a week off. Ideally a month off. Some novelists stick their work in a drawer for a YEAR and then come back to it fresh, and can evaluate it with a far better critical eye. Of course the problem here is you need to earn money, but if you can work on multiple games at once and swap them over, this might be an option. Its definitely a system that works.

A third technique is drugs. Yes I went there. I am quite boring in that my narcotic of choice is just good old fashioned alcohol. Its not like I am permanently drunk when designing (am I making this denial too strongly maybe?), but I *do* drink, and I do my best to learn to ‘channel’ the feeling of being drunk when thinking about game design. The reason? when you are uninhibited, you have a different emotional response, and I think that change in emotional response gets you closer to the enthusiasm of someone seeing your work for the first time. Drunk cliff can watch a battle in Ridiculous Space Battles and have no greater design insight than “WHOAH LASERS!”, and if thats the response to my game, then I am totally fine with that.

In fact ‘Whoah Lasers!’ is a good name for a game.

Anyway, I offer this blog post as counterpoint to the idea that game design is something that you can get from a text book and can be quantified and analyzed with ‘player verbs’ and ‘core loops’. Ultimately what you are trying to do is make something FUN and this is no different to making something FUNNY. Its folly to suggest there is an equation for either humor or fun. Making something with either of these attributes is hard, and fuzzy and it doesn’t come easily to everyone. Certainly not me.

But obviously I need to reassure you that Ridiculous Space Battles will be totally fun. Its currently 92.65% fun by I am optimizing it. You can wishlist it now etc. Wouldn’t that be fun! (am I funny?)

Optimising Ridiculous Space Battles

Posted on May 18, 2025

Due to what seemed to be a compiler bug (omgz) yesterday I thought that large complex battles in Ridiculous Space Battles were hitting performance limits. That appears to not be the case, but it got me back into profiling the bigger battles (20×20 grid size, with up to 25 ships in each square, probably 600 ships in total) to see where the bottlenecks are.

The game is already multithreaded for some tasks, but the first profiling runs for he first 50% of a battle gives me this flame graph from uprof for the main thread:

In practice what I really care about is stuff inside GUI_Game::Draw(). I have to say I am pleasantly surprised with the breakdown as it seems nicely distributed, without any real obvious processor hogs at first glace. Drawing the ship sprites, processing the simulation, post processing (mostly lightmaps), particles, hulks, bullets and then a bunch of minor stuff. Nothing seems too bad. On the other hand there are some things in there that seem quite big given what I know they are doing. For example the lightmap stuff shouldnt be that big a deal, and perhaps should be threadable more? Lightmaps are being drawn not only for every laser ‘bullet’ but also every engine glow, and every one of the many sprites that make up a beam laser. I also draw ship ‘mattes’ to ensure that light does not glow through objects like asteroids. Even so, this doesn’t sound like a lot of CPU?

So this breakdown is showing as expected that a lot of it is within the drawmattes, but even so that seems too much to me. There might be a single ship sprite, but 6 engine glows and the flares from 20 missiles or 6 beam lasers associated with it. How come mattes are so slow? At first I assumed that I was not checking to see if they were onscreen, but I definitely am. Here is the code for that function:

GUI_GetShaderManager()->StartShader("matte.fx");
for (SIM_Ship* ps : PlayerShips)
{
    ps->DrawMatte();
}
for (SIM_Ship* ps : EnemyShips)
{
    ps->DrawMatte();
}

GUI_GetHulks()->DrawMattes();

GUI_GetRenderManager()->Render();
GUI_GetShaderManager()->EndShader("matte.fx");

So nothing exactly too complex. It could be that just traversing the STL list for 600 ships takes time, but frankly 600 is not a big list. Could it actually all be the hulks? Actually uprof suggests a lot of it is… but checking that code, its basically doing the same thing. The game made a note early whether to render a hulk matte, so there is no redundant rendering taking place. Hmmm. Maybe best to look elsewhere for problems. I tried running a battle involving a ludicrous number of bullets. I gave the Expanse ‘Apocalypse Cruiser’ a huge bunch of Gravimetric impulse cannons which have lost of burst fire, and filled a fleet with them.

And the flame graph is actually not too bad again:

Ok, bullet process is now the top task, but it has not gone insane, which is good. And the bulletmanager Draw() is also obviously bigger, but again not insane. I dug a little deeper, and found this nonsense inside the bullet process function:

float radangle = D3DXToRadian(Angle);
float cosa = COS(radangle);
float sina = SIN(radangle);

Looks innocent, but I actually wrote faster versions of sin and cos that use a lookup table for 3,600 versions of each. So basically my precision there is within a tenth of a degree. I probably left it like this because I worried that the quantizing there would make the bullets look like they miss their target when my sim shows that they hit. I checked with grok:

The bullet could be off target by up to approximately 2.62 pixels when using a sine/cosine lookup table with 1/10th degree precision over a distance of 3000 pixels.

Thats interesting, because frankly none of my bullets are firing 3000 pixel ranges, and being visibly off by that amount is actually ‘no big deal’. Its absolutely not a big deal if the bullet has been pre-determined to miss anyway… I guess I *could* be super-cautious and have a flag where if the bullet will miss, I use the lookup table for its movement, and if not I use real math?

And then this is the point in the thinking process where I realize that all my code is bollocks. Its only when the bullets WILL hit the target that they need to change their angle once shot anyway. In other words, some bullets are (for sim purposes) effectively homing-bullets, and some are not. In other words, not only can I use a lookup table for the angles of non-hitting bullets, I do not even need to recalculate the angle for them at all once they have been fired. Jesus I need a coffee…

Coffee consumed… And now checking that this change (caching one-off sin and cos for missing bullets) works and does not break the game… And it works fine. I am now aware of a much bigger issue: When a bullet expires, it removes its sprite from the list of lightmaps to be drawn in the lightmap code. This is a big deal, because that list may well have 6-10,000 entries. Removing an item from a list that big all the time is hitting performance in this perverse case with thousands of bullets. I need a better solution…

Checking UProf I can see that GUI_Bullet::SetActive() has a cache miss rate of 66%. Thats pretty dire, the worst of the top 20 most processor intensive functions. Yikes. And yet…

2 minutes chatting to grok (XAI’s chatbot) gave me the frankly genius solution: “Why have a pointer to a sprite stored in a list, and then go back later and try and find it. When you add it, store the ITERATOR, and then later when you want to remove it, you already have the iterator ready. No more list searching.

Holy Fucking Crap.

I’ve been coding for 44 years, and its never occurred to me that with a tightly managed list of objects that will have constant addition and removal, and the list may be huge, that its worth storing the iterator in the stored object. Thats genius. Maybe you do this all the time, but its new to me, and its phenomneal for this use case. Not only is GUI_Bullet::SetActive() no longer in the top 20 functions by CPU time, I cannot even find it. Its literally too fast to measure, even with my extreme stress test.

Buy shares in NVDA and TSMC!

Ridiculous Space Battles Design Goals

Posted on May 10, 2025

In case you missed it, I am doing a total re-imagining of Gratuitous Space Battles, 15 years after the first game, and calling it Ridiculous Space Battles. This is a sort-of-hobby semi-retirement project that I have got super into. I thought it worth laying out what I think is to be gained from re-doing the game.

Firstly,. yup its still a 2D top-down game being made using directx9. I know a lot of developers will think it mad not to go 3D, and mad not to use unity/unreal and to use directx 12 or whatever the latest version is (I don’t care), so let me address that first. I do not think 3D games are automatically better than 2D ones. In fact most of the time I think they make a game hugely worse. Having enjoyed the Company of Heroes and Age Of Empires games over the years, I can attest the the fact that when really enjoying the game, rather than posing to get screenshots for magazines, the best approach is to just leave the camera locked and play them as 2D games.

But oh noes! the horror! How can I not want to zoom in and see the game in a first person POV? Well I have the Battlefield games for FPS views thanks. Playing a big strategy game in 3D is just deliberately making things hard for yourself. People who make promo videos may enjoy letting the camera strafe around one of their units because ‘its cool’, but in terms of actually playing the game and working out whats going on? No. Humans are still basically 2D thinkers. Most strategy war games still work best in 2D, even if you want to use 3D meshes and 3d hardware to draw them. I prefer RSB as a 2D game.

As for Unity/Unreal. Ha. Fuck off. No. I do not want to spend these happy hours when I’m working on my dream game working out what bullshit combination of middleware actually compiles or works. I do not want to be begging developers on middleware forums to explain why their API crashes or beg for source code. I do not want a random ‘engine update’ to totally break my game, give me random crashes or just not compile, or trash the performance. I want to OWN and CONTROL all of my code. And the idea of paying a percentage of revenue? LOLZ. Its that real? I cannot imagine people being so beholden to some 3rd party. I’m typing this on a logitech keyboard. They don’t ask for a cut…

So yup, 2D and own-engine it is, at which point TBH the effort of switching to Directx11/12 is not really worth it. DX9 is the ‘sweet spot’ for 2D stuff for me, because I know it inside out and backwards. I could maybe take advantage of some newer API stuff, but the tradeoff is relearning enough code that it would become frustrating and no fun. So no. Besides I’ve made it look quite good just with directx9:

So thats the tech stuff. What HAVE I changed and why? Well basically the big changes are as follows:

Grid based deployment.

Gratuitous Space Battles had a ‘deployment zone’ but let you do pretty much what you liked inside. As I recall I ‘tried’ to prevent you putting ships on top of each other, but people managed to hack it. The result is a huge ‘scrum’ where people stacked massive capital ships into tight bundles. Little dense islands of spaceship that were insanely hard to defeat. Thats fine, thats a player prerogative, but it went against a core design principle of mine: ‘In play, the game should look cool’. When ships overlap it just looks bad. I call this ‘total-war gameplay’. The total-war games always had great setup formations, but once battle was jopined they all just looked like a punch-up in a bar. I hate that. So now ships stick to their assigned grid formations. Except fighters, that can raid ‘ahead’ of the fleet.

Fixed squadron size.

GSB let you have any combo of anything, but RSB lets you deploy units into a grid square. 1 cruiser or 4 frigates or 25 fighters. Those are your options. This simplifies gameplay a lot, and I think 95% of players never adjusted fighter squad size anyway. It also means its super easy to place really organized looking fleets. This also contributes to the ‘huge battle formation’ aesthetic.

Simplified Orders & movement

RSB units have a ton of orders, but they do not retreat to repair, nor are there any escort orders (they are no longer required with fixed formations). This simplifies things, and makes the game more clearly a game of ‘design ships and place them in a group’, rather than ‘chain together some complex orders like you are doing shader programming’. It might allow for less esoteric combos but I think it is much easier to understand and control. GSB players often wondered where the hell half their ships were going and why. In RSB its simple: The lead ship maintains the fleet position, and moves forward as enemies are destroyed. Movement of ships is only on the X plane.

Defend the line gameplay

This is the one I am not sure of. The win condition for the player is to destroy the entire enemy fleet. The lose condition is triggered if any of the enemy fleet makes it to your (left) side of the screen. Its done mostly so you have to have a proper distributed ‘line of defense’ which looks cool, but it might be too arbitrary. I will likely tweak this and solicit feedback from players when the game goes into early access eventually.

So there you have it. I made a bunch of changes from GSB. I will be doing a challenge system online just like GSB. This one will use the latest version of PHP and be way more stable! I have not started work on that yet. There are still a ton of things to be done in the single-player version yet.

By the way, if you think this game sounds interesting, it would be super cool if you added it to your steam wishlist:

Ridiculous Space Battles: how and why?

Posted on May 3, 2025

Its 15 years since Gratuitous Space Battles came out, and when I announced a few days ago that I was making this game, I said I’d been working on it for 18 months. How come? Why not announce sooner? and why am I making it, and why now?

After I made the last expansion pack for Democracy 4, I took quite a bit of time off, because I had the mad idea to build a solar farm. This literally took years longer than it was supposed to, and swallowed up a ton of time, and effort, and caused me an insane amount of stress. Even though the farm has been generating for 6 months, its STILL causing me stress and still not properly finished. To put it mildly, during this time I did not have the energy to actively and publicly be working on a new video game.

Any indie game dev will tell you that it is a super stressful job, and a very very hard way to make money. I can say with experience now that solar farm development is 10x as stressful, so that took its toll and meant there was absolutely no way I would also announce a new game. I simply could not cope with having to deal with people asking me about the game, or asking when it would be done, or telling me it was a bad idea and that I was doing it wrong. I had multiple bouts of screaming and tears over the farm. No way was I going to add more pressure or work on top.

You do not know stress until you have personally financed and managed a project like this. Gamedev is easy.

So as a sort of ‘hobby project’, I decided ‘for fun’ to make a little space shooter game using the assets from Gratuitous Space Battles and its DLC. This was a fun project to work on. I coded it all completely from scratch, with a new engine, because I actually find writing engine code (2D but using 3D APIs) to be genuinely relaxing. I know most people would not agree, but thats me. I got quite into this game, and eventually made it public, and put it up for sale on itch.io and on steam. I’ve since stopped using itch, as they ignore requests to pay developers for months, but you can still grab that game on steam:

Anyway, I enjoyed that enough that I ended up making a proper game rather than a little vertical scroller. The amount of change this early game went through is huge. At one point it was called ‘paint by spaceships’, where you basically had microsoft paint, but with brushes that deployed formations of spaceships. To this day, the game’s project folder is called PBS.

A screenshot of ‘Paint By Spaceships’

That then got changed to a game called ‘convoy’ which was like GSB but entirely about protecting a convoy of freighters from enemy attack. The Visual C++ project for the game is still called CONVOY. That then morphed into a ‘re-imagining’ of GSB, called Ridiculous Space Battles. I had decided to re-code everything entirely from scratch, because I prefer to do that rather than hack and bodge together 15 year old outdated code.

At some point I decided that re-using art assets from GSB was a bit boring, so ended up buying stock 3D art packs and kit-bashing together my own new art for the ships. At this point, solar farm dev was less intense, and I was working 40+ hours a week on the new game. I even spent some actual money on the art packs and some new textures for backgrounds and planets, so suddenly this was less of a hobby and now an actual new commercial game I would release.

I am in a very very fortunate position as an indie game developer, in that I have had a run of hit games, starting ages ago with Kudos, then Democracy, then Gratuitous Space Battles, the Democracy 3 and 4 and Production Line. I also published Big Pharma, and I invested the profits pretty cannily. Thus I made enough money that retirement beckoned. Early retirement no less! what a luxury. I then decided to spend a gratuitous amount of money on a solar farm. I do not know if it will break even yet… but even so, I am in the fortunate position of not *needing* RSB to make a huge income. I do not have to stress myself half to death chasing reviewers and streamers and youtubers. I do not have to manically work 60 hour weeks on it, or beg people for wishlists and bundles and marketing opportunities.

However…

I am now super proud of what I have made. Having a ‘second go’, from scratch, at a game idea from 15 years ago, with no financial pressure is a huge opportunity. Realizing very late that I somehow invented an entire genre (autobattlers) and never really capitalised on that is very motivating. When I look back at GSB, its a very very innovative game, but it was a first-go, and suffered from a load of obvious game design mistakes. Why not right them, and try to make the game GSB should have been? Even if it makes no profit at all, but just leaves behind a game I am proud of, and a small percentage of GSB players bought and enjoyed and brought back good memories, thats definitely a good and worthy thing.

An early design for the main menu

As of today I have not sent a single press release or told any journalists about the game. I am building up to it. The game is actually playable, and looks lovely, and I have a never ending supply of awesome screenshots. I could do a trailer right now, but I am thinking about getting new music for it before them (it currently uses music from GSB, which is…ok, but could be more modern perhaps). I also have no real release date, and a very flexible schedule and design.

I am also really enjoying writing the code for it. I updated from Visual Studio 2013 to 2022, which actually went extremely well. I am sticking with directx9 but pushing it to its limits, and doing it in a way that will be tons more stable than when I attempted it in Gratuitous Space Battles 2, which had technical issues :(. I have way better tools to develop the game now, and 15 years more coding experience. I also am happy to stick with top down 2D graphical style. GSB2 did mock-3D lighting and I don’t think it was worth it. Sticking with simple 2D gives me other options to ramp up the crazy spectacle, and its working well.

I’m already pleased with how the game looks, and it will only get more ridiculous

So yup, expect a lot of technical coding blog posts (and design ones) over the next few months.! In the meantime you can add the game to your steam wishlist now :D