How the left and right brain learned

to love one another

Tim Moss
Sony Computer Entertainment America,
Santa Monica Studio.
Presentation Objectives
Post Mortem
Team Structure
High level Summary of methods
 Brief History
Studio started in 1999
Fun Games that Sell
First project Kinetica
An average game that sold averagely
(But had nice technology)
 Objectives
Establish a new Franchise for Sony
A 3rd Person Action Platformer
taking the best elements of ICO,
Devil May Cry etc.
Cinematic Camera
Epic Story
Casual Hardcore
 Design Objectives
Lots of special cases
It should feel REALLY BIG.
Feature creep dont exactly
know what I want but I will know
it when I see it.
Game should keep moving, no
obvious repeats.
 Programming
Objectives
60 Frames Per Sec
Technically outstanding on release.
Build game / engine methodically, to
avoid wasting time and reduce bugs.
Avoid special cases
Prevent the programming department
from becoming a bottleneck
Spend the last month of the project on the
beach while the game is being completed.
 Bridging the
Communication Gap
Left brain / Right brain
Designers want special cases
Programmers hate special cases
Tools were the answer
Studio Layout
 Open plan facts
Facilitates conversation
No-where to hide so productivity
seems better. Cant surf Ebay all
day.
You feel like youre in a team.
Headphones are vital.
Difficult to avoid seagull
management.
 Team Structure
Code team (7)
Design team (10)
Art team (22)
Sound (3)
Production (4)
 Code Team
7 Senior Programmers
Broad responsibilities
Usually a single point of contact for
a given system
 Design Team
Game Director
4 Level Designers / Scripters
3 Combat Designers
2 Sound Implementers
1 Camera Designer
 Art Team
Art Environments (6)
Art Animation (5)
Art Characters (4)
Art Concept (3)
Art Technical Artists (4)
 Technical Artists
A group of 4 for GoW.
Helped the Programmers structure
the tools.
Helped design interfaces for the
Maya users.
Troubleshooters
Helped us avoid over-engineering.
Asset Creation based in
Maya
Art Environments, Characters,
Particles
Collision Separate geometry from Art.
Camera Placement
Entity System (Scripting)
Sound / Music Triggers
Visibility Triggers
Loading Zone Triggers
Waypoint layouts
 Asset Control
Alienbrain . Used simply as a file
structure system. Not at all
customised. Thats probably why
its ok for us.
The programmers didnt use it for
code.
 Maya File structure

World

Cameras Entities Visuals Waypoints Sound

 File Structure
Allows multiple people to work on
different aspects of the same level.
Common interface allows cross
pollination of responsibilities.
Helps with bottleneck issues since
chances are higher that someone else
can do any given task.
 Build Tools
A single tool processes the .mb file
producing:-
Binary chunks
PERL Include Files
Only changed pieces of scene are
rebuilt subsequently, the rest
comes from the cache.
Complete Level data file is
assembled using a PERL script.
 In Game Tweaking
Some stuff can be edited in game
Cameras
Combat specifics
Fog
Saved to disk, included into the
WAD file on the next rebuild.
Tweaks are checked into
Alienbrain.
 Easy workflow
Every person has Maya installed,
along with the current build of game
and tools
Any person can build any asset of the
entire game on their own machine.
Fast iteration time when editing
specific assets.
No programmer intervention required.
 Code Structure
3 time rule if a request comes through
3 times, its probably something thats
really wanted.
Evaluate any serious design request
with an eye to adding a feature to
support it. Build it in neatly and in as
general way as possible.
Dont Hack EVER. You will pay for it later.
HOWEVER Resist the urge to over-
engineer
 Simple AI / Player
structure
Common code for all enemies and
the player
Navigation / Combat in 2 separate
systems so that 2 programmers
could work concurrently.
Easier to debug
Much less code
 Navigation Code
Objects represented
by a capsule.
Line tests into the
collision to find
surfaces.
Separate Physical
Position from actual
position to reduce
pops.
All characters use
the same code.
 Combat / Move System
Every single character in games used same
Combat / Move system, even the player.
Designers could cut up anims
Special tools to allow real-time tweaking of
combat from a PC.
Branches setup to occur on :-
Hits from or to other chars
Environment hits
Timers
Button presses
Etc.
 Combat / Move System
Details
Add sound effects
Add visual effects
Play at different speeds
Synchronize with targets
Add Button press triggers.
Track and Field Play back.
 Player / AI
Player :-
Joypad converted into a Worldvector,
this drives motion
Buttons control which combat moves
are called
AI :-
World Vector is calculated, used to
drive motion
Decision Tree decides which move.
 Waypoints
