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…… don’t 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. Can’t surf Ebay all day.
• You feel like you’re 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
Art
Art
Art
Art
–
–
–
–
–
Environments (6)
Animation (5)
Characters (4)
Concept (3)
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.
That’s probably why it’s ok for us.
• The programmers didn’t 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 that’s 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.
• Don’t 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
Meg
Exe
Run
Time
Data
Perm
Data
4*1 Meg
Enemies
16 Meg for Levels, split into 2
• 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 A
Level B
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 don’t 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 aren’t even aware of.