Fill out your e-mail address and click submit to join the positech games newsletter!

Pre-order copies on sale (oh my god…) + Manual

Filed under: gratuitous space battles cliffski 9:56 am August 31, 2009

I am so nervous. Normally when I release a game, there is just the distant sound of tumbleweed and a handful of people who give a try after playing the demo. This time I am bombarded at all directions from people who really want to play the game.

If you are that obsessed, skip the rest of this blog post and go grab it now from www.gratuitousspacebattles.com

Some things to be aware of:

This is a beta copy of the game that you are getting. It is not final. There are some bits which I’m not 100% happy with (are we ever?) and I will probably overhaul a few sections of it before it’s actually given a proper release.

The game has an on-line challenge system, and that’s a new thing for me, so expect some teething problems. All of this has been tested, and works, and seems bug free, but you simply can’t plan for the reality of people on-line connecting from all over the world to do stuff with PCs and the interwebs.

You might find some weapons, hulls, modules unbalanced. I’ve played a lot of battles and think it’s balanced, but maybe I’ve never even thought of building a ship with 16 point defense turrets, so didn’t spot what a super-overkill combination that can be. Obviously through the course of the beta, the game will get heavily tweaked and rebalanced.

Finally, this is an indie game, it’s literally a bedroom coder effort, so be gentle on the shouting when you discover something that crashes or won’t work. It’s purely because it’s something that never happened at my end, I will endeavour 100% to fix it as quickly as I can if you have any problems. If you are not happy to try out a beta copy of the game, or genuinely think your PC isn’t up to it, then please don’t get it yet, wait for a demo and the full games release.

I’ll be checking my forums, and blog comments throughout today to see if there are any problems, and explaining any bits of the game that I’ve explained really badly. There IS a pdf manual, and it’s worth flicking through it. In fact, here is a copy for people who want to read it first to see what the game plays like.

Obviously feedback here or the forums is VASTLY appreciated. Hopefully we can get a really good game out of this.

Theres is always something I forget…

Filed under: business,gratuitous space battles cliffski 1:01 pm August 30, 2009

The problem with being a lone developer is there is nobody else to cross-check stuff with. Tomorrow I’ll be putting GSB up on pre-order and beta download, so real paying gamers are going to play it for the first time.
I’m pretty sure I have everything covered. I have the final code working and tested, the website pages are ready to upload. My trusty proof-reader is proof-reading the manual, the payment stuff is all set up. The database has been cleared out of my test challenges…
There is always something that gets missed. I’ll realize it 10 seconds after the first person buys it and sends me an email saying “hey cliff…”

At least I haven’t pressed 5,000 CDs like you would have done in ye olde days. I’m sure a patch will be released in the first week with big fixes and updates. Even if there isn’t a single bug, I’ll be adding new and better graphics for some of the bits I’m not happy with.

I’ve never been this nervous about releasing a game before, despite the fact that I think this is my best game. It comes right at the tail end of sales from my last games, in the middle of a games price-war and a global recession, with me about to move house and suddenly we are 100% dependent on games money to pay the bills. Added to this is the fact that this game probably appeals (at first glance) to the more piracy-prone slice of gamers, which can’t help. The trouble is, I’ve never been able to make games that aren’t exactly 100% what I want to play. I could have made 3 or four diner dash or zuma clones instead of GSB, but I’d just be depressed doing it, even though I’m pretty sure I’d have made a more reliable income that way. People I know who do that are doing very well out of it.

It’s a bit weird (and scary) to think that my ability to buy food next month is dependent on whether people think I’ve balanced the ranges of fusion beams and multi-warhead missiles correctly.

Rendering GSB (geeky details)

Filed under: gratuitous space battles cliffski 4:14 pm August 28, 2009

Here’s something I thought was cool it’s a step-by-step breakdown of a single frame of GSB being rendered (minus the shaders, I had to disable them to be able to do this).
Enjoy!

Finding and fixing some nasty bugs

Filed under: gratuitous space battles,programming cliffski 10:52 am August 27, 2009

It’s amazing what bugs you find when you just sit and play through the game for hours (I’m playtesting and balancing the game so that the AI fleets give you a bit of a challenge).

