Making bigger bets with smaller stakes.

Keeping Lionhead Innovative.

Adam Jethro Langridge


How do you make something big and innovative?

That's a particularly interesting question in the computer games industry. It is easy to see its significance once you peruse your local Computer Game store. When I look around a game shop, I tend to look for something exciting and interesting that offers me something that I haven't experienced before. If I'm lucky I'll find something that hasn't existed before. For most people, especially those that don't play games (which is a lot), I think this may be the case too. They just don't know it yet - the amazing game that will interest them still hasn't been made.




For an entertainment medium that is still in relative infancy, computer games already make a lot of money and often have large teams working on a single title. This opens up the game developer to two opposing forces; On the one hand, there is a great deal of opportunity to innovate- to find new ways to entertain new people. On the other hand, a large financial commitment to any project means that mistakes can be costly. As a result, big budget titles display a tendency to be risk averse, which at its worst can mean the latest release you've been looking forward to turns out to be the same game you played last year, but bigger. However, there are a handful of developers that are the exception to the rule. They manage to make big games, with big imaginations. This article shares my insight on how just one of them does it - Lionhead.


Lionhead Studios has been making computer games for over 10 years. Founded by Peter Molyneux and a handpicked team of crack commandos in July 1997 Lionhead has grown from 15 people making Black & White to become a fully fledged Microsoft Game Studio with over 100 full time developers. On its way, Lionhead has made the Movies, Black & White 2 and of Course Fable 1 (as it is now known).


Lionhead's heritage goes back to Bullfrog Productions, which was itself responsible for some genre defining hits, most notably the birth of the 'God Game' in Populous.


During this time, Peter Molyneux and Lionhead have built a reputation for innovation and ambition in every title that has been released. Most recently in Fable II, some interesting innovations include mechanics called 'Ambient Orbs', the 'Breadcrumb Trail' and 'One Button Combat', each of which weren't previously seen in computer games, but managed to help Fable II shine. However, with every innovation is an element of risk. Some ideas simply don't work. If you're unlucky they end up in the finished product - making your game less fun and less successful. If you're really unlucky, commitment to a bad idea can wreck a title's development completely. I have heard stories of games that languish unfinished and unreleased because of a particularly unfortunate turn in its design - they just never recovered. Of course, these are an extreme case, but even bad ideas that don't wreck a game can still be costly if mishandled. Why is this? 


Size does matter.

Computer Game development teams have grown over the last 20 years from a lone bedroom programmer doing everything, to teams of more than 100 people. These new teams have dedicated people corresponding to many different disciplines. Broadly, teams are made up of Artists, Animators, Designers, Musicians, Programmers and Testers. Each of these disciplines has their own specialities. For example in the case of artists you will find people who focus on one specific element of computer game art such as characters, concepts, environments, textures, and more. This means that because a single game feature often involves a team of people to coordinate, working on the wrong idea wastes a lot of time. Due to the complexity of many modern games, these mistakes can introduce knock-ons to other areas.


The big question is how do you invest in big ideas, without taking equally big risks? Some ideas seem great on paper, but unless you've played them, you sometimes never know. But what if you try them out in the game and the idea fails? You've wasted all that time and work, and the deadline is that much closer now! I'm sure you've already guessed the answer to this question - and that is what Lionhead has a culture of doing - Prototyping.


Show - Don't Tell.

