Last night I was leafing through my collection of game design books. I got addicted to game design books in the hopes that one or more of these would give me some insight into the process of game design. These books are like flypaper for novice game designers like myself: they seem attractive on the surface, but you can get stuck if you adhere to them too closely (double meaning slightly intended). Many of them have similar advice, starting with trying to define a game before jumping into a broad survey of the different types of games that are out there. Then they give some prescriptions of their own design process, and then tell you how to land that job at that company you've dreamed of working at (or worse, how to make money selling games by reading the gaming market from the period before the book was published).

I've read more of these than I'd like to admit, and I've seen a lot of different patterns in these books. Most are geared toward landing a job in the video game industry. Many of them are tangentially related to game design itself, spouting truisms like "optimize for fun" or "make emergent play" (note: paraphrased). Some of them actually guide through the process of designing a game and what to notice, but a good number of them cut the conversation short so they can focus on the next topic.

Last night I got frustrated at one book because it referenced "The Hero's Journey" by Joseph Campbell and the abridged version for writers "The Writer's Journey" by Christopher Vogler. (If you've ever wondered why your reluctant hero has to have a call to action to fight the big baddie at the end now you know what advice the designer took to heart.) I started looking through other books in my collection to see what other designers prescribed this advice. If there's one thing I would love to recommend to designers is to read the myths themselves without the lens of Joseph Campbell. I promise they're much more interesting than his ridiculously oversimplified and wrong formula.

I then leafed through some mechanics books. That got me looking at some wargame design books. Maybe I was tired, but the book I picked up felt like someone rambling to me about wargames more than instructing me how to design war games. True, it was starting with the rules for a particular war game (and I'm not naming the book in particular in part because I'm thinking the fault is with my patience rather than the material) but it got me thinking about war games, and then I wanted to look at one war game in particular: Eastern Front, by Chris Crawford.

Eastern Front was a pivotal game for the Atari computers. It was a graphical masterpiece and did what few games of the era could do: create a tactical war game that could be played against the computer with credible opposition. It was also written in 16K and published by Atari's "Atari Program Exchange" (a user-submitted, curated label for Atari Software). It was written using Atari's Assembler Editor cartridge over the span of about a year (around 900 hours of development).

What made Eastern Front so special was Chris also released the source code via APX. Rather than just a dump of the source code it also includes a section explaining the code and the decisions behind it. In those 60+ pages of text and notes Chris gives a masterclass of game design and his approach to design. He talks about his design process, decisions he made for code, and the playtest feedback he received. He talks about his frustrations, his triumphs, and (of course) the cycle count on the Atari and the efficiency of the routines.

The manual has been scanned and is available on the Internet Archive (Eastern Front Source Code.

At the time the source code for Eastern Front was $150 in 1980s dollars. Had I known what I know now I think this would have been a wise investment for my game design interests. It sure would have saved me from purchasing all of the other books that didn't give me nearly as much information.

You can find the source code for Eastern Front and other games that Chris Crawford has written on in his source code library.

(I may write up a second post of books that I recommend for game designers that touch more on the process of game design rather than paint it with broad strokes, but for now the one that I'm finding most helpful is Think Like a Game Designer by Justin Gary.)