Category: programming

How I envy developers working on arcade games, or anything that has a very simple game ‘state’ that can be easily saved and loaded with no grief. For the game I am currently working on (announcement later this month), it’s a bit of a pain, because the actual game ‘state’ is horrendously involved, and every single byte of it has to be loaded and saved perfectly. The problem is mainly due to my tendency to code systems that have a huge number of objects that all have pointers to each other, in complex and arcane ways.

In theory, stitching everything back together after a load is fairly easy, but in practice, it’s a bit of a pain, and the REAL pain is to know that it has all worked perfectly. if 99% of the pointers are right, and 1 isn’t, then I have a horrible dangling bug somewhere…

My current process for preventing this is to have the game completely save out it’s state and load it’s state back in every turn (it’s a turn based game). At the moment, due to arcane debugging issues this is horribly slow, but eventually will be super fast. At least doing it this way means that during development I’ll spot any save/load inconsistencies really quickly.

I’m aching to get on with some GUI stuff to make it look nice, but I’ve learned the hard way that I have to put that off until the foundations work better. Better to have it stable now, rather than fix it later.

I use the odd bit of code that has char* in it. There I’ve said it. It feels like a big confession. I bet some programmers just sprayed their coffee everywhere. I’m sorry. They say the first step is admitting that you have a problem.

I’m a very very productive game developer. I churn out a lot of very very big and ambitious games. One of the ways I manage that is that I don’t change my ways unless I can make a really good argument for doing so. I never learned what on earth .Net was, no I don’t mind it’s passing. I don’t really know C#. I have no idea what design patterns exist other than singleton. I have no idea what a UML diagram is (is that even a thing? I don’t know…)

You have no idea what a huge big deal it was for me to switch from directx7 to directx9. That took some doing*, and it’s why I still use DX, not OpenGL (which would make apple mac ports far easier and cheaper).

While I’m in confession mode, here are a few other howlers you might be amused by:

• I manually type out for() loops without using for_each()
• I use FILE* not the stream stuff
• I use my own GUI library, and Input code, not third party stuff. In fact I wrote my own hash table code too. The only stuff I rely on is STL, and only partially use std::string

Scary huh?

Why am I such a luddite? Well it comes down to time. If I had regular bugs that I could attribute to passing around char* now and then rather than a std::string, then things would be different, but I know all the functions that handle chars better than I know STL, so I code much faster that way. I have a slight niggling doubt that for_each() is as fast as it should be. I can’t remember the iostream syntax, so I use FILE*, because frankly my file handling code was written years ago and still works fine, so why change?

I see a lot of coders jump on every code bandwagon, and learn new stuff all the time. They are constantly rewriting their whole engine, and constantly going back and changing the code they wrote a month ago. They rarely ship games, and very rarely ship large ones. To me, it always makes sense to make occasional big jumps, rather than constantly fight to keep up with the latest stuff. I have no idea what was in Directx8, it passed me by totally. I’ll maybe move to directx12 (more likely opengl).

It may make me seem old fashioned, but it’s incredibly productive.

*it’s not learning the API, but building a bug-free FAST engine that correctly encapsulates the API that takes time.

I actually wrote some new code for Gratuitous Space Battles today, and in doing so, I had to do a bit of chin-stroking and thinking about the general code structure of the game. GSB is not my latest game, so the code I write now for new stuff is more polished and better designed, but even so, I’ve coded about a dozen games from scratch before GSB, so it should be fairly good.

..and yet…

One of the best lessons you learn, mostly from experience, is how to arrange classes and objects in your code so that its fairly modular and not ‘closely-coupled’. In C++, what this amounts to is you shouldn’t have a lot of classes constantly using get() and set() calls to talk to the private members of other classes. Separate objects and basically separate for a reason. The hardest decisions to make in code are the big architectural decisions about what objects sit inside others, and who inherits from what. I’ve been coding in C++ for decades now, and I still know I often get it wrong. This stuff is really important.

For example, there is a class is GSB called SIM_Ship, which contains all the gameplay related stuff for a ship (totally separate from the visual representation of the ship which is entirely different and in a totally separate class). In an ideal world, that ship class would be pretty self-contained, without a ton of connections to other objects.

