Digital Foundry vs. LittleBigPlanet 2

Media Molecule's LittleBigPlanet remains to this day a remarkable game - a title whose longevity is entirely down to the ingenuity and enterprise of the people playing it. Long after the game's preloaded levels are complete, LBP continues to enthral and entertain thanks to the mammoth collection of brand new stages created by a large, vibrant community.

In Digital Foundry, we often discuss the techniques developers use to take on the fixed hardware of the current-generation consoles, repurposing the platforms to create experiences and effects we've never seen before. Such is the flexibility of LBP's content creation system, we see designers doing similar things with the game engine, coming up with brand new ways to subvert the system to create levels with features way beyond the imaginings of the Media Molecule team when they developed the game.

LittleBigPlanet 2 has been operating in a closed beta for some time now, with journalists given access to the servers a short while later - a canny move by SCEE and Media Molecule as we instantly get access to a relatively well-stocked array of user-generated levels in addition to the small batch of stages provided by the developer's level designers.

Eurogamer has already posted a hands-on feature, but the Digital Foundry focus is different. In addition to our usual performance and image quality analysis, ardent LBP player and level designer David Coombes joins us to give us a technical appreciation of the revised rendering engine, along with an in-depth breakdown of the new content creation tools.

Media Molecule's aim to support all the existing LBP user-generated levels also gives us a unique opportunity to test out a couple of important elements in the sequel. Firstly, the developer's claim to support all homebrew levels from the first game can be put under scrutiny - can a game with so many differences, refinements and improvements in its tech truly be fully backwards-compatible with the old game?

Secondly, through the construction of our own levels, we can create specific scenarios that allow us to highlight the changes and improvements Media Molecule has made to the rendering tech. We've already got a pretty decent idea of the refinements made to the underlying engine in this regard, thanks to the awesome tech interview we carried out with Alex Evans just prior to E3 this year, but with code in-hand we can run the self-same levels through both LBP1 and the beta, and produce comparison shots between the old game and the new.

Before we get onto that though, let's take our first look at performance: to give some idea of how the code's looking, we'll restrict ourselves to the small batch of Media Molecule stages and dot the three major levels supplied throughout the feature. This beta is interesting in that it gives us the opportunity to compare our own performance analysis tools with the one of the developer's: at the bottom of the screen, you see various bits of debug data, one of which is the time taken for the frame to render.

LBP2, like its predecessor, has a target frame-rate of 30FPS, which equates to 33.33ms of rendering time allocated to each frame if it is to maintain v-sync. Any higher and the game will tear, and if consecutive frames exceed budget, the tear remains on-screen, cascading up or down.

Having the game tell us exactly how long the frame is taking to render is obviously a useful bit of information to have in hand - however, frame-rate is capped at 30FPS, and this is reflected in the on-screen indicator, so it is only really useful as an indication of when the engine is running over budget as opposed to giving us a rounded view of how long a frame takes to render: even a completely empty scene in the content creator still gives a 33ms timing.

However, as discussed in the tech interview, the developer favours a fixed-cost system of rendering. In theory, no matter how complex the lighting for example, it'll take the same time to generate. This means that level designers - be they from Media Molecule or from the gaming community - can work with whatever light sources they want, for example, and the game's performance won't be so easy to break.

Obviously, geometry levels are a contributory factor to an engine's performance level, but the LBP2 tech is far more about processing pixels than it is about processing vertices, and even here we know that vertex-processing is offloaded from the RSX graphics chip with the Cell SPUs doing the heavy work there. The overall sense is of a refined, elegant solution that plays to the hardware's strengths.

That said, it's still clear from the beta that a fair amount of optimisation needs to be done. If the rendering is consistently over budget you can get some pretty off-putting screen-tearing, and there are couple of areas in Media Molecule's own levels where this is a commonplace occurrence. What is curious is that in the space stage of the beta, in a scene of arcade machines playable by the player or Sackbots, performance drops pretty radically, yet the view is mostly zoomed in and not showing much content.

Based on what we've seen of the beta, performance is very much in the same ballpark as the original game but there are many, many image quality improvements. The first game's native 720p resolution is retained but aliasing is radically reduced thanks to the inclusion of morphological anti-aliasing, or MLAA. In the first batch of screenshots we saw, it was selectively implemented - but in the beta the coverage is far more impressive – for example, the grapple wires are edge-smoothed now, while previously they were not. MLAA is now a part of the Edge tools available to all PS3 developers and it's effectively a drop-in component that can be added in an afternoon of coding - expect to see it in many more titles, not just those from Sony.