Here are my notes for the GDC Session ‘Winging It’ – Ups, Downs, Mistakes, Successes in the Making of LITTLEBIGPLANET. It was a general postmortem on the development process of LittleBigPlanet, with a focus on specific mistakes they made. The session itself was also winging it a bit, it was presented via a custom Mac app that they apparently wrote on the plane ride over. Throughout, they showed various videos and early screenshots of LittleBigPlanet, on a weird zooming grid space. It was presented by Alex Evans and Mark Healey of Media Molecule. These notes are categorized by topic instead of chronologically, because the talk changed topics fairly often.

Development Process

• They had to deliver a set of monthly milestones for Sony. Milestone were initially delivered in the form of videotaped studio walkthroughs with content shown. Milestone requirements were generally worked out the prior month, so iteration time was fairly short
• Spent 3 months working on a “beanstalk” level, that was beautiful but never really worked because the vertical orientation of the level lead to severe gameplay issues. Eventually got painfully cut.
• The Tech Director spent a lot of time working on a “ribbon” 3d play space, where it was linear gameplay but presented as full 3d. This lead to complication in the code base without providing benefit to designers. Eventually was entirely excised from code base.
• They kept an actively maintained Design Doc that was used as a teaching and summary tool, but was not at all considered final. It was more a “snapshot” of the current thinking about the design of the game.
• Tried using Lua for their scripting language, but ended up using a proprietary one becuase they couldn’t serialize the state of the game satisfactorily using Lua. They could load old versions of saved games on new versions of the code, which was complicated but deemed worth it.
• In general, they worked on one branch of the game, but it worked because they had a small, highly competent team. They put a prime focus on backward compatibility with all of their code changes. They don’t really have a specific strategy for scaling up, working on that now.
• Features such as the look of Sackboy came about originally as a fight between various artists with lots of ideas. Then, they synthesized the best concepts for each of the designs into one, and then the chief character artist owned Sackboy from then on.
• Original design was for Sackboy to always be directly facing the camera, to simplify the physics interactions. However, the artists deemed this unacceptable, and eventually one of them coded up a prototype to prove the system would work with side-view movement as well. It mostly worked so coders fully implemented that solution.

Editing Tools

• Initial version of editor tools was entirely physical and exactly the same as playing the game. This was one of their strongest initial principals. Moving away from entirely physical effort took a lot of prodding, and eventually it happened when part of the team coded up a prototype to try and convince the rest of the team, which eventually worked.
• Once they moved to a more abstract editor, they had  a variety of UI problems, especially involving placing and scaling objects.  They tried to optimize button count and text, but the problem was actually the basic metaphor used by the editing tools.
• The final editor design ended up being an extension of the only fun part of editing before, placing stickers. This lead to the integration of very complicated CSG tech for allowing arbitrary material shapes, but this was deemed to be worth it despite the risk.
• At point in production, all editing of shipped gameplay started taking place using entirely the console editor. This forced the designers to never cheat, so lead to improvements to console editor as well as entirely consistent, physical gameplay. Players knew they could do exactly what the designers did

Community Tools

• Original design for community tools (search, etc) were very much using the Web metaphor, and used a lot of images and text. This had problems with display and interface.
• Shipped community tools shifted dramatically the opposite direction towards ease of use and simplicity. They felt they probably shifted too far, and worked post launch to bring back some of the missing functionality.
• Discovered that anything more than 2 clicks from the front page had a dramatic falloff in participation. This lead to a positive feedback loop where the highest played levels STAYED the highest played levels, and new content had a hard time breaking through.
• The quality of content during the internal Alpha was lower then they were hoping. Content quality during the semi-open Beta was significantly better then they expected. Moral is that you can’t rush into decisions about community, sometimes it takes a while for things to develop.
• During Q&A I stammered through a question about the priority of Share compared to Play and Create. They admitted that it didn’t get nearly the attention as the other two, because Create was operational so late, and they didn’t ever come up with a method of testing Share in any meaningful way other than just doing the betas. No way to do it without just trying.

I enjoyed this talk, and a good bit more than some other people I talked to. It was fairly unstructured and it did come off as a bit unprepared, but I thought the content was clearly worth it. I found the details about their development process and various mistakes very useful. It was definitely worth my time, especially as someone who’s interested in UGC.