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

Category: gsb2

A video game budget breakdown: Gratuitous Space Battles 2.

Indie developers, especially ones working on their first game are always very interested to know how much stuff costs, and whether they should spend more money on X or Y. It can be a bit intimidating and scary when you have no idea what you are doing and its your first game. To try and help with this, I thought I’d release some data about the last full game I shipped as the developer, which was Gratuitous Space Battles 2. For those who aren’t aware, its a top-down 2D space strategy game with more lasers and particles than you can shake a stick at, and it looks like this:

Image4

Or in video form like this:

Anyway, here is a pie chart breakdown of the cost (EXCLUDING MY CODING TIME) for Gratuitous Space Battles 2.

b1

And for those who hate marketing, here is the same chart but without any:

b2

Obviously you have to strongly remain aware that there was a LOT of coding time by me which I have not included here, because obviously as the owner of the company its hard to work out how much I should value my own time at. Regardless of this, maybe some people find this useful;. If you want more insight into why the costs are the way they are, you probably need to check out the game. GSB2 is a VERY GUI and visual-effects intense game. It has a lot of very complex GUI elements, and thats why its such a big chunk of the cost. It also has very good dramatic music. If you are making a 3D game, costs might be different. If you are working on mobile or ipad, again it might be different. This was a hardcore PC strategy game designed for huge monitors and hardcore players. How does this budget breakdown compare with yours? Share in the comments :D

Indie game developers move on. Or they fail.

I’ve been asked if I am still working on Gratuitous Space Battles 2. And I am not. I’ve been accused of all sorts of stuff as a result. I wont repeat that here. What I want to talk about is the economics of this question, why people get angry, and why it makes sense that I am not working on Gratuitous Space Battles 2 right now.

First some facts. GSB2 started work around November 2013. It was released on the 16th April 2015. So the dev time was about 17 months.

Now the game was in beta for a while before release, with sales from my site, and is on sale also at GoG and the humble store, but most people wont have any idea how well it sells on any of those, so lets just look at the steam sales as reported by steam spy:

Owners 10,876. Assume average of 50% off maybe? so assume $10 a copy? so lets say it made $108,000 and add in another $50,000 from other sources. However steam take their cut so thats really only about $120,000. Actually thats a bit shy of the real figure, which is just over $150,000. So I guess some people (mostly kids) are screaming at me at this point for being a greedy scumbag and so on, because I am implying the game failed or I can’t afford to keep working on it.

screenshot_14-08-2014_12-40-20

The development & marketing cost for that game was $115,000. The *profit* so far is about $40,000. If I look at the hours I spent working on it, I earned about $12.74 per hour. That is assuming I stopped work on it when it shipped, even though I did not, and continued to add patches, fix bugs, add new features and polish existing ones for months after release. Something that made zero economic sense.

If you think $12.74 an hour is good for a software developer with more than twenty years experience you are flat out wrong. If you think that you can run a business in the UK earning £17,549 which is the sterling equivalent, you are flat out wrong.

Gratuitous Space Battles 2 failed, partly because it was released into a sea of space strategy games that are so numerous I cannot possibly list them all. I still think its a darned good game and am very proud of the engine that was coded for it. I think it is superior in every way to the game that came before it. I’m sure it will continue to earn some money in the long run on steam, but not nearly enough to make it anything other than a relative flop.

screenshot_14-08-2014_12-29-05

And yet…people will still hurl abuse at me for moving on. Of course I am moving on, that is why I am still in business, and that is why I am able to pay the rent for the server on which this blog post resides. Some games are hits, some are flops. Almost all indie game studios have flops and it normally puts them out of business.  I am not asking for any sympathy, I do not want any, I am not blaming anyone but myself, and …oh for fucks sake, why even bother typing any further, as I know I will get nothing but abuse and vitriol for even posting this because many teenage gamers think that I should be working from now until my death bed to implement every possible idea, tweak, or change that they can imagine for the game because they paid $10 for it once.

That makes no economic sense, and when you harass and bully and scream at the devs of ‘your favorite games’ to do this, all you do is accelerate the date at which they go out of business and stop making games. If there is a way to turn off comments just on one post I’m going to do it here, but I expect abuse on twitter and so on anyway. Apparently thats what you have to put with for $$11.74 an hour in 2015.

FWIW positech overall is doing just fine, I’m developing a new game and publishing others. I am also personally fine, I just know many devs feel this way but are too scared to say so, I’m doing their venting for them :D

 

Coding the GSB2 Radiation effect (directx9 C++)

I was never 100% happy with the radiation effect in Gratuitous Space Battles 2, so I’ve coded a better version for the next patch. Here it is in very short silent video form:

I thought maybe some people may be interested theoretically in how it is done. Now I’m sure if this was in 3D in unity there is already a 99c plug-in that does it without you even having to understand coding, but thats not how its done so here we go…

The first thing to remember is that the spaceship is not a 3D mesh at all. its a series of sprites rendered to different render targets and then composited. That means that I’m not wrapping a texture around a mesh, but drawing one sprite on top of another, but cropping the final output to the alpha channel of the base (ship outline) sprite.

Before I learned much about shaders, I had a system that did this using mostly fixed function, which I use here, but build on with better shaders to do more stuff, making it a hybrid approach and fairly complex :D. To simply draw one sprite on top of another, but use the alpha channel from the bottom sprite, I use a custom vertex format that has 2 sets of texture co-ordinates. One set is from the splatted image ‘radiation’ and the other is from the alpha channel of the ship outline.

It gets a bit fiddly because where I’m drawing the splat sprite could be anywhere on the ship, so I need to work out the offset and dimensions of the splat in relation to the ship image, and store that in the second set of texture UVs, and pass that into a shader.