Two bugs squashed today are these:

Firstly, the code that detected that an enemy target was being ‘painted’ by a target painting laser (and thus easier to hit for missiles) was just not working at all. I’d checked and double checked it many times, but because the ‘is it painted’ code is just one of about 6 factors determining optimum target selection, it was hard to tell if it was working right without stepping through everything each time.

It turns out that code worked fine, but some *other* code which told a targeted module whether or not it even *was* a missile launcher, was buggy, and so the code was never even being run. doh!

The second bug was investigated after I noticed some very slow missiles which looked like multiple-warhead missiles but never split into their sub-munitions. It turns out that this code has never worked correctly! The code works fine the first time a missile splits into sub-munitions, but if it gets to live long enough to shoot another missile later, the sub-munitions are never triggered. That was an easy fix.

Unfortunately, that means I’ve been underestimating the destructive power of multiple-warhead missiles all the time, which means I need to re-play through every battle, on every difficulty, and both re-balance the fleets, and maybe re-balance the cost and strength of the appropriate missile modules too. This will take all of today at least.

Damn :(

One thing I did notice, that was pretty cool was an imperial AI fleet I’d put together that sends its fighters in ahead, and the rest of the fleet shows up afterwards (moving slower). By lucky hap, although the fighters were useless against the heavily armoured federation cruisers, they did manage to blow the crap out of the row of point-defense equipped escort frigates that flew alongside them. So when the Imperial cruisers got into range, they could bombard the feds with missiles without opposition. This is exactly the kind of design and thinking I hoped the game would reward, so it’s cool to see it is all about strategy and not just luck :D (Obviously when you play against that fleet, make sure you don’t have a line of unarmed frigates sitting waiting to be blown up :D )

Challenge!

Filed under: game design,gratuitous space battles cliffski 1:58 pm August 26, 2009

This is the current challenge list screen (click to enlarge). It’s not exactly an MMO quality on-line browser, but it’s what there is right now, at this beta stage of the game. (BTW I’m aiming for pre+orders + beta for pre-order customers as of next Monday).

There are basically 3 types of challenge. Automatic ones, open to all, which get uploaded whenever you beat an AI fleet from the game (these come from ‘auto’), open challenges where a player has posted up an open invite to beat their fleet (sent to ‘all’) or personal challenges sent to another GSB player by username.

Only the target player will see personal challenges you upload. I’d imagine 90% of challenges people play will be the personal or ‘all’ ones, the auto ones are just there to ensure some challenge population is available. I will also be developing some kickass fleets for you all to lose against :D

The browser downloads a list of all the challenges, and you can then filter them using those top buttons. Every time you attempt to fight against a challenge, the ‘Attempts’ is incremented globally. Every time you beat a challenge, it’s ‘Victory’ will go up. You click the download button to grab the challenge from the server and play against it. From then on, that challenge is a local downloaded one you can revisit easily.

I haven’t done the code yet that means only one victory per challenge, per person can happen… must do that!

I must also add a button to only show *your* challenges, so you can check on how many attempts your fleet has had, and how many people have beaten it. Ideally there would be TONS of community based features like this, it really does depend how well the game does, and if people enjoy this sort of thing. The minute there are some pre-order buyers playing the game, I’ll have a decent idea as to where to direct my energy in terms of development.

Thoughts?

Interview and prices

Filed under: business cliffski 10:31 pm August 24, 2009

Just a quick post with a link to an interview I did about GSB and other stuff:

http://www.geeks.co.uk/5841-positechs-cliff-harris-a-life-in-games

I’m trying to sort out pre-order dates and deals at the moment. I’m thinking about selling the game on pre-order for $19.95. Tell me why this is a good/bad price in the comments :D

Raw PIX data for gratuitous space battles

Filed under: gratuitous space battles,programming cliffski 11:59 am August 22, 2009

I’ve never seen anyone share data like this, but I don’t see why they wouldn’t, it’s hardly source code. PIX is a free program from Microsoft that lets you analyze your games directx performance. I haven’t analyzed this data or changed any code yet, but here is a quick 2 minute start of a battle in the game (release build) analyzed with pix. Click the image for a larger version

This is great for working out why you get occasional slow frames, or working out where bottlenecks are. TYhe FPS seems to never go above 60 FPS, because the game caps it there, making a note of the ‘headroom’ available for potentially enabling higher-demand effect (not all done yet).

This is under Vista, 2 gig RAM, Core 2 Duo 6600 2.4 gig CPU and a Geforce 8800 GTS with latest drivers.

Please feel free to comment on how the numebr compare to agmes you might have worked on or develop now. I’d lvoe to see other peoples pix data as a sanity check. Is 83 set textures a frame a lot?  it seems to depend on what else is going on.

RangeFinder

Filed under: gratuitous space battles,programming cliffski 5:25 pm August 21, 2009

In my play testing and balancing sessions, I found myself really wanting to know what the ranges were of a specific weapon mid-battle. You get to see this in pre-battle deployment, but that’s only the initial formation. There is nothing more frustrating than watching your ship sit there, minding its own business while an enemy ship sits just out of range and missiles it to pieces :D I should adjust the ‘retaliate’ AI order to allow it to move within range

So anyway, I’ve added in a new range-display GUI to the battles. Basically you just click on your ship to show the window with its details, then click a module with a turret on that window for it to highlight that weapons range on the map. I’ve toggled on the background grid here for extra ‘tactical display mode’ fun.

The last few days have been really hard work battling an obscure texture corruption bug. I was working on it at 1AM last night. I’ve completely rewritten my vertex buffer code to use a different locking strategy, and I’m pretty sure it’s for the better, although I do too much memory copying for my liking. Still, the game runs pretty fast even so.

Victory Conditions for GSB

Filed under: game design,gratuitous space battles cliffski 3:16 pm August 18, 2009

For a long time the code that checks for the end of battle has basically looked for the first fleet whose number of live hit points as a ratio to its total (damage is ignored, only active or destroyed ships matter) drops below 10%. At that point you lose.
Theoretically you can pull back from 10% of your fleet to victory, but the code is there to prevent the game going on for hours trading shots between two closely balanced fighters.

Some play testing today has made it obvious that there are other clear cases of victory / defeat that need detecting. You may well have played an RTS where it’s pretty flipping obvious whose won, but you have to endure another hour of it. Hopefully this won’t affect GSB.
The new rules include this:

  • If three minutes has gone by without any ship being destroyed, and one fleet is less than 50% of the strength (in percentage terms, not absolute hitpoints*) of the other, then it loses.

also:

  • If one fleet is reduced to nothing but fighters, and the other fleet is not, AND that other fleet outnumbers you by two-to-one in hit points. You lose.

As I code this, I’m wondering if that initial 10% calculation should also be contingent on the three minutes without a ship destruction being introduced too. It should at least consider extending it if it’s a close battle.

This is the kind of stuff that gamers who want to be game-designers think designers do all day. In fact a lot of the time its more obscure crap like “If the player designs a cheap ship, then edits it in the editor and goes back to the deployment screen, but the fleet is now too expensive, do we prune ships automatically? or do we put up a dialog or disable the fight button? zzzzzzzzzzzzzzzzzzzzz

*on expert difficulty, the AI outnumbers you, so this needs to be calculated as a fraction of totals.

New Video, just some new gfx fluff

Filed under: gratuitous space battles,programming cliffski 7:46 pm August 16, 2009

Today is a weekend day, so I don’t feel bad adding graphical fluff. I also fixed a few minor bugs in the UI. Amongst the stuff added was Level-Of-Detail particle emitters for explosions here and there, some new particle effects for minor things like shield impacts, and missiles flares fading out as they run out of fuel.

Particle LODS are interesting, because they only half solve the issue. Not drawing them at lower zooms is all well and good, but each particle still needs processing. Its not enough to assume they will remain off-screen when not being drawn either. I guess I could not update them, and just note the time elapsed, and ‘catch up’ when they are next on-screen, but because they may have moved on-screen during that time, you can get artifacts that way. You can maybe do it for ones clearly massively off-screen.

In any case, having LOD levels for some effects makes it easier to turn them off when the GPU is overloaded, or if we need the time to do other stuff.

This vid was knocked together in 10 mins, so it’s nothing special, but you might like it anyway.

Next Page »