Download Developing The Development Process

Developing the Development Process
This document is a glimpse into problems and solutions encountered as team/technical
lead/director over 5 released titles with 4 out of 5 titles delivering on time for the last 11 years in
games and 5 years in business working and leading multi-user business system projects.
A lot of this may well just seem obvious but I am always amazed at how many projects do not
have even some of the more basic points established, inevitably causing the project to delay or
lose focus and end up being canned.
The quotes are more or less accurate from individuals within the game development community.
“So, we’ve got this idea right , your in a sub , underwater or summit, and you can dock and
walk around, just like tomb raider and then you can go above the water, maybe, and fly to
another planet…I think !!!”
One of the main problems we faced on a couple of titles we did was a lack of ‘the champion of the
game’.
An idea would spring up from the misty depths of someone’s consciousness, a proposal drawn up
and presented to a ‘game board’ and then subsequently a prototype started, unfortunately, even
at this point, the game had become so ‘designed by committee’ that it had lost its ‘champion’ so
to speak.
The one key member of the development team who assumed all responsibility for the direction of
the idea and how it would grow, that would show confidence and conviction to the idea, this is not
to say that others cannot contribute or changes made to the design due to constraints/schedules
but they, at the end of the day, were the one person that could be relied upon to know ‘the game’.
It seems obvious that we simply call this person ‘lead designer’ but the role is far more than a
title, it is the leading light the artists/programmers and management call on for direction and
confirmation.
“If I want a million sprites on screen, then you’re the programmer and I’m the designer and
that’s what I want!”
What makes a good designer? no doubt there are hundreds of answers, but one that we found
again and again is a designer who understands and works within the constraints of the system.
This doesn’t mean they should restrict ideas and design to technology/schedules but take the
technology/schedule constraints into account when creating a design and applying it. This also
means that they are flexible when situations change, be it technical or schedule that have an
impact on design.
Design without constraints is not design, it is merely dreaming.
“Scheduling! your in the games industry now, it’s a creative thing, we don’t schedule”
Schedule, a word that seems to be hated by most programmers and artists and not always
understood by producers.
A schedule isn’t an anchor that restricts design, programming or art creativity, it’s a lifeline that
allows us to see the realisation of a game as a possibility.
There is nothing in a game that cannot be scheduled, design is not a black art that requires an
indeterminate amount of time, many of us have been in the game industry a fair while to know
what works and what doesn’t to some extent. For those areas where it is an unknown,
contingency should be built into the schedule.
One of the most helpful methods we’ve used when starting a schedule for a project is adopting a
business practice known as the ‘brown paper model’. This simply means taking 2-3 days out with
the leads of design, art, programming and a producer, pasting a meeting room walls with sheets
of paper, then writing down everything related to the game (required art/programming/design,
other assets etc.) on those sheets.
Once that is done the items can be sorted into chronological, art, programming, design categories
to start a proper schedule but we have a good basis of the items required to realise the game.
“It’s not my problem!”
Within game projects we have always found it to be vital that a clear lead in programming, design
and art existed.
Nothing is worse then having a problem with the art or code and no-one making the final call, or
even worse 2 leads in the same category making conflicting calls.
Of course there may be hierarchies so for example you could have a programming lead on the
engine, one on games and another on the consoles but one should still assume overall
responsibility. Without this conflicting standards arise, no-one person takes overall control and we
end up with the classic ‘it’s not my problem’ quote.
This also benefits change control, as any major art, design or programming decisions need only
be communicated with the leads and then they are responsible for ensuring it follows down the
hierarchy within their respective field.
“Whoo, glad that’s over, now we can forget about it..”
Projects tend to go through very different emotional phases, the initial enthusiasm and ambition,
the striving determination, monotonous periods, longing for end, refreshing boost of inspiration
when the game is demonstrated or a preview article written. But there tends to be one common
emotion at the end of a game project and that is the sense of relief that it’s done, over and now
onto the next project.
Unfortunately its at the end of the project that we can gain some of the most important information
from our experience by doing a post mortem, but with the overwhelming sense of relief and the
desire to ‘move-on’ this more often than not is overlooked.
We have found the post mortem is an excellent opportunity to discuss all the things that went
right but most importantly what went wrong and how we can improve.