Hello Games: design docs are "insane"

By Oli Welsh Published 2 October, 2010

"It's like writing a recipe and not cooking."

Sean Murray of Joe Danger indie studio Hello Games has told a Eurogamer Expo audience that writing design documents for games is "an insane idea".

"You can't have design documents," Murray said. "Writing what a game is going to be is just an insane idea to me. It's like sitting down to write a recipe and never actually cooking something."

Murray reckons Hello Games' loose approach to game design - detailed in our interview today - was used to make the classic Japanese games the Hello Games team idolises.

"I don't think you could design Street Fighter II on paper. You wouldn't know if it was fun or not. Everything I've read about those developers is that everything was itereative, everything was 'cooked'."

But Murray thinks it wouldn't have been possible to make Joe Danger in this way if the four-man indie had signed to a publisher.

"We had the benefit of not having a publisher, we had time to develop things, we weren't driven by milestones.

"We stole ideas [from classic games]... and we had the freedom to do that. That was a huge part of our process. When you look at games in the regular industry, you wish that those developers had that freedom."

It's not that the Hello Games team doesn't have outsiders making demands of it, however. Murray and his colleagues are bossed around by their fans instead, he said.

"We don't have a publisher, we have gamers. And gamers tell us what they want. And they want Joe to be a monkey."

Picture of Oli.

About Oli Welsh

Oli is Eurogamer's acting deputy editor and reviews editor and likes to take things one word at a time. He is among the best dressed people in South London.

Read more articles from Oli by visiting the Oli Welsh archive page.

You may also like...

