How the left and right brain learned to love one another
Download
1 / 47

How the left and right brain learned to love one another - PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on

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’

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'How the left and right brain learned to love one another' - keegan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
How the left and right brain learned to love one another

How the left and right brain learned to love one another

Tim Moss

Sony Computer Entertainment America,

Santa Monica Studio.


Presentation objectives
Presentation Objectives

  • Post Mortem

  • Team Structure

  • High level Summary of methods


Brief history
Brief History

  • Studio started in 1999

  • ‘Fun Games that Sell’

  • First project ‘Kinetica’

    • An average game that sold averagely (But had nice technology)


Objectives
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
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
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
Bridging the Communication Gap

  • Left brain / Right brain

  • Designers want special cases

  • Programmers hate special cases

  • Tools were the answer



Open plan facts
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
Team Structure

  • Code team (7)

  • Design team (10)

  • Art team (22)

  • Sound (3)

  • Production (4)


Code team
Code Team

  • 7 Senior Programmers

  • Broad responsibilities

  • Usually a single point of contact for a given system


Design team
Design Team

  • Game Director

  • 4 Level Designers / Scripters

  • 3 Combat Designers

  • 2 Sound Implementers

  • 1 Camera Designer


Art team
Art Team

  • Art – Environments (6)

  • Art – Animation (5)

  • Art – Characters (4)

  • Art – Concept (3)

  • Art – Technical Artists (4)


Technical artists
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
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
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
Maya File structure

World

Cameras

Entities

Visuals

Waypoints

Sound


File structure
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
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
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
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
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
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
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
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
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 / 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
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
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
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
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
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
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
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
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
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
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
Memory Management

  • Establish Hard Rules.

    • 16 Meg for Level Data (Split into 2 Levels)

    • 4 * 1 Meg for Enemies

32 Meg memory

16 Meg for Levels, split into 2

1.5 Meg Exe

Run Time Data

Perm Data

4*1 Meg Enemies


Memory management contd
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
Level Loading Scheme

Load Level B

Block Level B

LevelA

LevelB

Block Level A

Load Level A


Level loading scheme1
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
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
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
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
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
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
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.