The Making of MotorStorm Apocalypse
Digital Foundry talks to Evolution Studios about its most ambitious racer yet.
Finally released this week, Evolution Studios' MotorStorm Apocalypse marks the arrival of another high-quality, high-profile first-party release for the PlayStation 3. Sporting state-of-the-art environment deformation, 1080p and 3D support, superb dynamic lighting and an even more refined version of the franchise's remarkable physics engine, this is still clearly a MotorStorm game, albeit one quite unlike of its predecessors.
"As kids I think a lot of us were happy for video game sequels to offer minor iteration and polish, but as the medium has grown more significant differences are rightly expected," MotorStorm Apocalypse game director Matt Southern suggests.
"We felt that interest in MotorStorm would wane if we didn't treat the franchise with a 'healthy disrespect', whilst still respecting the original audience and staying faithful to our DNA. We also spotted a decline in interest in the entire genre of racing after Pacific Rift, which sold really well. We looked to the genres that were really gaining momentum for our inspiration: shooters, action adventures."
Lead technical artist Andy Seymour concurs: "It's all too easy to find yourselves treading water," he observes. "We needed to push ourselves beyond our comfort levels in order to keep the franchise invigorated."
From an engine perspective however, the studio prefers to build upon its existing work as opposed to developing a completely brand new slab of tech for each major release. "Evolution by name, evolution by nature," says lead graphics programmer Oli Wright.
"Apocalypse has lots in common technologically with our previous games. Unlike our approach to the franchise, we try and make incremental improvements to our technology rather than reinventing the wheel," Andy Seymour confirms.
"For example, on the first MotorStorm our VFX pipeline was very hard-coded. On Pacific Rift we developed an in-house editor for the artists to define VFX, and this was taken through to near-breaking-point on Apocalypse. Our animation pipeline, however, had to be completely overhauled to deal with the massive events in Apocalypse and the engine was reworked to deal with new challenges such as multiple dynamic lights."
"We were partly ready for large-scale dynamic environments already. Our object-culling approach, for example, has always used occlusion objects rather than pre-computed visibility," Wright explains. "This system just needed iterating to handle moving occlusion objects, and we also added a dynamic portal system to make our indoor sections more efficient."
Another of these evolutions was the inclusion of the SCEE-created MLAA (morphological anti-aliasing), which shifts AA processing from the RSX - a piece of hardware not ideally suited for the task - onto the Cell CPU, used by many developers also like a graphics co-processor that works in tandem with the NVIDIA GPU. Evolution adopts a different approach that is fundamental in creating its very specific gameplay experience.
"The only major pixel-pushing task that we run on SPU is the MLAA. The SPUs are mostly occupied with physics, vehicle simulation (which runs at 600Hz), animation processing, particles, scene processing and rendering preparation," reveals Wright.
"They're certainly not sat idle. If the SPUs were tied up doing lots of work offloaded from the GPU, then we'd need to have much simpler worlds with far fewer dynamic objects. That wouldn't be MotorStorm. As it stands, we have worlds with over 2000 dynamic objects in them."
Across the years - and the games - Evolution has worked closely with middleware vendor Havok in adapting its physics libraries to be more SPU-friendly.
"On Pacific Rift there were significant performance gains over previous versions thanks mainly to increased SPU usage, so by the time we were working on Apocalypse the big performance gains had already been made," confirms physics programmer Dave Kirk.
"However, the lessons we learned from the early products enabled us to really streamline our code. This meant we could squeeze even more tech in, such as our groups of NPCs, as well as significantly ramping up the amount of dynamic objects and destruction."
A core element of the new MotorStorm are the 'Events' - episodes of seismic destruction that change the circuits as you play, realised in the form of some spectacular graphical set-pieces.
"From a production standpoint the key challenge was to define and create an entirely new team - the Events Team - who could deliver the quality animation and VFX solutions we needed in high volumes," explains Matt Southern. "Nick Sadler joined us from Studio Liverpool (who were invaluable throughout the project), to help run things."
"Continual refinement of gameplay and visuals was invaluable in achieving final results, so it was key to have a process which allowed frequent reviews and frequent iteration," Sadler elaborates.
"The biggest issues faced in preparing the events were pretty fundamental design challenges: how would the event affect gameplay before, during and after it had triggered? The events were designed with fairness in mind from the beginning: they should be triggered far enough away so that the fastest vehicle with a clear run at full boost would experience as much of the event as possible and not be disadvantaged. No dynamic object could have sufficient mass to radically affect the gameplay negatively, or take out the player unfairly.
"We knew that the player could learn the motion of events, and how intrusive they would be onto the racing line, but wouldn't know if events would trigger. There's definitely a need for twitchy reaction and skill in adapting to the order of events."
Sadler goes on to discuss the challenges of conceptualising the event design process, using blockout assets - basic building blocks used in the prototype game engine to test whether a particular set-piece would work or not. "We also had to make significant alterations to the modelling/animation pipeline for interactive events," he adds.
"There was a good amount of 'chicken vs. egg', when moving between interactive pre-vis-quality events and interactive production-quality artwork and collisions: approving gameplay if the interactive blockout might be different to the production version vs. having artists commit to investing in a production-quality asset, without a blockout to prove its worth.
"Another issue came about because of the sheer number of contributions necessary in preparing the artwork; from modelling, to animation, to VFX/particles, back to modelling, then to audio, etc. Getting the right person working on the right aspect of the event at the right time was initially a pain, but we were well-managed, and the team was amazing in producing 280+ events on a tight schedule."