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

Ridiculous Space Battles Progress

Ok so, I know this is probably not a big deal, or a new thing… but I have spent so long with this blog casually embedding youtube video links, that it took until today in 2026, and my desire to do what I can to de-couple my life as much as possible from US tech companies for me to discover that you can just natively embed an mp4 in wordpress! So anyway… I present the new race-selection screen animation effect in Ridiculous Space Battles!

and yes… before you comment, I know there is a bug with a texture changing wrongly when I scroll to the left. I’ll fix that tomorrow! I am however, pretty happy with this code, and this look. Coding stuff like this is harder than it looks, because to have everything seem smooth and crisp, you have to basically render all of those windows to an offscreen copy (with alpha) and then copy them as scaled sprites to the screen. That sounds simple, but its a lot of management, as you keep swapping render targets, and have to very smoothly transition from ‘offscreen pre-rendered sprite’ to proper rendered and full featured window.

Trust me, its a pain. It took a whole weekend. Well… it took all the hours I worked this weekend (which was not a lot TBH…). Anyway, that is one new thing that is in Ridiculous Space Battles. Another change was the re-colouring and some adjusting of the deployment screen to make it more user-friendly and less BRIGHT COLORS:

This definitely looks better. You can also see that the range indicators from my last blog post are in there with less angry colors too. The next big thing on my list is to balance the various weapons, and in fact before that, I need to code systems that really quickly run a lot of battles super-fast for me to gather stats. That will be a whole rabbit hole of code, but should be fun.

So to recap, the things left to do before early access or alpha-testing are to balance the modules, to put together the campaign fleets, to test the campaign, and to implement and test online challenges. No doubt lots of bug fixes and optimisation to do too, but I love the optimisation bit :D.

Deployment Range UI for Ridiculous Space Battles

I have been a bit quiet on the blog front, but in case you were wondering, yes I am definitely still working on Ridiculous Space Battles! Right now I am thinking about the ship and fleet design for the campaign game, and this is forcing me to think more about the usability of the deployment screen.

For a bit of a history lesson, here is the deployment screen from the original Gratuitous Space Battles:

There are so many things wrong with both the style and the layout I do not know where to begin, but given GSB was the first auto-battler, there was both no competition, and no other examples to be inspired by. Anyway, one of the many bad things about this UI is those circles around every turret on every ship that were supposed to show the player the weapon ranges, but in fact just look like a confused mess. Here is my current version of the same screen in Ridiculous Space Battles:

I think its so much better… but specifically I am working on the range and fire arc overlays. They only show for ship(s) that you have selected, and one of the changes I have made is to color code them as red for short range weapons, white for mid range, and green for long range. Like *anything* in game UI design, there is no perfect answer here. Red for short and green for long feels right, as long range is generally good (assuming everything else is equal). Making mid-range yellow might be a step too far in mirroring those order strips to the right, so I decided to go with white…argghh…who knows!

The problems arise a bit once you have a bigger battle and with multiple ships selected:

Now the red is showing the combined overlay of the short range fire arcs for all selected ship weapons. Be aware a ship might have 7 different weapons, and could be in a 4-ship or 25-ship squad… Its a complex thing to visualise, but its getting better!

In addition to fiddling with this overlay UI, I have also been improving the ‘ship role descriptions’ that are shown as tooltips for a ship design. I’m basically approaching the problem in 3 different directions. Select a ship…and the overlay should show you its weapon ranges on the map. Select a ship-type at the top-left, and then hover over a weapon name, and you get that big tooltip (see the one for ‘Plasma Stream’ above), which lists everything, including range. If the range is especially low or high, it gets a colour (red/green) highlight. Thats true for shield and armour penetration too…

The thirds method is the mouse-over tooltip for the ship types in the top left ‘ship-picker’. The game analyses all ship types and gives them various descriptive tags (I call them Roles in code). Those might be ‘Mixed Range Weapons’ or ‘Anti-Armor’ or ‘SuperWeapon’, or a bunch more.

My goal is to be able to help the player remember which ship design is which, so they are not just blindly spamming down a bunch of ships and hoping for the best. Ideally you have some short range ships serving as tanks at the front, absorbing enemy fire and shooting down incoming projectiles, then deeper ranks are mid-range and long range, or ships with shield support beams. Choosing the right formation and deployment should be a big part of the game.

