 Film
vs Game Production
By Tim Carter (originally posted 2002)
The following article is adapted from an email I sent to a film
person at Telefilm Canada on the difference between the film and
game production models...
In film there is a hard distinction between
development, production and post-production. There is no such
thing in game development. For digital games, the term
"development" carries through right from the beginning concept
paper through to the gold master.
There also is no such thing as a "first day of
principle production". In film there is because film is intensely
industrial - everyone has to show up, the cameras set up, the
lights set up, you have your location for a limited time, et
cetera. Not so in game development - which occurs entirely in
cyberspace: whether the network of a centrally-located studio, or
simply the Internet with multiple parties working from disparate
locations (out of their own homes). The entire process requires
less intensive project management than film in an industrial sense
- though it requires more "thought management", in the vein of
design and engineering (more on that below). Basically, a film is
shot at a location; a digital game is made at a desktop.
You can develop a world-class game - certainly
a prototype for one - working in your spare time, with multiple
team-members scattered across the globe, uploading their work to a
project server. Maybe it isn’t easy, but it has been done. There
isn't a need for a hard-distinction between various duties since
the immense power of the digital tools at ones disposal, and the
virtual nature of development, allow for more general duties -
more overlap; much more ability to go back and redo things that
need correcting. (In fact, in regard to redoing things, digital
games for PC are effectively released "unfinished" - with
downloadable patches available on the Internet to correct things.
There's no comparison with film/TV in this regard [except maybe
for the "director's cut"]. Imagine releasing a patch for a film
that is already on that market, a patch that would get rid of a
bad line of dialogue, or erase a shot where the boom is visible?
It's impossible to. Imagine going back to reshoot a scene done
months ago where a hair accidentally got in the gate and wasn't
noticed (maybe a bad example, but you know what I mean)? Can't do
it on a film. In a game, no problem: the whole set is sitting
inside your computer. Just recompile the map, or re-render the
cut-scene.)
As an example of team-member overlap, on a
traditional film, you need a boom-operator and a sound recordist
on the set; then you need musicians; then you need a sound editor
during the cutting; then you need a sound mixer for the final
stages of post. Not so in a game - a single "sound designer" can
do it all. (And on small projects that person might double as a
graphic artist/ game designer/ producer ...whatever.) In a film
you need a director of photography to determine the look; gaffers
to set up lights; grips to put up bounces and flags to shape the
light; camera operators for that job; special effects for the
explosions - all these people working at the same time since you
have the set for a finite time. Then you need picture editors,
visual effects artists, lab technicians - and so on - to complete
the mis-en-scene, balance the colours correctly, et cetera. In a
game, all of that is done by the 3D artists (though there may be a
distinction between modellers, animators, lighters, shaders,
texture artists, et cetera).
In a game there is no chance that a scaffold
will fall over, injuring people; that the wind will start blowing
down grip-stands; that the sound recordist might string his cable
near fluorescent lighting and pick up some faint 60 Hz hum that
only becomes apparent months later in post (ruining the audio of
an actor's critical performance); that the neighbours might
complain and halt shooting while the crew is "losing the light";
that the actor might get upset he doesn’t have a cappuccino on
time and storm off the set; that the physical negative might be
lost somewhere on the way to the lab. In a game, everything lives
inside the digital realm that is made up and controlled by the
developers. There simply isn't the same kind of "fog of war" you
get with a film - with unpredictable elements so often coming at
the producers from all different quarters.
But game developers have their own set of
challenges. There are two in particular, unique to their industry,
which filmmakers don’t always have to deal with.
The first challenge is an elevated need to get
deeply involved in making the technical and interface standards
for the project before making many of the "artistic" creative
parts (the content). In film, the standards have remained pretty
static for many decades: 24 frames-per-second, 16mm or 35mm; or 30
frames-per-second NTSC/PAL video (analogue or digital). That’s
half of it. Lighting has remained pretty much the same,
technically: except for the introduction of HMI lights almost 20
years ago, only stylistic changes have been made. Of course there
is a whole new world of CGI special effects - but that is an
addendum to film, not a central aspect (you don't absolutely
need CGI to make a movie). Sound went from being analogue to
digital in the last decade. But the basics are the same: point a
camera at an actor, get it in focus, get the levels, and start
rolling. (Setting up is a tough job, but it is more tactical, if
you will - more here and now.) With a game, the standards cannot
be taken for granted. The actor is an artificial blob of polygons;
the camera a point in xyz space that renders a view; the
environment entirely artificial. The typical game reduces its
“shots” (if you can call them that) to a series of
paint-by-numbers data packets. When the game runs, the player’s
computer or console paints the numbers, rendering the scene on the
fly (hence “real time”). To be able to get this highly complex
process to occur accurately and with stability is a challenge, to
say the least. But the game depends on it. This is the issue of 3D
graphics programming. We haven’t even touched on things such as
physics programming, artificial intelligence programming, tools
programming, audio programming, and finally ensuring all of this
technology works with the blizzard of technical platform (home
computers) out there. And there are the game design and interface
paradigms - which tend to change radically from game to game.
Technical standards for all of this stuff continue to evolve. Even
3D graphics - which many game designers are declaring a done deal
now - are entering a new realm: fully-deformable worlds. (I have
played a "shooter" within an experimental engine using a
fully-"deformable" world - and it yields a very very different
experience, in terms of gameplay, from what we are used to in
games such as Quake.) We have yet to see the full impact of
3D technology on the experiences that will be created by the games
of the future. (However, all of this leads us to a question
which will seem obvious to filmmakers - less so to game
developers: What about the long-term earning potentials of a game?
What about developing a library? The game industry doesn't seem to
have a good handle on this, but there isn't really room to deal
with this here...)
The next major stumbling block with games is
slippage (sometimes known as "feature creep”). The virtual nature
of game development - and the removal of creative barriers it
entails - has the effect of allowing the creators of a game to
keep making and making and making, adding more and more and more.
This is well-known in the academic world as the “X+1 Syndrome" –
where it lead to the saying “publish or perish”. This is a
challenge central to game development; one where the film people
have it a little easier in comparison (except perhaps in 3D
animation). There can be slippage on a film – though usually that
will be in the pre- or post-production phases. During actual
production of a film, there is an inherent barrier to slippage:
the impatience of the crew, the actors, the producers, et cetera.
There is the sense that what has been shot has been shot. If it
was bad, oh well, you might be able to fix it a little in post,
but essentially it’s done. A driving force lingers on the set – a
sense of “let’s move on” - from the industrial nature of the art
form. Things are more physical, more here-and-now, more social and
extraverted. The crew sets up, locks up, does the shot, gets a few
takes, moves on. Game developers, on the other hand, are
challenged by a need for a kind of mental self-discipline – a need
for “thought management”. Their challenge is to avoid "imploding"
within their project. A game developer doesn't have people
standing around waiting for him to make up his mind on something -
as a director does - so they can go home and go to sleep. Game
developers must force themselves to finish details and move on.
Otherwise it is very easy to dwell on a single issue to the point
it becomes counter-productive. Slippage regularly causes game
projects to fail.
One of the major secrets to this kind of
thought management is to always confront the internalizing,
implosive nature of game development through good project
management and producing. A basic strategy is to have multiple
team-members involved in each aspect of development. No major
section should be left for a single person to create – that
individual should always need to work with another, so they are
forced to externalize, to justify their decisions, to get it done
and move on. The next strategy is to implement good project
management up front. The team members on a game project all go off
and "do their own thing" – they aren’t participating in the group
activity of “getting the shot”. So they need to have lists of what
needs to be created by when. And they need to have a correct
network structure, of what needs to be put where, to manage all of
this stuff.
There are other core cultural differences
between film production and game development - about which there
isn't as much time to go into here. Essentially, the whole process
moves at a much different timbre than film production. There may
be the temptation to graft the one process onto the other – to
treat a game as one makes a film - but that is done at the
developer’s peril.
|
|
