God of War โ€“ post mortem

Year 2005, last months of Playstation 2, next-gen consoles are coming. This is usually a good moment for ‘farewell hit’. Developers know the platform inside-out, there’s huge userbase. Sure enough, Sony Santa Monica creates God of War, game that later would be considered one of PS2’s greatest titles. I must admit I’m not that big fan of GOW’s gameplay (I suck at action games, though). Technically, however, it’s one of the most impressive games I’ve seen in the recent years. It’s fast, it’s pretty, it’s solid. At GDC 2006 Sony’s Lead Programmer - Tim Moss had talk titled ‘God of War: How the Left and Right Brain Learned to Love One Another’.

I read it, remembered mainly that it was interesting they had used Maya as main tool and kinda forgot about it. Only recently I’ve found out that recording from this session has been made available (for free) as well. You can download it here. Combined together they’re really interesting and I recommend everyone to spend few minutes and listen to it while reading slides. I find some similarities to our situation there, many differences (cough) and many great ideas. Random notes:

  • Sony Santa Monica started in 1999, their goal was to make ‘Fun Games that Sell’ (not revolutionary, you’ve to admit’ I dont recall many companies wanting to make crap games that dont sell). Their first project was Kinetica. Tim admits himself it didn’t really meet established requirements - using his own words it’s ‘an average game that sold averagely’. They were rather satisfied with technology created for this title, though.

  • Next title was God of War already. Basic idea started as a 3rd person action platformer with gameplay elements inspired by Ico, Devil May Cry, Onimusha (hardcore elements) etc. It was David Jaffe’s idea to put it in Greek mythology background.

  • At the beginning, when they started plannning/prototyping, it turned out there’s big difference between priorities for programmers and designers, their objectives are often exactly opposite (ie, designers love special cases - programmers hate them).

  • Interestingly, first programming objective mentioned is: 60 frames per second. I couldn’t agree more. Well, I don’t really care that much if it’s 60 or 40, but I think it’s really important to start with game running at planned (high) framerate and keep it there all the time. Unfortunately, it’s possible only if you start with title already running with solid framerate. Still, it probably is good idea to optimize at the beginning of your project and then maintain performance than to hope for the best 6 months before release. We made this mistake with The Witcher and even though we did manage to speed it up significantly, we couldn’t be 100% satisfied with the result. Tim notices an important thing: if you have a game running at 60FPS it makes your whole team work more carefully. There’s no place for sloppiness at this level of performance. Everyone tries to optimize his code as much as possible, to keep it running at high speed. People tend to care less if it works 15FPS anyway’ After all, it’s so slow, who cares if my routine isn’t 100% optimized, right? For me it’s a little bit like driving a motorbike. If you go 50mph, you can make lots of mistakes and they’ll go unnoticed, you may have to slow down to 40mph, but that’s it. At 250mph, one wrong move, one tiny bump and you’re an ex-biker. (Interestingly, designers didn’t really care about framerate).

  • Other major objectives were usually connected with simply letting designers to their job. It sounds obvious, but still many studios do it wrong and focus on fancy technology just for the sake of it. At the end of the day, no one cares how smart your code is when the game isnt fun’

  • There were only 7 programmers in the team! Impressive number for a Western studio these days. It’s a little bit similar to our situation, when we started there was 4 of us, at the end of the project around 10. Difference is that all GOW’s programmers were experienced seniors, in our case we had only 3-4 coders with any prior experience (I think it’s a nice testament to ‘new guys’ skills, if we still managed to pull it off). Each programmer was responsible for fairly major subsystem (camera system, scripting+front end and so on). It helped communication because everyone knew who deals with what.

  • 4 technical artists! (and it was time they weren’t that popular as nowadays)

  • Maya used as a game editor (all the art, collisions, camera tracks, scripting, triggers etc done there).

  • Fast forward to coding rules. They had nice ‘3 time rule’. Brilliant observation of many designers suffering from Bright Shiny Object Syndrome. For the feature to be seriously considered, it had to be demanded at least 3 times on consecutive days.

  • No HACKs. I think that most teams have this rule. Challenge is to obey it.

  • Avoid over-engineering (constantly ask yourself: should I really be doing this?)

  • Camera system is completely scripted, it doesn’t even need collision/line of sight checks. (I think there was more detailed presentation on GOW camera topic alone)

  • Fixed, scripted camera allows for extremely simple, but very effective visibility system. You always know where the camera is and where does it point, so you can manually disable stuff it can’t see. I think this one system sums GOW’s team coding philosophy perfectly. Many programmers wouldn’t even consider such ‘trivial’ solution, they’d be busy implementing latest Siggraph VDS with occlusion culling. It would take 9 months and still would be less effective.

  • Streaming system was equally elegant and simple. Designers had 16MB for level data and they could divide it between two levels as they wanted. Streaming was controlled with triggers, there were two kinds of them: triggers that would kick off streaming for another level and another kind that would block the player and display loading screen if it was reached before all the data has been loaded. There was also 4MB of memory for enemies. This ‘moved’ problems with managing this to designers themselves. They need to work as a team to achieve the best possible final result. If I create level taking 15MB, guys making the next one will simply kick my ass, we’ve to decide on limits together.

  • GUI was done using Flash with custom, heavily optimized player.

  • Framerate shown all the time (60FPS rule).

  • Did it work? Well, they definitelly did create a Fun Game That Sold :)

End trivia: it shouldn’t be surprising, but Tim Moss used to be famous Atari ST democoder. His group (The Lost Boys, another founding member was his brother - Dave) produced demos like Mindbomb or Def Demo.

[Edit[ For people who don’t read comments: presentation on GOW’s camera system I mentioned can be found here.

Old comments

Christer Ericson 2008-09-02 02:31:15

Maciej, Phil’s GDC’08 presentation on the GOW camera system is available for download here.
I’d be interested in hearing about the “many differences” you mentioned. Perhaps we have something to learn from them!

admin 2008-09-02 07:40:37

Thanks for the link!
About the “differences”, I said it half-jokingly, mainly about things that went wrong (in our case) in mind :)

[…] God of War - postmortem | .mischief.mayhem.soap. "At GDC 2006 Sony’s Lead Programmer – Tim Moss had talk titled “God of War: How the Left and Right Brain Learned to Love One Another”. I read it, remembered mainly that it was interesting they had used Maya as main tool and kinda forgot about it. Only recently I’ve found out that recording from this session has been made available (for free) as well. You can download it here. Combined together they’re really interesting and I recommend everyone to spend few minutes and listen to it while reading slides." Some interesting stuff - God of War pre-scripts a lot of things that other people might want to do in real time, and as such, makes some stuff simpler, and makes controlling the players' experience easier. (tags: sony santamonica programming godofwar postmortem games gdc development notes presentation ) […]

[…] God of War post mortem […]

Code edition god library name 2010-12-14 21:45:11

[…] God of War - postmortem | .mischief.mayhem.soap. Aug 30, 2008. Summary of God of War GDC postmortem.. At the end of the day, no one cares how smart your code is when the. Name (required). E-mail (will not be published) (required). The Little Schemer รข?? 4th Edition by Daniel P. Friedman ,. Game Engine Architecture by Jason Gregory. View full Library God of War - postmortem | .mischief.mayhem.soap. […]

More Reading
Older// NVScene 2008