Friday, 8 November 2019

Postmortems from 'Game Developer', a book review


"Postmortems from 'Game Developer'", edited by Austin Grossman is a collection of after-the-fact analyses of popular video games that had been recently developed and sold. The analyses are all written by senior members of each game's development team, and usually the game's head creator. "Postmortems" was published in 2003, so the games being analyzed include Diablo 2, Age of Empires, System Shock 2, and Black and White.

I purchased my copy from a thrift store in 2016, which had a suggested Canadian price of $42. This copy had several discount stickers on it, one of which had the book for sale for $0.84, a 98% discount.
Part of this is probably owing to the book's cover, which makes it look like one of those 'how to use technology' books that's obsolete before it hits the shelves, like "Windows 95 for dummies", or "programming for IOS 8.2". But the content of the book isn't tied to any one technology, it's about the principles of game design, has that much really changed?

To a 2019 reader, there are two things that are notably absent. First, there's no modern software development business lingo. Someone could read this book without any knowledge of Agile. Instead of sprints, there was crunch time. Instead of, uh, kanbans, there were to-do lists. That's not to say these methods weren't there in other forms. In the postmortem of Myst 3: Exile, there was a technical limitation during late development - the game took over an hour to compile, and thus over an hour to test any change live. They adopted a buddy system in which one programmer would watch another as they wrote code to do quality assurance and minimize the number of test compiles necessary. That buddy system today would be called "extreme programming". Buzzwords ruin everything.

More importantly, there's no almost discussion of revenue models. In 2003, most games were sold by the copy, and that was the only time that revenue was made from the game. In a couple of these games, there is some talk about preparation for expansion packs, both free and paid. Only one game, "Dark Age of Camelot" had a recurring revenue model in the form of a monthly subscription. Card packs, microtransactions, energy systems, and loot boxes are all nonexistent.

What was surprisingly similar was the scale of the games. Each postmortem included a development time and budget, and many of these games took 2+ years and $2-5 million to create. For AAA titles, that's not terribly different than today, not including the ongoing maintenance and development that happens with online-heavy games. The long-term job instability and extreme working hours were also pervasive, much like today.

There were some common recurrent threads that I never thought about: that a lot of the small two-dimensional sprites in games of the time (like Age of Empires) were actually pre-rendered images of much higher resolution 3D models. For some reason, I thought there was a lot more pixel art. This general strategy of creating high resolution images and scaling them down for the finished product shows up in several postmortems. When Myst 3 was being made, high definition televisions had just started being sold, and so initially the team didn't bother to record the live action sections with HD video, which they later regretted when trying to insert the standard definition video into the game, which looked grainy compared to everything else.

Another issue I'd never considered before was the concessions needed for localization. In Age of Empires, the menu buttons with words (instead of icons) needed to have a lot more space than English typically needs in order to make room for longer translations. Other games with voice acting needed to set events to trigger whenever certain voice clips finish, rather than at a particular time, otherwise the localized voice clips would need to be spoken unnaturally fast or slow to match the timing of the English version. (If you've ever been forced to name your game character something that was 4 letters long in a NES or SNES era game, it was probably because it was originally in Japanese, and 4 kanji would have been plenty for most names)


Many of the postmortems emphasized their choice of development tools under what went right/wrong. Several of them mentioned 3DS Max by name as being a good choice for modelling. Others mentioned regretting not building something for DirectX, or being too dependent on a scripting tool they were to receive from their publisher halfway through development. These days, Unity has become the de-facto default for many developers, but finding, evaluating, and using the right development engine was a much harder task back then.

Most of the discussions on project planning are still relevant today. There's two cited strategies for ordering tasks that sort-of compete. One strategy is to do as much of the planning as possible before creating a minimum viable product. This approach minimizes the amount of work, especially artwork, that needs to be thrown out and redone because story elements are less likely to be dropped or changed if it's all be planned out first. The other strategy is to get some basic version of a playable game created as soon as possible so that people can start testing and experimenting with features right away. The goals of this strategy are to motivate people with a playable vision of what the game could be, and to maximize the number of cycles of testing-and-improvement that can be fit into the late stages of development.


There's a postmortem by Peter Molyneux on Black and White, in which he talks about his bad habit of trying to build bigger games than are feasible. Around 2011 when his mobile project "Curiosity: What's Inside the Box" started, there were jokes that Molyneux overpromises and underdelivers, so it was interesting to see that bit of self awareness. If you're not familiar with Molyneux, he made quirky, experimental games. Think Bennett Foddy (Getting Over It, Universal Paperclips), but with a larger budget.

A recurring issue was scaling to meet computer requirements. Each game has a CPU speed budget, a RAM budget, and a total file size budget which was usually a single CD-ROM, or about 700 Mb. The Postmortem of Star Trek Voyager: Elite Force talked about how the levels had to be either shrunk down, cut in half, or both to accommodate all the curved surfaces that the Quake 2 allowed, but which took much more resources than the equivalent levels in Quake 1. The Postmortem for Age of Empires talks about the difficulty in predicting the frame rate of the final game from prototypes in which many of assets are not yet loaded in and running. In developing Tropico, the ability to zoom close in and see the details of the people walking around became a major headache because it took a disproportionate amount of disk space and RAM to handle that much detail. While RAM limitations are less of an issue today, and disk space is almost a non-issue, optimization for limiting computing power is still common problem. Previously, games could rely on Moore's Law to improve computer hardware dramatically every couple of years, but today we've had to get a lot more creative to improve speed by distributing load across multiple cores, and by writing non-graphical code for specialist graphical processing units.

The book "Postmortems" doesn't deserve to be forgotten, and a lot of the material is relevant for game and other software development today, even though a large section of the industry and player base has moved on to mobile.




No comments:

Post a Comment