Created using a tool in Maya
Overlays a grid onto a Room in
Maya.
Designers can paint accessible
gridsquares.
Tool automatically sets up linkages.
Enemies can then use this to
navigate through environment.
 Synchronized
Animations

Player can synchronize animation with an

object in the environment.
Puts the job of doing special case in the hands
of the animators and designers.
Synchronized Examples
Cranks Play a synced animation,
and player stays attached to the
handle. Handle can be moved
anywhere by animation.
Lift Doors Use track and field
mechanic.
Combat all over the place.
 Entity System
Annotation system for game levels
Allows designers to add reactivity by
connecting "events" to "actions",
e.g.
"pull lever" -> "open door"
"player in zone" -> "load next level
Designers create entities and zones.
Connect them and edit attributes in
a MEL based editor.
 Entity System - Tools
Various Entity Types
Sensors Detect Entry / Exit from zones, Creation /
Destruction of objects
Actuators Play Animations, Control visibility, create
objects /
Entities have attributes, some are common, some are
custom per type.
Attributes may contain in-line script code, e.g.
"Enabled: (GotShield && GotKey && ! DoorOpened)
"Execute: if (OnBeam) SetCamera ('OverheadCam')
Scripting is very simple in scope:
if/else, int/float/string variables, built-in commands
NO loops, user-defined functions
Interconnection between entities is very limited:
Sensors can only trigger actuators
Many-to-1 and 1-to-many is allowed
 Entity System - Game
All creatures / objects have
"markers" that are tracked as they
move through "entity zones"
This motion, as well as internal
game activity, give rise to
messages that are passed among
entities
Interpreting entity attribute scripts
changes the internal game state
 Camera System
Completely scripted
No Collision
No line of sight checks
Set Design Level building strategy.
Cameras can be controlled by the
entity system.
 Camera System Contd
Static Fixed Position, Direction and FOV
Animated
Dynamic constraints setup in maya.
Actual position calculated by game code.
Action Zoom Combat controlled, aims
at character, plays with FOV.
Multiple cameras can run at once.
Cameras can be overlapped to avoid
rapid switching.
 Visibility System
Entirely setup by hand.
We always know where the camera
is, what its pointing at.
Camera Position controls visibility.
 Environmental Sound
and Music
Sound effects can be added to
animations within Maya by a
designer.
Atmospheric sound zones can be
placed in a region.
Music triggers can be done the
same way
 Memory Management
32 Meg
memory

1.5 Run Perm 4*1 Meg 16 Meg for Levels, split into 2
Meg Time Data Enemies
Exe Data

Establish Hard Rules.

16 Meg for Level Data (Split into 2 Levels)
4 * 1 Meg for Enemies
 Memory Management
contd
Let Art / Design do their own Memory
Management.
Avoids Pigeon Holing anyone. Every level
ends up being a good compromise.
Tools for memory tracking available in
game.
The artists frequently spotted memory leaks
/ problems using this.
Level Loading Scheme
Load
Level B
Block
Level B

Level A

Block
Level B
Level A
Load
Level A
 Level Loading Scheme
2 Levels loaded simultaneously. Either
Current Level and Last level, or Current
and Next.
Design places Load Triggers. These kick
off a level load.
Also place Load Blocks.
Simple rule allow 1 sec of travel time for
every 1 meg of level that needs to load.
4 enemy slots also changed out at Level
Load time.
 Flash
All Front End and HUD elements
done using Flash. Heavily
optimized for the engine.
Compiler is freely available on
website.
Allows prototyping and design
without programmer.
 Optimising for Speed
Frame rate is displayed front and
center to everyone, 60fps regarded
as the 100% CPU and GS.
Lead Programmer hassles them
endlessly about 60fps.
The Frame Rate lies to everyone
 Scheduling
Overall Task List for the whole
project, broken down by
programmer.
Updated regularly
Only added time estimates for
what was being done next.
Bang for the Buck approach.
 Did it work?
Executable for God of War was 1.5
meg. No code loading was done.
General code made the game
small, more cache efficient. Ran
faster.
Engine / Tools are being used again
on GOW2. Also moving on to our
PS3 titles.
 Testing / Debugging
500 Bugs in database 2 weeks
from Gold Master. 25 were
Programmer bugs.
Led to a more bug free game no
single group was overwhelmed.
 Summary
Programmers dont drive game
development like the old days
Expect more from Art and Design.
They can cope with it.
Programmers are able to provide a
logical left brain structure to the
project that the creative right
brain types arent even aware of.