GDC09: Making of Little Big Planet (ups, downs, mistakes, successes)

Alex Evans, Media Molecule
Mark Healey, Media Molecule

Summary

The MM guys are funny as ever, although Alex’s “I made it myself on the way here” presentation tool would perhaps have been more usefully replaced with something like Presi (or whatever it’s called – the “interactive” presentation tool that is like Alex’s thing, but on steroids. Ask Jussi, he’s a fan of it).

The overall impression I got is: here’s another studio that has “by trial and error and cunning and talent” independently discovered something very similar to Scrum. They don’t do Scrum, and I’m sure a lot of people will scream at me for even saying it, but … I went through similar “find a process that worked for game development” (not carried so far, and on much smaller projects), and I recognize a lot of the lessons they learnt and things they incorporated in their processes and approaches. And from my experience, I think they’d find it relatively easy to switch over to Scrum, and that they’d get a lot of benefit from having a more polished version of their processes. Not to say that Scrum is universally better – there’d be losses too – but for people considering their own processes to use – or trying to “understand” Scrum – you’d do well to read this liveblog and try to internalize some of the lessons and attitudes. And then consider this and scrum as alternative to each other, but both near-relatives. And … if you are *not* MM, and don’t have all the details of precisely how they work, you’d probably find it much easier and more effective to adopt the well-documented Scrum instead.

All errors and misattributions my fault. There were two speakers, they chopped and changed arbitrarily, so I’ve not recorded “who said what”. Sorry. My comments [in square brackets].

Fun

What was fun about LBP was that we failed a lot, and failed quickly.

Thanks to Alex’s hate of powerpoint we have an app he wrote on the plane on the way here, so I’m incredibly nervous.

[its a shared whiteboard app with their mac’s linked together]

This is the spiritual successor of a talk we gave at 2007 GDC ten minutes after announcing the game … in a tiny room to a small audience. We showed the game, and people said brilliant, it looks done, but it took another 2 years, and it very much wasn’t done.

People think we’re a bunch of hippies, but our first hire from ex LH people was a highly organizational very experienced producer. So we had a miletone every month, and we never missed a milestone. We conveniently only set them one month in advance, so we could invent what we were actually going to capable of just in time.

When we were at LH, we were put into a little room and allowed to do whatever we wanted. We had no milestones, no schedules. We did that for a long time at LH and got used to it. Mixing that in with our producer, who was very organized, was very interesting. Big culture clash.

Milestones

Our milestones were: run round the office with a handycam, film people, and show what we’d done that month.

