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

Category: programming

How to stay motivated whilst programming a game

Posted on July 2, 2010

Lots of people want to know the answer to that question. Most indie games fail. Most indie projects never get completed. I don’t have any way to prove that, but any indie game veterans will know it’s true. Here are my top tips. Some of them may seem like they de-motivate, rather than motivate, but I get motivated by knowing how important and serious it is for me to work hard. Most indies don’t realise how hard they are going to have to work, and how good their game has to be.

1) Code something you like.

Just because you did your research and can prove that a poodle simulator is the best choice for the current games market, doesn’t mean you want to program one. You might kid yourself that you can see it as a ‘mere engineering challenge’, but you won’t. Getting out of bed when nobody forces you to, with no deadline and no boss, to go code poodles probably won’t motivate you for a solid year. Pick something you are passionate about. I love sci fi and space battles, so making gratuitous space battles was a no-brainer. On a related note, save up some ‘fun’ coding for when motivation is low. Feeling keen? code the save game system and the options menu. Get them out of the way.

2) Surround yourself with inspiration

I listen to music from star wars or star trek when coding easy stuff or doing art. Coding scrollbars can seem dull, but the music reminds me these are spacefleet scrollbars and that makes it ok. The people who play your game won’t see the code, only the art and the game, so keep a picture of the final ‘atmosphere’ of your game in your head all the time. Does your pc desktop wallpaper not reflect the mood of your game? why not?

3) Keep a log of what you did each day.

Sometimes its easy to think the day was wasted, that nothing got done. I have lists of things to do for my games like this:

  • Fix bug with plasma torpedoes
  • Resize scrollbars
  • Add tooltips to buttons
  • Add transition to options screen

At the end of the day my log looks like this:

  • **DONE**Fix bug with plasma torpedoes
  • **DONE**Resize scrollbars
  • **DONE**Add tooltips to buttons
  • **DONE**Add transition to options screen

And that makes me realise how much I got done. You get a tiny adrenaline rush by crossing things off a todo list. Make one each day. Make the entries small, simple items, rather than huge projects. It should always be possible to cross something off each day.

4) Do some shiny

Mr Spock would code the entire game engine, get the gameplay balanced using just coder art, then add the graphical fluff last, to minimize re-doing work. I used to assume that made sense too. I used to rail against Lionhead for having so much artwork, code and music done before we were even sure how the game played. So much work got thrown away. Now I realise it’s important for your motivation to have something that looks and plays nice ASAP. The GSB campaign add-on hasn’t got all its gameplay coded yet, but theres a gratuitous map-zoom effect in already, plus background music. Having those things there keeps me positive about how cool the final game will look. There really is a good reason to code some shiny stuff in the first 25% of your project. Just don’t go mad.

5) Hard lessons in money

I gave a talk at a conference recently about the reality of indie games as a business. To be short and sweet, you need to sell a full-price game direct to a customer every 45 minutes, or you probably won’t make a career as a  full-time indie. That means at the very least someone grabbing your demo every 240 seconds. When you keep this in mind, you realise you need to make your game really good. Better than it is. You need to do better, just to survive in this market.

6) Stay aware how high the bar is (know your competition)

Don’t forget that for most gamers, the competition isn’t other indie games, but AAA games, or even other activities, TV, movies, etc. When I worked on the battles for GSB, I spent very little time looking at rival games, and virtually no time looking at indie space games. I compared it to the best sci-fi battle scenes I knew of, by ILM. Yes, you have to pick your battles, and graphics might not be one of them. Spiderweb compete on game length, Dwarf fortress on gameplay depth. Whatever it is that you are competing on, you need to ensure you aim as high as you can. Also remember that your game isn’t measured against the best game there is right now. It’s measured against the best game when your’s gets released…

8) Take short breaks.

Get away from the PC for a short while, so when you come back, you are fresh, keen and energised. Physical activity is a good idea. I do archery now and then. It’s ideal because it involves standing upright, concentrating on a distant object, and 100% focus on what you are doing. It’s the perfect sport for desk-bound geeks

===

Staying motivated is hard. Everyone has the same problem. Often, its the deciding factor between getting your project done or not. High motivation trumps everything. There are indies making games who are homeless (yes really) and who had to make them ‘undercover’ in Cuba. They still got stuff done. Lack of experience, lack of money, lack of time, can all be overcome by sheer bloody determination, if you can summon it. Now stop reading this, and type out tomorrows todo list.

Crappy windows code

Posted on July 1, 2010

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…

Better Smoke Clouds

Posted on June 23, 2010

Sooo…

On my list of stuff I think looks not good enough, for me to improve when I am ahead of schdule and ‘treating myself’, is the black smoke clouds left behind when ships explode (mainly cruisers). They always looked a bit poor, and were just a handful of big sprites that rotated and faded in and out.

I’ve spent a good few hours investigating techniques and ideas and ended up with this:

Looks better in motion. Despite a lot of reading about fluid dynamics and mega-particles and other stuff, I ended up just using spinning sprites again, but this time with tons of refinements, in terms of different sizes, generation delays, greater sprite contrasts, and using sine waves to control spin speed degradation, sprite size growth and also now have 2 distinct groups of them in different size distributions.

I also experimented splitting them into layers so ships could fly through the smoke, underneath half of it, but it looked a bit wishy washy so I junked it. There is some extra fillrate involved in doing this, but I don’t think GSB is maxxing out many video cards right now, and this does look better to my eye.

Also, retreating now works 100% in the campaign game. Just need to have a visual retreat countdown timer and some tutorial hints for it now.

Unhappy with lighting stuff

Posted on June 21, 2010

I did some campaign stuff today, but also tried to finish off my weekend stencil buffer fun, had a brief flirtation with shadows, and got loads of stuff working, but was not happy. Basically my plan was to be able to take an image and draw it so it only appears on the ships. This would work for light sources, as well as shadows.

It worked! using pixel shader version 3, mind, but that would be togglable. The downside is, it looked crap, mainly because the ships are just sprites, and shadows therefore just splat over them rather than ‘rolling’ and it looked fake, and maybe worse than none. The lighting glows stuff looks better, but still bad. Using normal maps for the ships is theoretically possible, but insane amounts of grief, especially because it wouldn’t work on the turrets without re-doing them all. Bah.

Here is how it looks, if you can even tell. There is a brighter light glow around the laser bullets, as they move over the ships.

It sucks, and I am determined to get the game looking better than this. Also looking at other potential effect improvements…

Todays Bugs

Posted on May 13, 2010

I found a bug today, after it was reported by a few GSB modders. I had done some cunning optimisation for my file handling months ago, where my Ini File loader code kept a file open during it’s lifetime in case another section from the same file got read soon afterwards.

It turns out that the C Runtime barfs if you try to open more than 512 files, under all circumstances. This is fine until you mod an extra 300 modules into GSB, then it just dies. So… problem fixed. Ideally my ini file code should be able to handle this better entirely, but thats for another time,

The second ‘bug’ is still underway, (point defence modules appear to not respond to damage, but in the debugger, they clearly do…) but its pointed me to a third one, that was also reported…

When a point defence beam shoots a missile, it may not work. The missile may be unharmed. In this instance the missile is still ‘claimed’ by the PD module until it dies, so no other PD module will have a second go at it.

I could fix this trivially, it’s just an oversight*. But would that make PD too powerful? It’s already prety good, albeit some of it’s thunder has been stolen by the Swarms Smart Bomb. It’s only going to kick in where you have a few incoming missiles and multiple PD modules. But that second chance to fire could save you from that vital pesky megaton missile, or Order nuclear bomb…

Thoughts?

*easily explained though. The neutron power surge generated by the point defence beam temporarily blinds the targeting mechanism of other PD modules from homing in on the positronic flux decoupler on the same missiles.


Edit: actually the PD bug is now fixed, making them fire much slower as a result, so I’ll fix the multiple-attempts  bug to compensate. it also turns out that the fire-Interval for guidance scramblers is misleading and not applicable, which explains its strangely high effectiveness, so that will be nerfed slightly too…