What Went Wrong
Doubling the team and halving the time does not
equal the same output! We knew this, but we
went ahead with it anyway, and gave ourselves
a number of headaches in the process.
1 MiniMal pre-proDuction
/// One of the great things about creating a tools
team was that we actually had a group of people
who could make and maintain tools to enable
our content creators to work their magic. During
EmpirE’s development, tools were maintained by
devs who also had to worry about specific game
features at the same time. This meant that we really
didn’t start with the toolset we felt we needed.
The problem for Shogun 2 was that with
such a tight schedule (a triple-A game in about
a year), the tools had to be developed while
production was in full swing. This was a recipe
for some real difficulties, and early on, the tools
group had the thankless task of dealing with
portions of the team rendered unproductive by
unstable tools.
Despite sometimes feeling like we were
fighting tools as they were developed, and
messing around with the pipeline while trying
to make content, things were going much more
smoothly by the end of the project, and in the
end, we made major progress developing tools to
set us up for an easier time in the future.
2 late Design
/// A big game project is an all-consuming
endeavor for the team, and this does not
diminish as release approaches. Quite the
contrary. This makes it a real challenge to peel
even senior design attention away from one
project that’s about to release and onto another
that should have started some time ago! We have
always found this very hard, and the transition
from napolEon to Shogun 2 was no exception.
A significant portion of the team (artists
especially) were finished with napolEon many
months before release, and they needed to start
work on Shogun 2. The problem was there was
very little thorough design. It was frustrating
and risky for the artists to work with limited
guidance, but we had little appetite for taking
design attention away from making napolEon
the best it could be during such a critical phase
in its development.
This definitely caused some disagreements
within the team. Some did valiantly try to start
thinking about Shogun 2 up front, but there
wasn’t the capacity to get into detail. The intention
was to ensure that any finished artists at least
had valid work to do, so a limited design effort
fleshed things out at a high level so that work
could proceed and no one was blocked. It was
an admirable plan, but without a more detailed
design, some cul-de-sacs were inevitably entered,
and there were quite a few things that had to be
retrofitted. Not an ideal outcome.
Partly, this was the result of such a time-constrained dev cycle, but we do need to get
better at planning. The transition from napolEon to
Shogun 2 was probably one of our smoothest, but
as teams and costs grow, and time constraints
get more severe, we will have to up our game.
The delegated team structure does help this, and
hopefully we can learn from our mistakes.
3 get noobs playing early!
/// Playtesting can present a challenge in very
tight development cycles. Either it’s too early
and the game is not in a fit state for useful player
feedback, or if the game is ready, it can be too
late to do very much about issues that are raised
by playtesting. We are generally very ambitious
with what we try to do with each project, and new
features and content come together as a playable
whole frighteningly close to release. Getting the
game into a state when it is truly playable as
early as possible is vital, but this was a huge
challenge in such a short project, and getting a
true “vertical slice” of a grand-strategy game isn’t
really feasible until much of the game is actually
finished; it’s not like a level-based game.
When it was in a decent, playable state, the
whole team could finally play the whole game
as opposed to everyone just focusing on their
own piece of it. Suddenly, a deluge of revelations
appeared that might be familiar to any designer
who has ever watched new, naïve users get
their hands on initial code. The feedback from
team outsiders was absolutely invaluable in
making improvements. The problem was that
this happened so late. Coordinating development
better is vital so that each feature becomes
visible and playable without delay.
4 branches, branches
everyWhere
/// Two games became three, which became four!
In the beginning, there were battles: a super-realistic RTS game with thousands of soldiers
fighting it out on screen at once. The turn-based
strategy campaign was initially a wrapper to
generate varied battles and give them context.
That was the original Shogun in 2000. Over time,
the campaign game has evolved into a full-fledged strategy game that is, in itself, a rival to
series like Civilization. total War’s unique formula
involved two full games. When development
began on EmpirE in 2006, we knew that, since it
was set during the great age of fighting sail, it was
the perfect project to introduce full-scale naval
battles: three games in one. Not to be outdone, in
Shogun 2, we added game number four into the
total War formula: an online career campaign in
its own persistent environment to give context to
players’ progress in multiplayer battles. We didn’t
quite intend it that way, but revolutionizing the
multiplayer experience ended up diverging into its
own unique game world.
This meant more code branches (yay!).
Shogun 2 was the first title where we branched
the game code in earnest, and we really went to
town. We had a main branch and branches for
campaign dev, multiplayer, UI, battle dev, audio,
and tools. We branched for E3, for alpha, for beta,
for the demo, for release, and for patch one. Of
course, branching was essential, and meant that
development could proceed at pace inside sub-teams’ branches without the risk of breaking the
build for everyone, and always having a stable
main branch to test was invaluable.
5 coMMunication anD change
control
/// The feature focus that we gained when
splitting people into multiple sub-teams did
not come without cost, and the biggest danger
was entrenching the separation between
game areas, so that while each area might
be improved, the game as a whole could drift
into a disconnected patchwork. We strove to
ensure consistency and coherency across the
entire game, and while communication within
the small, focused sub-teams was fantastic,
communication between teams on a larger scale
was not always as good as it should have been.
Problems were perhaps most obvious
later in the project, when tweaks and changes
were being made at a furious pace to improve
and balance the game. Our origins were as a
much smaller team, where word of mouth was
sufficient to communicate information about
changes. We need to be nimble and able to make
quick changes without the protracted delays that
are possible with bureaucratic with cumbersome
processes, but in a large team, change-control
and diffusion of information needed to be much
better handled. What might seem the simplest
feature tweaks can have tentacles across
many areas and teams: UI, display, audio, text,
VO, advice and tutorials, and more. We need to
manage changes with an improved and more
formal awareness of dependencies.
the five rings
/// The challenge for the future is to keep
the series fresh and new—to allow constant
innovation. We are determined not to let the
increased team size diminish creativity, and we
always look to push the boundaries on every
product without fail.
As the team grows, we inevitably need
processes to keep things organized. We are
determined to maintain our creative, craft-driven
culture while getting better at organizing the
talent's focus. We need to get the best of both
worlds if we are to continue to make fantastic
games as each title and the team that makes it
grow ever larger.
james russell is the lead designer for the To Tal War
series of games.
www.gdmag.com 17
