Dev Book Review: Sid Meier's Memoir!

Sid Meier's Memoir!: A Life in Computer Games by Sid Meier. ISBN 978-0393868296.

During the summer of '93 the French national anthem could frequently be heard blaring from my bedroom, and it's all Sid Meier's fault.

Like a lot of 16-bit home computer users of the time, I got completely addicted to Sid Meier's Civilization, or to be more accurate the free demo version from an ST Format cover disk which was restricted to playing as France. It didn't even matter that you couldn't save and could only advance so far before the time limit was reached and the computer was forced into a warm reset, I just started from scratch again, the game was that good.

Meier's memoir has a similarly addictive quality, the time spent reading just flying by. It helps that the topic is fascinating, taking the reader through the evolution of game development as a discipline and an industry, but also that Meier is a highly amiable and authoritative guide (the huge dash of nostalgia for me personally doesn't harm, either).

From his initial amateur efforts through to the most recent iteration of Civilization, there's a lot to learn about game design and development, but there's a lot to take away from the perspective of a software engineer as well. They're well-worn topics for sure, but seeing them come from game development in the 1980s adds a spin. Even today, game development is treated as a different beast, often looked up on in awe from a technical point of view, occasionally looked down on snootily from a software craftmanship point of view, and at the same time a significant proportion of us will admit that it was the idea of programming games that sent us down this path in the first place.

One thing that must seem astonishing to a lot of younger people is that back in the 80s, commercial games could be developed entirely solo. And we're not just talking about the programming - from coming up with the concept in the first place, through programming, composing the music, drawing the graphics, testing, security (copy protection), technical writing, and more, game designers like Sid Meier very much worked the full stack. It's several chapters (and games) before a graphic artist is introduced into Microprose. Sid might be a bit of an outlier in his range of abilities, but he wasn't completely alone in that.

Full Stack Development is a divisive concept, and maybe only truly works in simple systems, and times (or at least, games) were simpler then, but the book does illustrate how having knowledge of the different layers of the stack is an advantage when you may be forced to specialise or move into a more directorial role (in itself, a form of specialisation).

This also applies at a meta-level (emphasis Sid's):

I had useful knowlege that others didn't have, but I would have to rely on those who had knowledge of my knowledge, who could be my link to the non-programming world

This is in the context of working with an advertising consultant and also Microprose co-founder Bill Stealey who worked as CEO and handled the business side.

Business people don't necessarily need to know how to code (or do graphic design, or UX design, or...), but having appreciation of what goes into it will be an advantage.

It reminds me of the often asked, and often divisive, question "should designers learn how to code?". Well, no, not necessarily, but having an understanding of the constraints in implementation can't hurt, and one way to get that would be exposure to coding. Conversely, I like it when UX and visual designers pull engineers into sketching and mock-up sessions. It all goes toward fostering empathy and improving communication.

I do think it's better to have as many eyes as possible on a product while it's in development.

Empathy and communication with the customer is also a key part of modern product development. It's relatively straightforward to integrate communication with the customer when building software for the web (though often not as straightforward as it should be), but games distributed on physical media? It was done though, and the importance of pre-final-release play testing crops up often here, whether with friends and family or with gaming colleagues within Microprose.

It's not uncommon for even the most highly respected of Agilists to denounce such big bang releases as incompatible with Agile. This has often bothered me, as there's nothing inherent in the concept of Agile development to preclude it, and it is often necessary in the real world (see also: hard deadlines). This doesn't lead to abandoning Agile, it means applying Agile ideas according to your constraints, and a lot of the processes that are mentioned here in getting a game ready pre-launch feel at the very least Agile-adjacent:

This is why I never write design documents. Some managers are irrationally devoted to them, expecting to see the entire game laid out in descriptive text and PowerPoint slides before a single line of code is ever written. But to me, that's like drawing a map before you've visited the terrain

(not that I would say never write any kind of design document)

Each new version of a game - or anything else it suits you to make - is another opportunity to take a step forward. The more iterations you can rapidly cycle through, the more precise your final product will be.

There is no shortage of quotes I could take from this book illustrating the value of feedback loops and iterative development, but the section containing the following is one of the most interesting:

This is not to say that every step needs to be tiny. Efficiency is the goal, which means many iterations, but also getting as much information as possible out of each iteration.

He goes on to describe his "double it, or cut it in half" rule, the gist being that significant changes in one area, combined with a hypothesis, can tell you much more, and get you to a more useful place, than tiny incremental changes in the same direction, which can easily lead to being stuck in local maxima. It's a valuable lesson, and one which is often lost among looking for the tightest feedback loops and smallest possible changes.

Experimentation and innovation will always be hot topics, and I really liked this quote:

Ideas are cheap; execution is valuable.

It reminds me of definitions of innovation I've seen elsewhere, like Gartner's "the execution of new ideas that create value", but I also like that he doesn't just throw away ideas that aren't executed. Shigeru Miyamoto, legendary Nintendo game designer, reportedly puts ideas that are no good in a drawer, keeping them around until their time has come, for example when the technology has caught up. I think this is a trick we often miss, often only keeping documentation of active features and code and relentlessly culling everything else under the battle cry of "YAGNI!!!". Why not keep records of ideas, and the source code of spikes?

I don't want to exhaustively go through every relevant insight I've taken from the book - the best thing is just to read it and see for yourself, in context. It's a fun, easy-to-read book which deserves the sales. There is one last quote I'd like to take though:

A designer who is only interested in games will find it very hard to bring anything original to the table, and I'm sure this is true in other fields, too. Whatever it is you want to be good at, you have to make sure you continue to read, and learn, and seek joy elsewhere, because you never know where inspiration will strike.