The problem is, over time, I’ve ended up adding stuff to that class that bloats it and makes the code messy. For example, it has a function in there to shake off limpet mines. This is a bad idea. The limpet mine code should all be within SIM_LimpetMine. SIM_Ship not only shouldn’t get involved with the limpet code directly, it shouldn’t even be aware that the concept of a limpet mine exists. That stuff should be modular, residing elsewhere and making use of generic functions and hooks within the ship code from a distance…

Sometimes that doesn’t work in practice because of optimisation and speed considerations, but often, the reason stuff ends up in the wrong place and the code gets confused and messy is that the coder is just adding ‘one more thing’ and doesn’t think its worth going to the trouble right now…

But when you are starting a big new project, its good to keep these issues in mind. Assume you will have 5x the code you think you will have, and then plan the code architecture accordingly.

So intel sent me a new laptop, because they are wonderful nice people, and one of the reasons for this is to get game developers to use their amazing performance tools, and to see how modern games run on the very latest intel hardware. The laptop in question runs GTB very very well, and the graphics card is apparently an intel HD Graphics 4000 . I have to say, that if I plugged a mouse in, I could probably quite happily use it as a main gaming PC, which is a vast surprise to me.

Anyway, the main thing that impresses me is this intel graphcis performance analyzer stuff. You run a small program on the target PC (the laptop) and then run the analyzer stuff on another PC, connecting trivially by IP address. You run a game, and then you can connect to it on the second PC and view dozens of real time graphs on all sorts of crazy stats as you play. It’s pretty impressive stuff. AQTime can do this after-the-event, and it’s great for really working out exact lines of code that need optimizing, but this is a great way to get insight into the GPU, rather than the CPU.

Clickable full size screenshot below:

If you have a PC with an intel graphics chip, give it a go. Their performance analyzer stuff seems to be free, which is also awesome. I think for the first time in ages, intel video cards may well start to become serious rivals to ATI/Nvidia. Also the contrast between nvidias attitude to indie game developers (totally ignore me, even when reporting a bug), and intels is night and day.

Heres a video showing some of the stuff:

I have dabbled very slightly in 3D (Don’t be alarmed), and have retreated in terror at the additional grief it requires, and the compromises required, and the general ickiness as it seems to me.

So I am pretty unlikely to release a proper 3D game in the next few years, at least. I personally do prefer 2D games. However, that doesn’t mean I do not enjoy nice graphics, and certainly there are a ton of nice looking 2D games out there. The majority of them are side-scrolling or similar style games that rely more on a very good piece of art direction (Braid, World of Goo), than they do any sheer horsepower or rendering muscle. I’m not aware of many 2D games, indie or otherwise that tax a CPU/GPU as much as Gratuitous Space or Tank Battles.

However, having just bought a new PC, AND watched the latest cryengine demos, it’s pretty clear that modern gamers have enough firepower to render the bejezus out of anything in 2D, so we are in the happy situation of twiddling our thumbs thinking what crazy stuff to add next time-around.

One idea is is to push particle counts through the roof and have seriously complex explosions and smoke trails etc. This could certainly be ramped up, although smoothly transitioning to it from low-spec PC’s is a nightmare

Another idea is to use a LOT of different layers and components to build up individual units to give them a more unique feel. Obviously GTB is a big step up from GSB in that respect, but it’s got way, way more scope.

Shadows and lighting are two other possibilities. GTB infantry uses blob shadows. Animated shadows are certainly doable, but involve a crazy amount of texture RAM to do right. Maybe worth investigating. Faked 3D lighting using that clever deferred rendering thingy is another (fairly tricky) option.

More detailed environments is another. The problem here is art budget. It’s all very well saying we need 120 different bush or pebble models. Someone has to make them, and get paid for it.

More cunning explosions, using some sort of clever physics modelling, or procedural whatnots, or clever multi-layered shader thingies, is another option.

Of course the real problem is TIME. I already have this big scary change to Gratuitous Space Battles waiting for me to release for everyone. It’s just sat in-between holidays, GTB updates, redshirt, and talking to builders. Plus another new thing I haven’t revealed yet. I am quite tempted to just push out my GSB update very soon ‘as-is’. I was hoping to find a cunning way to use it to raise money for charity, but that’s a whole other story…