|
Writers Guidelines
Postmortem
Guidelines
Postmortems
Objectives
The objective of Gamasutras postmortems
is the same as that of a real-world postmortem. Your game has been
completed, and you are documenting what went right and what went wrong
along the way. Hopefully the lessons you learned along the way will
be communicated to others so that they can repeat the successful parts
of the development process, and avoid the pitfalls you encountered
along the way.
Article
Format
Begin the column with a brief description of what your game was originally
intended visualized as, before the coding began. Explain the type
of game, the goals of the game, the intended audience, and any specific
technologies or features that you wanted to build into it that would
set it apart from the competition.
Tell
us about your development team -- what else they have worked on, what
the team dynamics are like, and so on.
Talk about
the tools you used in developing the game. This should include the hardware,
software, outside services you used such as motion capture, etc.
After
introducing the reader to your plans for the game and the team and tools
that would build it, the bulk of the article should revolve around the
"5 wrongs, 5 rights" concept:
With these
points in mind, tell the readers about your experience. To keep the
format consistent from issue to issue, use the five wrongs and five
rights as numbered subheadings. Here's an example:
"The
Making of Speed Racer"
Introduction (Goals, vision, audience, team, tools, etc.)
What went right:
1.
After a long series of negotiations, we successfully licensed the Speed
Racer cartoon and got the original actors to do the voice overs for
the game...
2.
We successfully converted our static isometric perspective engine used
in our last game into a moving camera perspective that tracked the car
from different angles. This was achieved by...
3.
We hired away our competitor's lead developer; he ended up being the
person that made the modifications to our graphics engine...
4.
Successfully made use of 3D audio API, the first time we've developed
a game with this technology. It was a challenge, but here's how we did
it...
5.
Implemented new multiresolution geometry technology that we licensed
from [some company]. It allieviated some frame rate problems that we
were having, and also allowed us to use more detailed models of our
cars. Here's how it works...
What
went wrong:
1.
Our original schedule turned out to be too ambitious. As a result, some
features from the original design document had to be shelved, like...
2.
Our modified graphics engine had critical flaw not detected until halfway
through development schedule. This forced us to pull 2 contract programmers
into the project for a while, and hurt our schedule even more.
3.
Three days before E3, we realized that our audio team's latest tracks
didn't sound correct. We spent 2 all-nighters fixing the problem, which
we discovered was caused by...
4.
We lost our art lead halfway through the project...
5.
A critical technology we had licensed in our graphics engine turned
out to have some serious glitches in it. We had to fix it by doing the
following...
Conclusion
(Summing up lessons learned, etc.)
Don't
forget the Data Box
At the end of the article, create a data box containing a snapshot of
your game and its development. Here is the
necessary data:
- The number of
full-time developers assigned to the project, and the number of contractors
used.
- The budget of
the game (estimate/ballpark is OK).
- The length of
time the game was under development (from initial concept to ship
date).
- The actual length
of the game (i.e. number of lines of code).
- The release date
of the game
- The platform(s)
the game runs on.
- Hardware used
in the development of the game (what type of workstations, RAM, hard
drive, graphics cards, etc.). This may differ from person to person,
but list a typical workstation.
- Software used
in the development of the game (compilers, audio tools, animation
tools, etc.)
- Notable technologies
or technical underpinnings that were used/licensed for the game --
one you couldn't have done without. For instance: motion capture,
force-feedback input, Smacker, DirectX, Glide, etc.
Include
Visuals
Readers want to see what your game looks like. Send us as many screenshots
as possible if you have them. Send
screenshots taken during the creation of models (in wireframe view) or
other images that convey the feeling for what the game looked like during
development. Send scans of paper & pencil drawings done of characters
during the initial concept stages of development. Send photographs of
the development team, taken on the job.
Length
of article
The length of the Postmortem column should be at least 2,500 words.
Broken down, that allows you to write about 2-3 paragraphs on each of the
wrongs and rights of the project, plus an intro and conclusion. If you need
more space, let us know. Gamasutra may be able to accommodate a larger article.
[Back
to Writer's Guidelines]
|
|
|
|
|
