Other Bits and Pieces

There are tons of other bits and pieces to coding games, many of which you'll discover in the next chapter. These things defy classification, but they are every bit as important to games as a good random number generator.

Beyond that you'll find some things important to game coding such as how to convince Microsoft Windows to become a good platform for your game—a more difficult task than you'd think. Microsoft makes almost all of its income from the sales of business software like Microsoft Office, and the operating system reflects that. Sure, DirectX is supposed to be the hardcore interface for game coders, but you'll find that it's something of a black sheep even within Microsoft. Don't get me wrong, it works and works surprisingly well, but you can't ever forget that you are forcing a primarily business software platform to become a game platform, and sometimes you'll run into dead-ends.

Debugging and testing games is much more difficult than other software, mostly because there's a lot going on in real time and there are gigabytes of data files that can harbor nasty bugs. Combine that with the menagerie of game hardware like video cards, audio cards, user input devices, and even operating systems, it's a wonder that games work as well as they do. It's no secret that games are considered to be the most unstable software on the market, and it reflects the difficulty of the problem.

There are also a number of software development practices that work extremely well in game development—stuff that you'll think belongs in a government coding gulag for the DoD. Most game programmers shun this stuff—things like code reviews and build scripts and even source control, because if they wanted to work that way they would have applied to places like Computer Sciences Corporation or NASA. It turns out that these practices exist in these houses because of the risk of failure. A bug in a navigation system or flight control can kill people. Games don't share that problem, thankfully. Game code is extremely complicated and if you don't have some measure of discipline in your work, you'll spend more time chasing bugs than making your game fun. Remember that game code is still programming, just like everywhere else, and the application of process and discipline will result in a superior product. That's a software engineering way of saying you'll make a kick-ass game that's a blast to play, and hopefully a blast to make.