Debugging vs. Robust coding techniques

Game development vs. Application development

Published on July 15, 2005 By Draginol In GalCiv Journals

The team is getting features in like a well oiled machine. The new research screen just totally rocks. Kudos to Mudflap and Mormegil for getting that stuff humming. BoogieBack and the Elf Girl (doncha just love these handles) made good progress for getting the new star base system in and the new freighters in.

Our newest team member, Jesse (no cool handle yet), has started on the ship battles. We want the ship battles to be really impressive and we want ships to show damage. Ever see Star Trek II/III where the Enterprise has phaser burns and such? We want that kind of stuff.

The big debate this week is something that's kind of an on-going thing. I've been writing games now for 12 years. That's games on store shelves. I'm not a great programmer as I've mentioned many times before. But my coding style does lend itself to easy debugging and easy readability. I.e. I can go back and look at my code from 4 months ago and know what I was doing and in a pinch, put it through the debugger with all the important stuff just a click or two away in a debugger watch.

But I wouldn't program an application the same way as I program a game. Most of our business is creating applications. And when it comes to applications, robust coding techniques take the lead. A well designed application still needs readable code, but the odds of going in and tossing out features or algorithms in a typical application on a regular basis are not as high as they are in gaming.

In a strategy game, debugging becomes critical because debugging isn't about finding bugs. Debugging is about fine-tuning game-play. The last couple months of development usually mean, for me, spending 90% of that time in the debugger tweaking playability. And that means having structures and objects and classes that lend themselves to being easy to view in the debugger. To me, CString is the devil. STL is a pain. I don't like iterators. Which means I really don't like container classes. I understand the need for those things. I just find them a pain to deal with when I'm debugging.

The last few months of Galactic Civilizations II will mostly be about tweaking the AI. Why did the AI build this kind of ship? What did the AI put together a fleet with those kinds of ships in them? Why did the AI not build a particular structure on that particular planet? Where in the heck is that AI ship giong? Why are players running out of money? Why does the morale on a planet fall so low after a certain point is reached? Why did the AI not build a certain type of star base in a certain sector? Why did the computer player declare war on the human player when he did? Why didn't the AI recognize the threat posted by the human player? Why did the AI offer help to that player despite being morally opposite of him? Why did the AI choose to build that ship on that particular planet? How did the AI see my starship when it was over here in the corner? Why did the AI put their spending ratios and spend rate at that level? Why did the AI send their freighter there? How much money per turn is a particular trade route established between AI player 1 and AI player 2 costing? How many shield modules does that particular AI ship have on it? How much time is it taking the AI to research a typical technology when on Average intelligence? How much difference is there between different AI intelligence levels?

The questions go on and on. And those questions create many subsequent questions. The answer isn't to put a bunch of debug print statements in the code, that would take forever. The answer, as a practical matter, is to try to make it such that you can always look at a particular ship, computer player, planet, colony, improvement, whatever and with a few clicks be able to see the numerical value of it. And moreover, to be able to code it in such a way that it doesn't take long.

That means things like Arrays and pointers. Not special array types, but good old fashioned pClassStarShip pShipsInFleet[MAX_NUM_SHIPS_IN_FLEET]; type stuff. This is the kind of thing that drives seasoned developers crazy because it's so prone to causing bugs later on. One slip-up in a for loop or something and suddenly you're getting unexplained crashes that can take weeks to debug.

The way I've tended to deal with that is to break down my stuff into lots of small functions. So things that could potentially introduce some overrun don't happen. I also don't allocate memory on the fly. In 12 years of game development, none of my code has ever used a Malloc. And I've only recently (mainly because I'm had to adapt to other people's code) had to create instances of things on the fly and destroy them when I was done. My code has traditionally only created new things at the start of a game and deleted them at the end of a game. A single function for creating the stuff and another to wipe it out. Everything else is created (and stays) so I'm not messing with memory leaks, memory overrruns, etc.

