Tech Interview: LittleBigPlanet 2
Alex Evans on building a platform for games.
In Digital Foundry's last Saturday feature before the onslaught of E3, we talk to one of Media Molecule's tech masterminds, Alex Evans, about the origins of the company's association with Sony and how they got to grips with unique PlayStation 3 architecture.
We also go in-depth on the make-up of the proprietary engines that power both LittleBigPlanet and its forthcoming, hugely anticipated sequel.
It's a frank, candid and in-depth technical discussion about what is clearly something of a singular release, revealing a mine of hitherto unknown information about one of Sony's best-loved first party franchises.
Bearing in mind the insanity that takes grip across the games industry just prior to E3, we'd like to take time out to thank Alex for giving us so much of his time in what was clearly a very busy time for him.
Interview by David Coombes and Richard Leadbetter.
Way back indeed! When Mark [Healey], Dave [Smith], Kareem [Ettouney] and I were first debating starting a studio, the only real consensus we had was the idea of 'creative gaming' - something that engaged the player in the joy of creation. But beyond that, we wanted as many constraints as we could - we're naturally over-the-top, too-many-ideas-to-fit-in people, so constraints are incredibly motivating and constructive.
One of the first constraints was a small team, making a AAA game. For me, technically, already having chosen that we would build all tech from scratch, that meant that cross-platform would be too much of a distraction. Which narrowed the field to three really!
We were already talking to someone about doing something small - we'd just finished Rag Doll Kung Fu - but it was when our 45-minute slot with Phil Harrison took three hours and he totally challenged us in amazing ways and 'got' it (most of those challenges we have yet to fully realise, to give you an idea how forward-thinking and inspirational that meeting was) - that was when we knew we'd found the right partner.
So the two-word answer to that question could have been 'Phil Harrison'. But also, the fabled 'power of PS3' was very appealing prospect. The prevailing wind back in 2006 was that nobody would be building tech, you'd be licensing it, but nobody had good PS3 tech back then. So we immediately were on a level playing field with everyone else, despite not having a line of code. A wonderful prospect for any serially over-ambitious tech programmer...
Research-wise, we just dove in. I knew that we'd have these six SPU processors, and I'd heard rumours (incorrect in detail, helpful in spirit) that the vertex pipe was weak on the GPU. That doesn't really count as research, but it was enough of a nudge to just force us to build an engine where all the vertices are pushed through SPU.
It gave us a familiar set of problems - skinning and cloth - that we knew how to solve in a parallel way, and a great way to learn how to use the SPU. Anton [Kirczenow - senior programmer] takes all the credit there - he's amazing at getting beautiful stuff up and running with the minimum of fuss.
Beyond that we just got down to coding as fast as we could - we only had six months to prove ourselves, and we'd decided (unconventionally for Sony at the time, I believe) that the green-light build would be a fully playable 'vertical slice'.
No, the irradiance slices wasn't really a motivating factor in the look of LBP. However, the philosophy of algorithms or techniques that operate in world space rather than screen space or over vertices really appealed to me.
Artistically, I wanted LBP to tick all the 'next-gen' boxes of 2006/7 - heavy, characterful bokeh, stylised motion blur. Mark and I worked well as artist/coder and we developed a way to really layer lots of small textures at different scales to give very tactile, 'small' look, and then under the hood, I really wanted to keep the tech as uniform as possible.
I hate anything, as a matter of taste, that operates at the 'per object' level, or has arbitrary limits like 'oh you can have two hero lights and then the rest is baked into an SH probe' or 'oh we'll just lightmap everything'.
Of course, these are normally the most practical and tried-and-tested techniques, but I'd set myself a goal of just trying to do things differently, for the sake of it, preferably in the spirit of minimal code, maximally simple algorithm, even if it becomes 'uniformly slow' as opposed to 'lots of weird corner cases where it will suddenly slow down in this odd configuration'.
That's especially important for UGC [user generated content], where your designers are not sitting next to the tech team to be told what not to do.