A prototype is usually a standalone piece of technology that is made with the sole purpose of proving (or disproving) an idea. This idea could be anything - some rendering technology to showcase an art style, a control scheme, some networking design, even the way you make something. The great thing about prototypes is that because they only care about one thing, they don't need to bother with everything else. This means that they can take less time and use less people to put together than a full implementation. If it fails, you've lost one or two peoples work (but really you've saved a lot more people from making the same mistake). If it succeeds - you've got a proven idea ready to put into your game and some experience of doing it already.




This all sounds great, but is it actually done? Prototyping is done by lots of people in lots of areas of Lionhead. Lionhead even has a small department dedicated to identifying risky opportunities and prototyping them - called the Research and Development team. Let's use a case study to demonstrate how Prototyping has helped Lionhead make innovative games. In this case, let's look at Fable II's One Button Combat system.


What button combat?

This feature was triggered by Peter Molyneux, who wondered if we could have cinematic action without the complications of most control schemes - in this case, just one button. The sentence that encapsulated the idea was something like "When you press this button, the hero does the coolest and most exciting thing that he can at the time." This could mean attacking, defending or leaping off of a wall!


Straight away this idea presented risk, because this was counter to previous conventions - one button blocked, another attacked. So much so that I don't remember anything else that worked in this way in a computer game before.


Three options were open to Fable II's development. The first was to put it in the game and see if it worked. This idea seemed very risky for two reasons; combat is one of Fable's cornerstones and couldn't afford to be broken. Also, no-one had any clue as to whether or not it was a good idea - unless you get your hands on it and play, you'll never know. The second option was to ignore it, losing that opportunity. The third option was a prototype. This meant the Fable II's main development could continue. If this paid off, it would be a nice extra. If it failed, then nothing would be lost to the game's development.


As speed was critical, we decided to make the prototype outside of Fable II's codebase, which was still under heavy development. The prototype was called FistiCuffs, and focussed on unarmed combat only - a street fight. It wasn't much to look at, it didn't have any textures, and the characters didn't have any fancy animation coding techniques that prevented their feet slipping. These things weren't important, what was critical to this idea was how it felt. As it turned out, the prototype proved to be successful in proving this idea. Happily, some more ideas came along from this prototype as well. The nice thing about having a working prototype of this nature is that for very little extra effort, you can try out other ideas too. No matter how silly they seem, if they have a reasonable chance of success, they are worth trying because they are so cheap to explore.


This example goes to show that with a sound prototype and good backing (in this case Peter), new ideas can find their way into big games, even as core mechanics.


What could this mean to you? Well, if you find yourself wanting to try out a wacky idea for a larger project, but you're scared of breaking everyone else's work. Perhaps you find yourself having trouble getting consensus on a feature. Don't be afraid to Prototype it first. If you decide to do so, remember the following:


·         Prototypes don't need to show everything- just focus on what you're trying to demonstrate.

·         Prototypes don't need to do everything properly. If you can show an idea in 2d, even if it's for a 3d project, then do that.

·         Prototypes do need to show what's important. Make sure you have a very clear idea of what you're trying to prove. If you can't say it in a single sentence, you probably don't know what it is. Try writing it down. For example, "This Prototype needs to show whether or not a single button control scheme can be fun and rewarding in a combat game."

·         Know your audience. Often, a prototype will be a tool to demonstrate an idea in order to get buy in from more people. Weigh up any things that are easy to do, but boost the message of the prototype, such as sound effects in a game play prototype.

·         Re-Use code and assets. Don't re-invent the wheel, if something already does what you need it to, use that and build on it. Keep your own useful code handy.

·         Let the work speak for itself. As a previous title mentioned, show, don't tell. Simply by trying this idea out, it should be pretty self-evident whether this idea is a 'goer'. If people aren't buying in to the idea after being shown, then it probably isn't that great an idea. Don't get upset, you've just saved yourself the pain of working on it in the larger project and finding this out too late!


Next time you're looking through the shelves at your local computer game shop, think what ideas and prototypes these games would have looked at or dismissed. Perhaps you’ll have ideas of what prototypes you would like to try to make these games better - you'll be on the way to making your own groundbreaking blockbuster (or little gem). Have fun.


Lionhead is currently searching out the brightest, most imaginative and nicest graduates that are around to become the games developers of the future. If you've a clever brain full of big ideas, are currently finishing your degree, and like programming- follow this link:

Comments (0)

Skip to main content