Tech Interview: LittleBigPlanet 2 • Page 3

Alex Evans on building a platform for games.

Digital Foundry: So, LBP ships and the tools you've created are handed off to the gamers. What was the first level you saw that genuinely surprised you in how it utilised your tools? In the here and now, what are your best recommendations for user-generated content?

Alex Evans: The best content is always picked out by Tom and Spaff, our community managers - and @mmpicks on Twitter - so for the time being, that's where I go! Or I check the hearted levels of some of the community's famous creators. That kind of social bookmarking will be taken further once all the data is visible via, when LBP2 comes out.

The private 'Friends and Family' beta threw up almost no good levels - I remember a shaky cardboard deathstar dropping down an otherwise empty level, and rejoicing that they'd been able to build something - but it was within 24 hours of the public beta going live that the true genius of the community shone!

I remember seeing the tongue-in-cheek US election voting levels - in which you could detonate the candidate of your choice, and vote for the other, for example - which really made me smile and surprised me, or the famous little-big-calculator level, which was posted very soon after the game launched.

I loved the 'music video' levels that popped up quickly too - "No Surprises" by Radiohead was on there as a whole story - a total abuse of the sound objects that really made me happy. The sign of a good tool is always when it is used in ways you didn't believe possible. The stuff more recently, like the use of the 50-layer 'bug' to create backgrounds, is just wonderful.

Digital Foundry: User-created content seems to be represented in two different ways - high order curves for the curved brushes (circle, ellipse), and simple polygons when point-edited. Is this so? Are the limits to providing users with drawn curves to define shapes technical or design limits?

Alex Evans: Actually, it's all one code-path. It's all just 'polygons with holes' as far as the game engine is concerned, and then we chamfer, bevel, extrude and sometimes clothify to build the mesh. I'm not sure exactly which limits you're referring to, but we do cap the number of vertices in any given shape just to make our lives a little easier - there are fixed memory pools for things like vertices and so on, so we have to cap things somewhere!

Digital Foundry: The adoption of the MLAA form of anti-aliasing is a huge improvement for the image quality, and people are excited to see this technique appearing in more titles. So, how hard has it been to include? Did it slot nicely into LBP's post-processing step or like Santa Monica with GOW3, did you have to massage the engine to free up SPU cycles in the middle of each frame to keep latency down?

Alex Evans: We really got to ride on their shoulders there - when we got the MLAA code from Sony, it was already in a pretty usable and fast state. We dropped it in during an afternoon, I believe, and it did save us a little GPU time. As with any change, there are knock-ons, a bit of SPU rescheduling etc, but it's definitely a net win.

Digital Foundry: What is this AA technique being called among developers? Is it morphological AA, MLAA, as Intel described it, or are they calling it something else?

Alex Evans: We call it MLAA. But then again we do lots of things that we don't have names for or make up without knowing the literature, so I have no idea what others are calling it!

My favourite techniques and engines are the ones that blend techniques anyway, so as soon as you try too hard to categorise something, the value in the name tends to drop off: you know, the 'oh it's kinda SSAO but then I changed it with a dash of this and that and threw in some blur in post and some precomputed irradiance stuff with a dash of photonic voxel warp drive potatoes'. And so it goes on...

Digital Foundry: In your shots it seems to be the case that MLAA is being used selectively, not on all edges. Is this something that you'll address for the final game or are there limitations in the technique?

Alex Evans: We're still tweaking everything in LBP! A journalist asked me once when I showed him yet another new feature in LBP, 'Why didn't you tell us about it last month/year/whenever?' The answer being, because it wasn't written yet. We show stuff very, very close to when we make it, because feedback and exposure is the best motivator for any team.

Digital Foundry: Why were AI bots so expensive in terms of thermometer cost in LBP? A spawner set to create creatures would gobble resources. Is this something that's been remedied in LBP2, or is the improved AI to remain costly?

Alex Evans: Yes, it's not so much AI as the way the thermometer used to work. Briefly, we created a bunch of limits for things like switches, bots, shapes, stickers, etc, and then just statically analysed the level, and showed you the 'worst' of all of those limits. And the limits were just set more or less arbitrarily, based on the levels we had built ourselves.

For LBP2, we've rejigged it significantly. We take more care (and processor time) measuring the cost of a level. And we allow each different area of code/memory/CPU/GPU to eat into global 'budgets'. So if you skimp on one area, you might be able to do more of another, or you can have more 'balanced' levels.

Another example is that emitters used to have to take the 'worst case' view, since the analysis was static - but now we actually re-compute the thermometer cost as the level evolves.

Limits are a very difficult thing to get right - given the dynamic nature of levels, especially emitters - and we want a stable, high-quality console experience that never crashes, while simultaneously not putting too many arbitrary limits on people's creativity. It's a very fine line, and one that we've refined a lot from LBP1 to LBP2.

Comments (25)

Comments for this article are now closed, but please feel free to continue chatting on the forum!