[milestone 5 video: snips of LBP as it was back then. MS4 we had first pass at a level, art sound, basic mechanics, etc [then he skipped the video 3 minutes to a gameplay video. Had the cloth style, and cloth badges as nav structure already. Very low poly renders.Pricne from KD as one of the characters. Four players doing synchronized actions on screen, dancing, then the skateboard example. Here’s a 3 month blind alley: elements of the gameplay of the final first few levles are visible here. Came out of a piece of art by our art director that looked like this howl’s moving castle meets beanstalk, and we loved it so much we spent 3 months intensively on trying to make it work with vertical gaemply/level orientation. Because it was vertical you were spending all your time jumping back and forth fighting gravity, and we didn’t spot the wood for the trees for a long time, didn’t accept / recognize the obvious fact it just wasn’t fun and wasn’t going to be. Ths skill is knowing when to say this is not working, it’s shit.]

Q: was there an average time you spent on exploring different ideas before killing them?

Typically around a week to two weeks.

Alex: Personally, I added a cool 3d ribbon that wound through the level, but the desigenrs never used it. And I was really unhappy to accept for sevral months that it needed to be removed because it made the code too complex, added a seocndary parallel co-ordinate system. But when I did finally go in and delete it from the codebase, and factor it out, I found I was fixing bugs and simplifying code all over the place, and by the time I finished I was happy, and convinced it was absolutely right to remove it.

LBP had to be an eidtor that was powerful, but … was also fun to use. This was our key thing we wanted to achieve. So for a long time we were convinced we’d have no distinction beteen play mode and edit mode.

Here’s the inventory: you had to go into a physical spae and walk around and explore the physical space to look at the inventory.

[ADAM: Home]

We were really keen to keep this in the engine. All the tools were built as gameplay items [ADAM: as opposed to vice versa]. e.g. colouring the background, your avatar had to manually slowly paint the background with a paint roller. Evetually we realised this was insane and we needed to make the eidtor tools much more like an editor. We had to leave behind that physicality.

We spent a long time on that one, having views and talking in words, but then the crunch point came when we actually tried to implement it. In our team, if someone is passionate and voncineced of an idea and no-one else is, often what ahppesns is they quietly go off and make it anyway to try and prove it.

[vidoe: exampel of someone showing makign something non-[hysical in the world]

[menu-based system Create/Change/Share/Quit that pops up on screen projected out of the avatar’s body]

I think a big factor in helping us recognize when we were going down a blind alley was that we had a very good QA team, they were totally unafraid of telling us when something was shit.

For GDC07 video we had a kind of mini x-media bar. But we’re professional video game developers, we’ve spent our lives sitting in Maya etc, with everything broken down in a very technological matter. But we found that’s just not fun, the user experience doesn’t make sense, it didn’t feel like a console experience.

[ADAM: basically: Maya et al still suck donkey from the GUI aspect, but can’t really change the patterns that x million artists have all got memorized and internalized in their heads by now]

We identified that we had a problem of it took too many button clicks to change from “move” tool to “scale” tool. Over and overa gain we were attacking the wonrg problem, tryign to find a “perfect” button mapping. But there was one small piece of the editor that was fun, and that was the stickers, and stamping stuff on things.

It was pleasant and fun to press a button and get a reaction in the world. So we said “everything should be as simple as placing a sticker”.

This of course made everything much harder on the tech side, because now we had to make a really good CSG system. This was a late stage in the project, this was post greenlight, post GDC reveal, we were now in full production. We were ripping out our tools and putting in a core feature that we knew for a fact was technically going to be very hard, and doing this late in the project.

Then we tried pie-menus.

Community and Sharing features

An area we backtracked a lot in particular was the Share part of it. All the reference points are web-based, browser-based, AJAX, form-based, assumes a mouse and a high res monitor, etc. It’s amazing how much is assumed, and we ended up trying to make things lots of text but throw in more and more images. we were using tiny fponts that were fine on our HD TV sitting on our desks, but sucked when we took it home and played at home on low-def TV from the other side of the room. In the end we probably launched with an oversimplified slight overreaction to that, and we certainly haven’t got it completely right yet.

Anything within 2 clicks of hte front page will get an order of magnitude more play counts than stuff that is 3 clicks from the front page. Then Feedback loops can make life go horribly wrong: if you use popularity to decide what goes ont he 2-clicks then you’ve set upa feedback loop that will enver let that page change.

Design Docs

Maybe this is something peolpe bleieve before they come to the industry, that you can write a design doc in advance. Maybe you can, in advane, for some games, but mostly not. It makes it much harder for you to throw stuff away.

Bu we did kind of. I was passionaee about “collating” all the time, showing “this is what we currently think we’re making / aiming for”, it was a periodic re-summarising of what was going on. It was particularly useful for when new people joined the company.

[ADAM: that classic problem of wikis that so many games industry companies conveniently ignore: you MUST spend a LARGE amount of time DEVOTED to “re-precis’ing” regularly. Again, this is a common “best practice” at a lot of places, but sounds like something that the MM guys independently figured out on their own was a good thing to do, and experimneted with how best to do it]

We had boss battles at one point.

Aside: we had a scripting system that I had coded up, built around LUA. And then we thought: actually we’re going to create our own scripting system that doesn’t use Lua, that’s proprietary, and we’re goign to re-invent the wheel. And it flies in the face of best practice, BUT … in our case it was about serialization and saving levels. And we needed to save the entire level state. I want to be able to take a snapshot of the running game and patch the running virtual machine onto the serialized savegame format: i.e. we would guarantee ourselves instantaneous backwards compatibility at hte scripting level, so we could iterate effeectively all the time. So … it was actually worth going into the nightmare of making our own VM from scratch.

We had this idea there would be a whole family of characters, and each artist had different iews of what we wanted, so each artist madr their own custom family. We did agree up front (our art director lead this) that the silhouettes would be essential: if the avatars can dress up in many differnet ways, we needed to still have instant visual recognition when you saw something in a screenshot, and the silhouette would buy us that.

Although we argued and had different things, when we finally found the one we wanted, we collapsed the oligarchy down to having just one person own it as his baby. From then until ship, we had just one person do all the animations, everything, and that gave us a great consistency that we think really shows through.

scripting

We used to have lots of complicated levers and physics based stuff, and you would hope you got the weight correct to activate it etc. It was frustrating, so the level designers got “switches” added in that would simply work. Once we got that in, overnight everything got much easier less painful in the level design.

We want to make LBP something that enables people to make games. The super cool thing about switches that came from the creative side of the office that had a big effect on the play side of the office because the quality and fun of the game went through the roof.

[Showed game of life level]. That is amazing, we thought it wasn’t practically possible – done purely user-created.
[showed the calculator level. If you haven’t seen these, what have you been doing the past year? :P . Anway, c.f. YouTube, where huge levels are just physical creations of logic gates that make up a single computer]

Q: did you anticipate that people would do shit this crazy?

We saw the power of switched but never expected something like that. We secretly hoped that people would embrace it, but seeing this made us think wow ther’s some seriously fucked-up people out there, that’s real OCD right there. We were happy when we saw it was possible to make Tetris within the game, techincally speaking.

We gave it to friends and family, and Sony staff, all professional game devleopers, and the levels were terrible. Shockingly poor. I had a crisis of confidence then and there, and ever after our expectations weren’t huge. It was only when we went to public beta that we saw high-quality levels, and that happened within 24 hours. So, we didn’t expect this level of amazingly complex creativity, not this much.

summary

writers / game designers block. But once you start to try and implement stuff against it, you find that by the act of exploring it, it starts to unblock, and you find new ways, and if you’re not afraid of throwing away and starting again, then you can unblock and it works.

Q: I asked this in 2007: do you think this is goign to change now that the world knows about you? More pressure? Your asnwer then was that “thigns probably won’t change much”. Did the pressure come?

Announcing at GDC 07 did add a little bit of pressure, but it had a huge beneficial efefct in independent validation of the team; we were never entirely sure that people would “get it”, would like it the way we hoped they would, but we did after GDC. It also helped the hiring hugely.

But it didn’t really change the way we worked. We kind of forget that the outside world is even there.

Q: how many people do you have now?

32. That’s a nice team size that I like.

Q: what was the design process for the community parts and the share parts?

That’s the least finsihed, least complete part of the game. The process was very diffifcult because you cannot find an example audience to test it on until very late. Even with thosuands of beta testers, it was very different from how things felt when you finally got 2 million people out there in the community.

Q: Youve been supporting the product a lot after release. How do you manage that from a creative standpoint, within the team?

We’ve got ltos more that we want to put in, to do with it. Many many more ideas for LBP, so no problem there.

The codebase is tiny, very small, so it’s still easy for us to add new stuff, complete new features. A recent not-yet-released one took just 2 days to make the initial working version, direct inside the real game. Looked ugly as hell, but it was incredibly playable and fun as well, straight away.

We think we’re only about halfway through LBP even now.

Q: if you’re making wild ccode-breaking changes to the physics etc with all these branches?

We worked especially hard to always have backwards compatiblity. We did sometimes break peoples levels internally. The physics wasnt finalized until last few months before ship.

The game is deterministic, so one thing we’re investing in right now is a lot more automated testing. e.g. automated playthgouths of community created levels and alerting us if the outputs have changed with a new version. Then we can run against a thousand community levels and see straight off if we’ve added a regression bug accidentally.

[ADAM: yay for AT done *properly*! I got seriously fed up a couple of years ago with how many studios, large and small, whose senior tech people – right up to the CTO’s – didn’t understand the core of great AT for games. It’s great to see MM going ahead with it; hopefully that will inspire / educate more people to follow suit]

Q: Is that going to become an albatross?

Yes, but I think it’s one that very much we need to have.