The shader then simply reads the color data and alpha data from the radiation splat, and multiplies the alpha by the alpha at that point on the base ship texture, and voila, the image is cropped to the ship.

But thats a very simplistic explanation because there is more going on. To make things fast, all of my radiation gets drawn together (to minimize texture / render target / state change hassle), so its done towards the end of processing. In other words, there is no painters-algorithm going on and I need to check my depth buffer against this ships Z value to see if the whole splat is obscured by some nearby asteroid or debris. That requires me passing in the screen dimensions to the shader, and also setting the depth buffer as a texture that the shader can read.

So that gets us a nicely Z-cropped image that wraps around the ship at any position. It also fades in and out so we need to pass in a diffuse color for the splat sprite and calculate that too. We also have to do all this twice, once for the splat, and once for the slightly brighter and more intense lightmap version, allowing the radiation effect to slightly light up areas of the ship hull during final composition.

At this point the shader is a bit complex…and there is more…

I wanted the radiation to ‘spread’, and to do that, I need to splat the whole thing at a fixed size, but gently reveal it expanding outwards. To do this I create yet another texture (the spread mask) which also gets passed to the shader. There were various ways to achieve this next bit, but what I did was to ‘lie’ to the shader about the current UV positions when sampling this spread mask. Basically I calculate and pass in a ‘progress’ value for the spread, and I use that, inverted, to deflate the UVs of the source image (which is CLAMPed). So effectively my first UVs are -4,-4,4,4 and the spread splat is a small circle in the center of the splat, expanding outwards to full size.

Because I’m only doing this when I sample the alpha channel from the spread mask, the color and alpha data from the base ‘splat’ texture remains where it is, so it looks like its a static image being revealed by an expanding circular (but gaussian blurred) mask.

I’m pretty pleased with it. The tough bit I’ll leave for you to work out is how that works when the source radiation image is actually a texture atlas of different radiation splats :D

Fun fun fun.

 

 

Gratuitous Space Battles 2 Updated to 1.38

A long list of fixes, tweaks and improvements this time for Gratuitous Space Battles 2. Here is the full list:

Version Release 1.38 July
==========================
1) Fixed bug when toggling between fleets in a custom map, where the player fleets icons would not re-load.
2) Fixed bug where ship components that spun are were not composites ignored applied custom textures.
3) Fixed bug where textures may display wrongly in some cases on the ship design screen.
4) Fixed bug where green ship running light did not appear.
5) F2HullMod 8 can now be colored correctly.
6) Zyrtari ship components now ordered correctly.
7) Fixed bug where the game could crash if you beat the first campaign mission when trying to autoload the next one.
8) Point defense beams now oscillate wildly around missiles traveling too fast for them to intercept.
9) Weapons that deliberately do zero damage (like decoys) no longer qualify as least damage done in the post-battle stats.
10) Contrails now correctly drawn even on complex multi-layer fighter & gun ship designs.
11) Ship module comparison window now shows extra data for shield penetration vs resistance.
12) Point Defense weapons now display tracking speed.
13) Missile modules now display missile speed.
14) Balance Change: Frigate/Destroyer Anti-fighter missile Range boosted from 800 to 900.
15) Balance Change: Frigate/Destroyer Anti-fighter missile Damage effectiveness changed to 100% vs Hull, 25% vs Shield.
16) Balance Change: Frigate/Destroyer Anti-fighter missile Firing interval reduced from 2900 to 1500.
17) Fixed text spillover on the messages screen.
18) Added new feature: messages in your inbox now contain a button to jump to the challenge if appropriate.
19) Added new window that shows effectiveness of point defense weapons vs missiles when you select the tracking attribute for one.

The ones in bold are the ones I think really matter. These are things that make the user experience of the game so much smoother. Making comparisons between modules and selecting the right tool for the job just got a lot easier. Since this patch uploaded I’ve been working on a fairly ambitious change to the way shields are drawn, and it looks like it just cannot be done, but its helped me find and fix some other minor graphical glitches as I do it, so hopefully its not time wasted. I may do a long technical blog post about what I was attempting and why it didn’t work at some point.

In the meantime you can grab the game from the link below:

buy_button

In other news Tim is still beavering away on the code for Big Pharma, you can read about the upcoming patch for the game which includes patents and custom games over at his blog here.

 

Gratuitous Space Battles gets Custom Textures

*note, only the windows patch is live at the moment, linux & mac updates are in progress.

I just released version .136 of Gratuitous Space Battles 2. The changelog is this…

Version Release 1.36 July
==========================
1) Fixed potential random crash when first starting a battle.
2) Balance Change: An across-the-board 30% boost in the hit-points of all frigate modules.
3) Balance Change: Double the damage of frigate anti-fighter missiles from 9 to 18.
4) Balance Change: 50% boost for the damage from a frigate flak cannon from 5 to 7.5.
5) Balance Change: 50% Boost for the beam power (time it can stay on) for both frigate tractor beam variants.
6) Balance Change: Increased the tractor beam recharge rates for frigates by 25%.
7) Balance Change: Increased the thrust of all frigate engines by 25%.
8) Balance Change: Increased the shield pen of Heavy beam laser for frigates to 15 so it can now do damage to all frigate shields but plasmatic, and also damage light cruiser shields.
9) Balance Change: Increased heavy frigate plasma shield penetration from 19 to 23 so it is also a viable option to damage cruisers with heavy shields.
10) Fixed campaign bug where you could re-deploy already deployed ships.
11) New Feature: You can assign custom textures to any part of a ship, even modded textures, and include them within challenges, using new right-click option.
12) Holding down shift now allows for pixel perfect ship design movement using the arrow keys.

But the most exciting bit is the new ‘custom textures’ feature. Its so exciting I made a video about it. I might one day write a play about it, or compose an opera. For now, here is the video: