Category: programming

I’ve spent another whole day working on particle /explosion stuff and tools. I was very pleased with the explosions in GSB. They look like this:

But much better in motion. I think that’s not bad. However, just because I think it’s not bad doesn’t mean it can’t be a factor of ten better. I’m aiming for ILM-standards, so there is a huge way to go.

GSB had a particle editor, but it wasn’t as good as it should be, mainly because it was built as an external program, and a crap one. I am notorious for making rubbish tools. I should just ask Eskil to make them. Anyway…

Here is the very first attempt at the explosion / particle editor for LB. It’s not vaguely finished, not even by 50%, and I really need to support zooming in! Anyway, the main thing is that it’s built into the game, which means a lot less hassle to edit effects and then toggle back into the game and see how it looks. Plus it uses the exact same source files as the in-game effects, so it’s less messy.

To be honest 90% of the effort was a re-jig of the class structures for a lot of my particle code, rather than actual tools production. Obviously all the GUI code there and the graphics are from GSB, don’t worry, I’ll get a brand spanking new GUI design for the new game in time.

I’m determined to finally make a game that has decent tools from the start, to make me more productive.

In other news, I was woken at 3AM by the death screams of what sounded like an injured pterodactyl in the garden. It *might* have been some less exotic bird, but I’m not so sure. Glad I hadn’t just watched some creepy horror movie.

I was chatting to someone about a year ago, who was embarking, for research purposes, on how to code a game in C++. They were familiar with the rudimentary concepts of coding, and with games, but had never looked at C++ before, or the source to any modern game. They had enormous problems going from the programming they leanred briefly as a kid which was this:

10 PRINT "I AM L33T!"

20 GOTO 10

And modern game source code. The main difference is that a C++ game is ‘object-oriented’ and the languages people start with are just simple lists of instructions, executed in order. This is a 30 second guide to helping newbie coders cope with the difference. The biggest problem you have, is the question “Yes but where does the code actually START?”. And the answer is, a function called WinMain. Basically, the structure of any game is this:

WinMain()

{

Create A Window();

InitialiseGameStuff()

while(true)

{

CheckGameNotQuit()

GameLoop()

}

}

That’s basically, Kudos, Democracy, Starship Tycoon, GSB… etc. It’s all there. that is the whole game. The real stuff happens inside GameLoop(). That is basically this:

GameLoop()

{

BeginFrame()

DoAIStuff()

DrawStuff()

EndFrame()

}

And that obviously splits out into a billion other functions. Now already, it might look scarily nothing like 10 PRINT SCREEN, but just imagine that GameLoop() is a GOTO that jumps to the start of GameLoop() and imagine a RETURN statement at the end of that section. The weird bit, for new coders, is that the code will jump back and forth all over the place, between different source files, in different orders, up and down and all over like a ping pong ball, but, ultimately, when the chips are down, it’s not really *that* different from old BASIC programs. Until you multithread it, anyway :D.

I was coding something in G4 recently, and it was in theory a simple thing. I was trying to work out why a certain unit in my game was not opening fire on another unit when I knew it should be.

When I was looking at the unit onscreen, it was one of several, and stepping through code is frustrating if you aren’t sure who is who. The best solution in this case was for me to overlay a range UI on the screen so I could check it wasn’t a range issue. That meant writing some new code to display the range UI, which is fine. The problem is that meant getting the range for that unit into the GUI code, and there was no simple way to do that yet. That meant writing some new code to make a note of the range for that unit elsewhere…

In an office, this is normally the point where someone taps you on the shoulder or asks you a question… And then it all falls apart. At this point my mental ‘stack’ is this:

Working on G4

...Debugging the firing bug

...Adding a range overlay

...Writing code to access max range

The longer that list gets, the longer it takes to get back into what you are doing. With really bad bugs (I coded a neural newtork once…eeeek) you can be 10-15 layers in. It can take a good 15 minutes to mentally rebuild that stack accurately if it gets lost, and it *will* get lost the moment you lose your train of thought.

Short summary: Make sure nobody interrupts you when you are coding.

Because I didn’t make it very fluid, I get an email maybe twice or three times a week about someone who had problems installing an expansion pack for GSB if they bought the base game from stardock or steam. The solution is easy, you need to browse to the place where the base game is installed during the installation. It had not occured to me, when setting things up, that this would be a big deal, but a non-trivial proportion of buyers don’t realise it, and they need me to walk them through it, which is fine.

Obviously I made a mental note to ensure that sort of problem will never arise with future games.

What really strikes me though, is how far we have come from the days of my gaming youth. Go back far enough and the boot-up ‘welcome’ screen on my first computer was this:

You were expecting icons maybe? or perhaps a graphic? or any way to actually launch programs or do anything? Unless you were lucky and had money to buy software, you would actually have to type in the code for each game (the whole program) from a magazine. The operating system was pretty much just a way to support the typing of characters on the screen. No danger of antitrust legislation for bundled apps there…

Fast forward through my days as a rock star and boatbuilder (long story) and I got an IBM 386. These were the days of playing X-wing. Now you might think it’s a pain to get the right drivers these days to run crysis, but back then, you had to literally reconfigure the structure of your RAM in order to run a game. People my age will get a cold sweat remembering autoexec.bat and config.sys, the two dreaded files that between them enabled you to balance your memory allocations just right to get that extra 16k needed to boot up SimCity.

The thing that really strikes me, is that re-configuring autoexec.bat and config.sys was so arcane, so complex, and so fiddly, and geeky, that not only was it much much harder than any problems current PC gamers have to deal with, but it was actually harder than most games. I may have got frustrated with constant deaths when storming the beaches in Medal of Honor, but that was NOTHING compared with the challenges presented by emm386.

As game developers, often geeky ones who are older than a chunk of our audience, we need to constantly remind ourselves that there is a huge swathe of people who never struggled with this crap. To them, sadly, the PC is just like a toaster or microwave. You press the button and then it does stuff. If it doesn’t. you complain to the manufacturer. Sadly, I suspect the nation of geeks and tinkerers we had in the 1980s has become a nation of passive consumers. Understandable, maybe inevitable, but maybe also slightly sad?