Comments (23) Latest comment 2 years ago

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

  • Feanor #1 2 years ago

    That sounds clever to me, not insane. :)

  • T4RG4 #2 2 years ago

    With a handful of people on small games perhaps. But in the real world? Hmm.

    Relying solely on design docs achieves little but if anything it at least provides the designers with direction.
    Edited by T4RG4 at 02/10/10 @ 16:20

  • thubie #3 2 years ago

    Sounds a lot like my former college course i took.
    Communication and multimedia design.
    You had to almost had everything on paper and for the most part got graded for the paper instead of the actual product.

  • TheWretched #4 2 years ago

    I don't know why you get downrated, but I had a similar project at Uni last semester... but luckily out grades where more the endproduct, which had to adhere to the documentation, though.

  • benfresh76 #5 2 years ago

    It may work for a micro Studio like Hello games, but it sounds a bit naive to me. I've worked at some high profile development studios that adhere to an 'organic' approach to game design with no planning, preproduction or documentation...It's a nightmare (oh, the stories I could tell were it not for NDA's!). You need a unified 'vision' and at least a 'loose' blueprint of what you are making (or at least what you are trying to make) before you can start iterating and thinking outside the box...I wouldn't suggest for an instant that what is on paper will necessarily translate into a fun and successful product, but it's undoubtedly the best start to that iterative process.

  • the_mtfr #6 2 years ago

    Yes yes, I can see how each of the Fallout games could have profited from the lack of a design doc.

  • dewington #7 2 years ago

    As a general statement, that's a daft thing to say - to dismiss design documents entirely is insane. It depends on the kind of game and the size of the team. I've worked on a number of games which have had varying development processes, despite all the projects being similar, and from my experience things are more problematic at the hands of an "organic" design process. Design docs are never (or at least very rarely) concrete, but if you don't use them with a big team then it becomes much harder to get everybody on the same page. It's also better from a planning point of view if you have something written down - it makes it easier to break down what needs to be done. I suppose all companies work differently, though.

    That analogy seems a bit broken, too. Surely you end up cooking something, even if it doesn't follow the recipe to the letter and ends up a disgusting mess (or just burns and ends up being thrown in the bin).

  • fiery_jackass #8 2 years ago

    Edited by fiery_jackass at 02/10/10 @ 22:34

  • fiery_jackass #9 2 years ago

    Edited by fiery_jackass at 02/10/10 @ 22:04

  • Golgo #10 2 years ago

    Fuck, you're well 'ard you are...I'm off...

  • Freek #11 2 years ago

    You can have a design doc to outline the project and be creative and itterative. Ask Irrational, for example, They did it on Bioshock and now again on Bioshock Infinity.

    What's insane is thinking there is only way of doing things; your way.
    Edited by Freek at 02/10/10 @ 23:49

  • Seth. #12 2 years ago

    Isn't this similar to the prototyping vs analysis question in software enigineering/project management? Aside from the size of the development team, games that aim to achieve a certain flow to the action/gameplay/level design wouldn't need design docs as much in that many important decisions will be made during testing anyway. On the other hand rpgs/simulation/open world games can't be made without planning cause of how much stuff needs to be combined without the game ending up broken. Street fighter is probably an example of the former category.

  • ShiroBen #13 2 years ago

    It seems insane to me NOT to have design documents. 'Just making it up as you go along' can only work for the simplest of projects. If this attitude is common, no wonder so many games these days are a complete mess.

  • swisstony #14 2 years ago

    sean's right for small teams where everyone is on the same page, but you can achieve cohesion on larger teams with bullseyes, X's and other tools. The $100 exercise should exemplify. You decide what game features you spend your $100 on, with the large amounts going to the most important features. Think back to Black's 5 rules of guncraft. The dev team always understand what is important to focus on, even if the detail is iterated...the 5 rules of guncraft never changed. As Sean knows :)

  • darkmorgado #15 2 years ago

    I disagree with him. Design docs are important for providing direction and conveying vision. I can understand that they seem less relevant for, say, fighting games. But in RPGs or adventure games, I think they are important in helping to develop the world and overall aesthetic.
    Not only that, but they can be entertaining and interesting in their own right. The design docs for Planescape: Torment and the Fallout Bible being cases in point.
    If anything, I think more of them should be made publicly available when a game is published - perhaps on the game's website, or as part of a special edition extra, for example.

  • knocker #16 2 years ago

    Putting aside the SDLC, and it's various approaches for a second (one size does not fit all ...) it's refreshing to hear a developer talking like this. Passion, belief and all that stuff.

    It's a little like hearing an indie band (in the old school sense) who've just put out a stunning debut album. But you do wonder of they can keep that loose attitude when they get bigger. I do hope so.

  • abot #17 2 years ago

    Perhaps the word "Design Doc" needs to be removed from the lexicon of the early stages of a game's development and replaced with the term "proof of concept." I can understand what Sean Murray means when he says "It's like writing a recipe and not cooking." In the beginning of a project you are tying to answer the following questions:

    What are we building?
    Why are we building it?
    How are we going to build it?
    Who is going to build it?
    When well it be done?

    Early in development you're getting ideas conceptualized. You're figuring out the game mechanics. You're prototyping and creating vertical slices.

    Once you have discovered the fun then you can create a more solid design doc. You need a design doc before going into asset creation and before integrating the assets into the game engine so all members of the team are on the same page.


    Edited by abot at 03/10/10 @ 20:54

  • Spekingur #18 2 years ago

    If you have no clear direction of where you want to go with a program you are either going to end up with a pile of dung or pure genius. The first one happens more often than the latter one.
    That's what design docs are for. Even if the design doc is nothing more than a post-it note.

  • kangarootoo #19 2 years ago

    /sigh


    A small team making a relatively simple game probably don't need any documents.

    A large team, making a complex game, where development involves lots of people in communication in an attempt to all make the thing they agreed to make, NEEDS good documentation.


    The reason I am sighing is that the guys behind Joe Danger are clearly talented, and its great that they are doing well in this business and putting their stuff out there. But its kind of annoying (in general) when people come out with stuff along the lines of "this is the way you should do stuff", when it transpires that the basis of their talk is doing stuff in a way that best suits their own personal circumstances, and their advice would be wholly unsuitable for many other development situations.

    I don't mean to be overly negative about it. Clearly their way of doing stuff works for them, and it produces good results. I'm just not sure that there are any holy truths in what they do that can determine the way all games should be made.

  • chrisjm #20 2 years ago

    design docs are needed if only to please the people above that dont fully understand the product but have final sign off.

  • kangarootoo #21 2 years ago

    @Thought_Criminal

    I would say that an awful lot of design documents are terrible waffle filled things. All nice pictures and repetition, with none of the concise info that somebody might need to actually MAKE a game. So I'm cautious of any discussion about whether design docs are empirically good or bad, when the quality (and usefulness) of the docs is such an unknown.

    Docs are one of those areas (appraisals at work being another that springs to mind) where most often people don't see the value of them, because they have only experienced bad ones.

  • pinchofsalt #22 2 years ago

    "design docs are needed if only to please the people above that dont fully understand the product but have final sign off."

    Not really. Those sort of people wouldn't read it.

    To echo some of the people here, the only purpose of a design doc is to keep your team unified in one single vision. If you are a team of four building a game around a ultimately simple (yet fun) mechanic then obviously a design doc is pointless.

    The typical expectation of a design doc is a huge bible made up of hundreds of pages. Only bad designers who feel the need to justify their jobs will produce these. Good designers (of which this industry is severely lacking) need only produce high-level docs and work to allow their team to run with the idea giving them ownership over their little part of a huge project. These designers will give their team room to work with an idea.

    There are too many designers who think it is their job to order artists and coders around regardless of deadline and budgetary restraints. It is these people who cause the majority of crunch problems in this industry. The unreasonable requests of publishers only compound this, but then a decent producer would pull out the contract and tell them to piss off unless they have some more money to spend.

    Alternatively, some coders in the games industry like to just be told what to do and then go home, so a more comprehensive design doc is useful here to keep these people happy and productive as well. But again, hundreds of pages are not what is required but concise flowcharts, diagrams or an animated PPT presentation to get what is needed across as clearly as possible.

  • kangarootoo #23 2 years ago

    @pinchofsalt

    I agree with most of what you say, but not entirely with the bit that states "Good designers (of which this industry is severely lacking) need only produce high-level docs and work to allow their team to run with the idea giving them ownership over their little part of a huge project".

    The success of sort of approach depends on who the people are that are running with an idea. The result of letting people "run" could be a feature that is nothing like the design, doesn't fit well with the other features, and doesn't achieve the original aim.

    A lot of this is semantics. The "small team" you describe could include a designer, working with art and code to produce a specific item. Everyone has input during the creative phase, but the designer (if they are doing things right) is keeping in mind the original brief, ensuring it is met, and feeding back to the lead at timely intervals.

    I expect that you might agree with much of this, and that it really comes down to the definition of the loose term "running with an idea".

    I'm a big fan of group involvement. Good ideas can come from anywhere and should be listened to. But I also believe in professional boundaries, and somebody having to "make the call". I suppose in summary I mean that it is nice when everyone agrees, but that they don't HAVE to agree for progress to be made. So its good to let a feature team run with an idea in a controlled sense, but that doesn't neccessarily mean that the end result has to be accepted. Nobody wants to waste work (for practical and motivation reasons) so its important imo that the creative process is managed (not too closely, but closely enough).

    Blah blah blah, me on my soapbox, etc.