Teach Yourself Game Programming in 21 Days - Day 2

This second chapter is titled "The Components of a Complete Game: Mech War". It's a decent overall look at how complicated game development is, and how much hard work it takes to get there. André lists 20 steps that he had to work through. The game 'Mech War' is essentially a Space Invaders clone.

His paragraph about design is interesting, because it is quite the opposite from my own experience:

"Much of what a game programmer does boils down to being creative. Writing games isn't too terribly complex once the fundamentals have been grasped. The hard part about making games is thinking them up! I can't count the number of times I've sat at my desk and tried to think up the ultimate video game. Many times I'd find myself creating games that had already been done. This is the problem: there are so many games out there (literally, thousands) that coming up with a completely new one is hard to do. There are still about 50,000,000,000 good games to be written—they're just harder to come up with."

I think of game ideas all the time. Often I will think of quite detailed systems and worlds while I sleep; my main barrier is not being able to make these concepts a reality. I think of myself as a fairly competent programmer, but the large-scale planning needed to create a game on the scales I can imagine often eludes me. Not to mention the huge amount of hours needed to create all the content needed to fill games; I'm no artist, though I used to dabble in musical composition, so I usually abandon the majority of my ideas.

I do agree with his assessment that there are essentially no 'new' games left. Even today, games can quite easily be described in terms of "older game X with extra mechanic Y". Or "like X but with better graphics". This is largely the result of the gaming industry becoming big business; many companies are simply not willing to throw the giant sacks of cash that AAA game development requires without guaranteeing a return on investment. Thankfully, indie development has a great role in filling these unfilled niches.

The author notes that even this simple game, copied from another existing game, took 5 days to write. Interestingly, he indicates that 50 days should be enough to write a game "of shareware quality" which you could probably sell. In my own attempts at game development, I can't really endorse this figure, but it does sound reasonable with a concerted effort and using the latest tools.

Even though Mech War is simple, he structures its development in a way that would make sense for a much larger game; he provides for a configuration system (here used simply to store sound card settings), splits up his code into modules, writes a separate library to handle sound playback (a very annoying issue back in the DOS era) and so on.

All the sounds in the game are processed samples of his own voice. I remember doing this too, back when I played around with The Game Factory; nothing beats going 'tsh' or 'oof' into a microphone then hearing them in-game. André also claims that many professional games use the same method; I don't think this is as true today, with the amount of commercial sound-banks available.

There are many, many more details here about what was involved in Mech War's creation, but I don't want to give everything away here. This is another one of those chapters that doesn't involve any actual programming, so I mostly skimmed over it on this fifteen-hundredth reading. It's still useful, though. At the end the author mentions a 'challenge' to send him an improved version of the game; he'll pick a winner and send them a cheque for $100! Golly!

I think perhaps that challenge might have ended some time ago. However, it might be amusing if I can find the time to send him my own improvement at the end of this little project of mine.

One of the exercises for this chapter is "Think up an entire game. Write down a list of all the elements in your game, and all their interactions." Way ahead of you, André.