Gratuitous Space Battles did not start off as a hybrid management/simulation/strategy space combat game. In fact, it started off as a turn based 'dictator-simulation' back in the dark days of 2008. In November 2008, I was starting work on the next game after Kudos 2, and had decided to do a game that was similar to Democracy, but from a dictators point of view. A sort of 'Virtual Saddam' game. It only took a few weeks of writing code for this for the game to strangely morph into a totally different direction, and before long I was working on a space strategy game. Thankfully, as an indie developer who self-funds, I can do this without having to get anyone's permission, or go through endless design meetings. Gratuitous Space Battles was born, but the name wouldn't be picked until February of the next year. In it's early days, like most games (even AAA) ones), GSB was put together with 'coder art', while the very basics of getting moving and firing ships was put together. Initially, the game looked like this:
Thankfully, it didn't stay like that for too long. Initially, I clung to a lot more of the typical Real time strategy game UI decisions that crop up in every game, meaning ships even had health bars over them (separate for hull and shields). This always looked pretty bad:
I also experimented with a 'burn' effect that is a cheap and easy way of getting glowing style images. The idea was that the game was not a real-world visual image of a space battle, but more what an admiral commanding the flagship might see on a tactical screen, similar to the view used by the klingon captain at the start of 'Star Trek: The Motion Picture'. This also made it look a bit too similar to the style of Introversion's games, and although I initially liked it, I'm glad I went in a realistic direction instead.
Once I'd settled on an art style, I had to make that difficult indie-developer decision of whether or not I really needed to employ an artist, or whether I could buy stock images. Obviously, employing an artist to do original art would look better, but how much better? Did I even have the money to pay them? (My income from earlier games was dropping every month, and this game was not about to go on sale any time soon). I at first experimented by spending a few hundred dollars on stock spaceship models and tried them in the game:
Obviously better than coder art, but not good enough. Most stock 3D models are done for 3d games. With a 2D game that used 3d models as sprites, I could push the poly count off the scale, so I needed an artist that could do incredibly detailed work and ideally, one who specialized in spaceships. There are a lot of generic artists and musicians out there, but I always think that its best to pick the very best person for the current job. Often that means using different artists for different games. I got quotes from 3 artists I liked, and after a lot of nail biting and looking at bank statements, eventually decided to go with the most expensive one. I don't regret it at all.
The art styles for the ships evolved as they were made. The first fleet was the federation, then rebels, then the alliance, and finally the empire. Later, the Tribe would appear in an add-on for the game. The original design for the alliance ships was actually influenced by biology, rather than anything from sci-fi movies. I sent a bunch of different pictures of microscopic organisms to the spaceship artist and asked for space battleship versions... That was the spaceships sorted, and I always knew that I'd be doing the special effects gfx myself (the explosions, tractor beams etc). I still needed graphics for the hundreds of ship components, and a logo and UI. For cost reasons, I had to do all the module gfx myself, which took forever, and was less than perfect, but for the user-interface I got a UI expert (Chris Hildenbrand) to do a decent UI for me to use
That was the artwork sorted, but I still needed a decent game design! Initially, the flow of the UI was rubbish. The player designed fleets on a different screen to the one in which he/she deployed them, which was insane, and hard to explain (even if it made for less cluttered screens). This was pointed out to me at great length by fellow indies after taking a look at the unfinished game. (I'm not sure activision do this with EA, but indies do) A good long rewrite of the UI sorted this out, and the game was in far better shape.
Of course, it's very true that the last 10% of game development takes the other 90% of the time, and that was very true with Gratuitous Space Battles. When I thought the game was finished, it was far from it. The screenshot below shows the original ship design UI. From a distance it looks the same, but at least 50 things got improved steadily on this screen, from better text edit boxes, to extra buttons to show more data, to sorting of data for better usability, to newer module background graphics, better tab buttons, and countless other minor tweaks.
This, of course only covers the UI of the game, which in something like GSB is vital, but also in code terms, pretty trivial in comparison with the graphics engine powering the thing. Although its commonly thought that 3D graphics are hard, whereas 2D graphics are easy and you don't need to optimize them any more on modern PC's, this is (to be frank) complete bullshit. It might be true if you are making a match-3 game, but if you have 300 spaceships per side, with damage textures, engine trails, flashing lights on wingtips, drifting space hulks, debris, explosions, missile trails, fancy shader effects, shield glow and impacts, cloaking devices and tractor beams, with parallax scrolling starfields, zoom and pan, a UI layered on the top, variable game speed and pause, sound effects for every weapon..... and all the AI for target selection and damage calculation for those ships in real time, then suddenly optimizing becomes your full time job.
I spent a huge amount of time minimizing the amount of texture swaps and draw calls used by the game. The old graphics engine I'd used for earlier games was not up to the task and was junked, and an entirely new Directx9 engine was written for Gratuitous Space Battles. The engine isn't generic at all, it's purely designed around GSB, with all kinds of special case code to handle certain scenarios. For example, when bullet are drawn, they are drawn as a big group, to speed up rendering. This puts them *above* all the ships, yet because of the way the images work, and the need for them to be seen to emerge from a laser cannon, they need to be drawn underneath the turret that fires them. This means the first few frames of each bullet get drawn one way (under the turret) and then after this they get drawn another way. Similar hi-jinks take place for fighters that normally fly over a ship, but fly under it when they dock at a carrier. Oh the joy of programming :D One of the things that makes all this 100 times worse is the ability to freeze-frame and slow down time in the game. Unlike a FPS, I can't get away with a graphical glitch for just 1 frame. The player may well be zoomed in and focused on it. Needless to say, I spent weeks zooming in and freeze framing to spot anything that looked bad.
Eventually it was time to actually release the game. I was also a bit nervous of the online 'challenge' system which I suspected would not be used much (oh how I laugh now). I actually coded in a bit of a cheat to compensate for it, whereby if the player was already online, if they beat ANY singleplayer battle in the game, that would get uploaded as a challenge silently to 'everyone'. That way, the challenge list wouldn't be empty and the game wouldn't look like a flop. I was very happy to have to patch that 'feature' out very soon, and before long I had to rewrite the challenge code to handle the problem of downloading list of over a thousand challenges to select from. This is a great problem to have. Originally the game went on sale as a pre-order from my website, which was great for getting feedback from real paying (and thus brutally honest) gamers, and also allowed me to pay the bills without panicking and rushing the game into 'finished' state. The pre-order period went on for a few months and gave me an opportunity to really polish the game so it would come across well in it's first reviews. During this period, I moved house, and turned 40, and went to GameCity Nottingham. This was all intensely busy, and how I didn't have a nervous breakdown is quite a miracle. Despite the ensuing chaos, the games release actually worked pretty well, despite that day when everyone's copies stopped working at midnight due to 'error 31', a pre-release timeout I'd accidentally left in the game. Ooops. And that press release that got sent in black text on a black background didn't help. Very spinal tap...
Not long after the game going on sale, I managed at last to get it on sale through steam (my first game to do so), which boosted sales and was very welcome. I was also very pleased to see it selling well on Stardocks' impulse system, as I'm such a huge fan of the GalCiv games. I still think they should let me put Drengin ships in the game :D. Post-release, i continued to patch and improve the game (and still am), and currently there have been 31 patches to the game, mostly improving and adding new features, ships, gameplay modes and effects. Thankfully the game was designed with a built in auto-patching feature. GSB has been my fastest selling game ever (although at the time of writing, sales aren't so hot), and is definitely the most polished, complex, and hardest to make (as well as costing more then any of the others in terms of artwork and other development costs). It's currently the game I'm most proud of, and the first game I've made that looks good in video and screenshots (the others are good when you play them, honestly!). I think it's fair to consider GSB a successful and even slightly profitable PC-only game, which is a rare thing these days. Cliffski. |
||||||||||||||||||||||||||||||