And those people who have played our games know that they're traditionally quite solid. I don't need a standard template library or a CString or other "stability via compiler" type stuff. My way isn't better as any general rule. But I believe it is better for game development on a game with limited scope (I wouldn't recommend this method for a development team of 20 people, it still requires pretty disciplined coding).

So that was our debate this week. Things are going well though. Beta 3 is going to rock.

Comments (Page 2)

CariElf

on Jul 26, 2005

James,

Unless you know something that we don't, in VS.Net 2003, you have to navigate through the odd hierarchy in the container classes to view the contents of the vector. It's not as quick as just putting aShipsInFleet[0] in the watch window. As I said earlier, Visual Studio .Net 2005 is supposed to have better tools for debugging with the STL. I love the convenience of the STL, but I am looking forward to the new debugging tools in VS.Net 2005.

Mike C

on Jul 26, 2005

vs2005 is really nice

That completes this informative post.

noctl

on Jul 28, 2005

You might find these interesting:
http://www.codeproject.com/macro/vsedebugaddin.asp
and
http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63905

JoeHunk

on Aug 11, 2005

Those links above illustrate my point. Debugging is a general software development problem. So are data structures. And so is delivering a product on a tight schedule. I find STL to be a huge time saver precisely because you don't *have* to debug STL containers...that's already been done for you.

As far as introspecting the contents of STL containers, there are people solveing that problem right now. It seems like a little bit of a cop out to say, "hey, my debugger displays a bunch of oblique info. when I look into an STL container so I ain't using it," when a quick web search can uncover utilities like those linked above.

I'll agree that if arrays are all you ever have to work with, then the win of STL is minimal, and may not be worth the extra debugging complexity. But arrays are also limited, especially for large or frequently modified data sets. Linear time insertion, linear time search (unless sorted, and then see insertion), etc. I find myself using std::maps and std::sets a whole lot, and those are both implemented on red-black trees -- try whipping out a bug free implementation of one of those in a respectable amount of time. SGI STL even throws in hash-table-based sets and maps...yet another data structure that isn't trivial to whip out any time you want it. And I might add, doesn't look pretty in a debugger even if you do.

A gentleman above mentioned Java...Java's development tools have already largely solved the problem that C++ tools are just beginning to solve, which is the ability to introspect complicated containers easily. I'd think an app like GalCiv, which has fairly modest computing requirements compared to, say, a first-person shooter, might be easier to develop on JavaGL. That sounds kinda cool actually...

Lorent

on Aug 12, 2005

Just a point that you will never heard mentioned in College, or in any textbook about programming. Using a basic array and a simple search you can load the entire unabridged dictionary and search for words faster, than if you use any other method. I did not believe this but then again I met one of the Engineers that helped build Intel, his name is Elliot, and he proved it by writing the code and loading the entire vocabulary in an array and using a simple sort. Then showing me evey other possible search method. I was rather amazed because I thought he was pulling my leg. I have never since underestimated the practical application of a simple sort and an array.

Luke

LDiCesare

on Aug 13, 2005

I once tested the array vs Hashtable performance in java. A size 7 array was of equal speed to a (synchronised) hashtable without using dichotomy. To be faster, you'd have to use dichotomy search, which means you're effectively coding a structure on top of an array. Although a hashtable may become less efficient due to memory requirements, I doubt a B-tree would be less efficient than a straight array.

Peter King

on Aug 14, 2005

If its a sorted array then you can do a binary search on it anyway, you dont need to turn it into a tree. Under C you could use the bsearch function on the array. I find arrays nice fast and simple for things like searching, just inserting elements into the middle of them or requiring a resize of the array can cause the performance hits.

CariElf

on Aug 17, 2005

n uvem, thanks for those link. Those look like they might come in handy.

Welcome Guest! Please take the time to register with us.
There are many great features available to you once you register, including:

Richer content, access to many features that are disabled for guests like commenting on the forums.
Access to a great community, with a massive database of many, many areas of interest.
Access to contests & subscription offers like exclusive emails.
It's simple, and FREE!