How the left and right brain learned to love one another

1. How the left and right brain learned to love one another Tim Moss Sony Computer Entertainment America, Santa Monica Studio.

2. Presentation Objectives • Post Mortem • Team Structure • High level Summary of methods

3. Brief History • Studio started in 1999 • ‘Fun Games that Sell’ • First project ‘Kinetica’ • An average game that sold averagely (But had nice technology)

4. 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’

5. 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.

6. 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.

7. Bridging the Communication Gap • Left brain / Right brain • Designers want special cases • Programmers hate special cases • Tools were the answer

8. Studio Layout

9. 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.

10. Team Structure • Code team (7) • Design team (10) • Art team (22) • Sound (3) • Production (4)

11. Code Team • 7 Senior Programmers • Broad responsibilities • Usually a single point of contact for a given system

12. Design Team • Game Director • 4 Level Designers / Scripters • 3 Combat Designers • 2 Sound Implementers • 1 Camera Designer

13. Art Team • Art – Environments (6) • Art – Animation (5) • Art – Characters (4) • Art – Concept (3) • Art – Technical Artists (4)

14. 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.

15. 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

16. 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.

17. Maya File structure World Cameras Entities Visuals Waypoints Sound

18. 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.

19. 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.

20. 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.

21. 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.

22. 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

23. 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

24. 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.

25. 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….

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.

32. 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

33. 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

34. Camera System • Completely scripted • No Collision • No line of sight checks • Set Design Level building strategy. • Cameras can be controlled by the entity system.

35. 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.

36. Visibility System • Entirely setup by hand. • We always know where the camera is, what its pointing at. • Camera Position controls visibility.

37. 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

38. 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

39. 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.

40. Level Loading Scheme Load Level B Block Level B LevelA LevelB Block Level A Load Level A

41. 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.

42. 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.

43. 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

44. 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.

45. 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.

46. 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.

47. 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.