"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.
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