Anyway, thats what I’m working on right now. The list of stuff to do before Early Access release does keep getting shorter (I think). Anyway, don’t forget you can wish-list the game at https://store.steampowered.com/app/3607230/Ridiculous_Space_Battles/

Designing the orders system for ridiculous space battles

Yikes, this has turned into a really complex and confusing beast. I am very happy so far with the improvements, but I need to publicly brainstorm the details. Simply put, the orders system in Gratuitous Space Battles was a mess, and I needed a much better one, PLUS I wanted to add new orders to take into account the new gameplay style of Ridiculous Space Battles.

In GSB there was a whole bunch of orders, and they all apparently pretended to work together to come up with an opinion on which ship a weapon should target. Orders are per SHIP, not per weapon, which frankly is a whole other story, but I think it would be stupid overkill to have the player assigning different orders to every weapon. My whole unique selling point is BIG fleets with LOTS of ships. Anyway, the original game had orders like Attack Fighters and Co-operate, but it was never clear how they all worked together.

RSB introduces three new orders entirely. Raider (race ahead of the fleet up to a given distance to engage enemies) which is used by Fighters, Last Defense, which concentrates fire on the enemy ships that have got the furthest through our lines, and Breakthrough, which is for punching a hole in enemy defenses, and only fires on ships right in front of you (or in that row anyway).

Here is my new current implementation:

So the big things here are categories, color coding and priorities. OH YES. To explain, this ship has one ‘Special’ Order, which is to engage enemies at 2 squares range. Thats a movement order, so independent of all the targeting stuff.

The next order is ‘co-operate’. Its one of a class of (blue) orders I’m tempted to call ‘Discriminators’ or ‘Tie-breakers’. There can only be ONE of these (Co-operate, Vulture, Retaliate, Breakthough or Last Defense), and essentially they are used at the end of the process to choose which out of a series of potential targets is picked.

The Green and yellow orders are Target Criteria. They describe a target size class or a defense status (shields up, or shields down but armor intact, or down to naked hull). These orders are special because they are in priority order. (I realize now I should show the numbers!). So when the ship decides who to shoot at, it first builds a simple list of all enemy ships in range and fire arc, that match any of those criteria. (You can delete one to make the ship NEVER target those ships). Once that list exists, it then goes through the target criteria from top to bottom seeing if any ships meet that criteria…

And this is where I have a decision to make…

I can either stop the processing once it has one or more targets, then pick the best using the discriminator OR I can then keep filtering down through the list as long as I have 1 or more targets and THEN use the discriminator. I cannot decide which. Are you confused? I suspect so:

Example 1: Using the above orders, I scan my target list and find 4 cruisers and 12 frigates in range. All of them have shields. Cool! So I stop there, and evaluate them all using Co-operate, firing upon the one that is the most under fire right now.

Example 2: I scan my target list and find 4 cruisers and 12 frigates in range. All of them have shields. The NEXT criteria is Fighters. There are none in my list so I ignore. The next is armor. All 16 have armor so again I ignore. The next is Frigates. Wait! only 12 are frigates, so I prune the list. The next is Hull, all check. The next is cruisers, none found. I finally use co-operate to evaluate which frigate to fire at…

Is this dilemma even making sense, let alone deciding on a system? Its very involved. My game IS a complex strategy game, but I don’t want to rely on crazily complex tutorials. Now to be fair, Gratuitous Space Battles had a completely opaque system that nobody understood and was poorly explained and it sold a bazillion copies, so maybe I am overthinking it. But I would like to do a MUCH better job… I know SOME players would be happy to literally write code to control this stuff, and might suggest I add conditional clauses and other complexity but I think that makes the game seem more like work and less like fun…

Looking at it now I KNOW I need to add priority numbers to those yellow/green strips. Maybe they should be called Filters now Criteria? Who knows. I may need to think about this a LOT.

By the way add the game to your wishlist :D Or pester a news website to cover it! Or share a screenshot somewhere you hang out. That stuff all helps :D.

Is this game you designed actually any fun?

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?)

Ridiculous Space Battles Design Goals

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: