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

Shield Support Balancing

GSB recently got a shield support beam. This was a groovy empire-frigate-only weapon which remotely boosted the shield power of friendly ships. It was criticised as being too powerful. Not surprisingly, people experimented with minimal cruiser fleets boosted by a huge swathe of support frigates using the beams for mutual reinforcement.

Surprisingly, this turns out to actually be super effective in comparison with filling those frigates with weapons and other useful stuff. I spent a while playing, and analyzing player challenges where it was claimed the SSB is just *too* good.

So I nerfed it badly to see what was needed to get the sweet spot for this new weapon. Serious nerfing of the transfer rate was tried. Then serious reductions in the amount that would be held in capacitors. Still, the SSB seemed awesome, in large numbers.

Then, eventually, I concluded that it was the mechanic, not the numbers that caused an imbalance. The SSB was being used regardless of the state of the target ship. It could be under intense plasma fire, and be ECM jammed, and still shake offf all attacks thanks to 6 or 8 SSBs boosting its shields. I wanted a single SSB to be worth having, but at any reasonable level, the combination of 8 then became a super-defence.

So my currejnt thinking (under testing now) is to nerf the SSB by reducing two key stats (beam rate to 20, recharge rate to 20), and also introducing three restrictions:

  1. The SSB can not be used to reinforce ships if the target ship is currently ECM jammed.
  2. Only a single SSB can be utilised on a target ship at any one point in time (although they could take turns).
  3. The SSB can only be targeted on cruisers.

I think this is the solution, but feedback is much sought. After all, I stupidly thought it as balanced already :D Ideas?

Server Downtime

The GSB server, and my website will be down at some point tomorrow for about 30 minutes as physical server moves take place. You can still play GSB then, but not download or upload challenges, rate them or anything similar. The forums will also be offline for that period.

Unavoidable really, unelss you use fancy cloud stuff, and although amazon and google are gerat, I like hosting companies that answer the phone when things go bad. Google aren’t big on that.

Campaign AI stuff

I am working on the various chunks of code that determine the strength of AI opponents in the GSB campaign game (currently being developed). The game takes existing challenge fleets, as well as other players campaign-fleets to use as the enemy, in massively-singleplayer style. However, it needs to select an appropriate fleet, in terms of strength, to fight against you, either as a defending fleet when you attack, or an attack on one of your systems.

The simplest method is just to assign a fleet size value to each planet, and let that be the strength there. Simple, but dumb, because nothing prevents the player sitting back and building up a larger fleet. A refinement would be to gradually ramp up a scalar for the enemy fleet sizes over the game, but that would mean it could spiral into insane difficulty, and doesn’t allow for different skill levels.

A system I’m working on is a ‘reactive-arms-race’ style approach. The nearby enemy worlds have their fixed starting values of fleet strength. When battle is joined, the Ai will start to build up larger fleets in nearby systems when it loses, and not bother if it wins. There will be some lag here, to represent building times.

The idea is that once you think you have a slight fleet-size advantage, you need to get all expansionist and start conquering, before the enemy realsies how mighty your fleets are, and builds it’s own countermeasures. If you just sit back and build up, the enemy will be doing the same. I may introduce an additional ‘anti-turtling’ scalar that starts ramping the enemy fleets up even faster if you have gone a long period without expanding your empire.

All this takes ages to code and test, and you never notice it’s effects on the surface. It is important to get this stuff right though (more important than adding more shiny or features) because it’s what drives long term playability.

Why GSB is not like a normal RTS (deliberately)

Have you seen korean starcraft players?

http://kotaku.com/5580080/korean-gamers-are-faster-than-a-speeding-bullet

fast huh?

Although it’s impressive, and kinda funny, it’s also a bit depressing and kinda sad. I like to see the RTS genre as a mostly ‘S’, and not so ‘RT’. If I was 14 years old, I’d think differently, but I’m not. One thing spending your teenage years learning neoclassical heavy metal does, is to teach you that someone with more free time than you is going to be faster than you. Always.

When I was at Elixir, I worked on a game that got canned, which was like speedball. it seemed to be a really strategic game. The player who won was the cleverest, the most strategic thinking. It played a bit like real-time chess. The reaction-time and number-crunching side of it was minimal, it was an ‘outwit-the-enemy’ style game. I liked it.

GSB doesn’t care how fast your reactions are. You can be 55 years old and have arthritis, you can still design a kick-ass fleet, and a cunning challenge.  I know starcraft is a massively popular game, and they know what they are doing, but you can only really design good games if they are games you personally enjoy playing. I can’t compete in FPS games or arcadeish super-fast RTS games, but I can compete happily in GSB. I also like the asynch nature of online challenges, because it eliminates the asshole attitdue of many online RTS players, who drop connections when losing or mock you during in-game chat,

I met the guys from introversion for lunch today. Had a good chat about games and indieness. It’s always refreshing to chat to people who understand what it is you do, and do something similar.

Crappy windows code

Soo… some people have a bug in GSB where in fullscreen mode, the titlebar of the windows ‘window’ is still there, but invisible, meaning you can accidentally hit the close or miniomize buttons, or worse-still, double click and then ‘maximise’ the already fullscreen window.

I have encountered this a few times in GSB myself. but cannot reproduce it right now. It’s certainly not reliable. And it’s annoying. I would love to fix it. I’m pretty sure its something to do with the windows code that selects either a windows style or windows class.

currently I use:

wcex.style            =    CS_CLASSDC | CS_DBLCLKS;

and

HWND gWnd = CreateWindow(appname,appname,
 WS_BORDER | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX | WS_MAXIMIZEBOX,
 0,0, width, height, GetDesktopWindow(), NULL, hInstance, NULL);

Both chunks of code I haven’t changed in ages. I suspect the code is wrong, but am finding it impossible to find what is ‘correct’. Looking at the directx samples makes me want to cry. In amongst 500,000 pages of incredibly convoluted, confusing, totally over-engineered MFC style bullshit that they call ‘DXUT’, there is a hint that microsoft themselves use just CS_DBLCLKS and WS_OVERLAPPED. The thing is WHY? There is no documentation. In the old days, directx5 used to tell us we need to use WS_TOPMOST or somesuch.

You would imagine that as 95% of people using directx write games, and 90% of them want to, at some point, run fullscreen, that the directx docs would have a line saying “for fullscreen apps, you need to select these options for your window”. No such clues have emerged though.  Another evenings trolling through coding forums no doubt…