The High Concept Design Document

• Requirements
• Estimated time
• Dificulty

Objective

(Almost) nobody likes documenting “stuff”. However, (sometimes, in some contexts) there are reasons why you should document your work, in some areas. Have no doubt about this: documentation, although not mandatory, brings many advantages in game design.

One reason why documents are made is to communicate. During the entire game design process (and development, and testing, etc.), it will be necessary for a given team to communicate the design to others (for instance, the level designers will need to communicate with the art team). A document may also be used to give a brief description to a producer of a given game idea.

Personally, I use documents as a way to turn vague ideas into a precise specification. During game design, it is normal to have a lot of options about how to make a game, with different ways of making something, and multiple elements that may be included. Different documents work as milestones representing the decisions that were made during the design process.

Also, the contents of a document may be used to test your idea (by presenting it to some panel of friends, for instance, or using other method), allowing it to evolve quickly. This way, different types of document and different versions of one type work as a history of the process.

In this tutorial, I will describe one type of document: the “High Concept”, using its format to take the game idea generated in the previous tutorial one step forward. I will also introduce a method to evaluate a game idea on an early stage, allowing filtering good ideas, discarding bad ones, or putting a good idea which is not being well thought of, back on the right tracks.

By the end of this tutorial, you’ll see how our initial idea, generated in 5 minutes, is growing into a more serious possibility for a game that players (some of them, at least) are willing to invest time (if not money) on.

Keywords

Game Design, Game Document, High Concept, Evaluating Ideas, Communicating Ideas, Decision Making, Hooks.

The High Concept

Different authors, like Ernest Adams and Andrew Rollings (link) state that the High Concept’s main use is to work as a résumé, introducing the key ideas for the game in a few, fast-readable pages, and allowing you to be heard by a producer, or publishing executive. However, Ernest also points out that the High Concept may be used to keep a record of the ideas you have (link).

The high concept document should be 2 to 4 pages long, and take no more than 10 minutes to read. Even if you are not writing this document to introduce your idea to any producer, it is important that you do not write more than 4 pages, intentionally focusing on the main ideas and letting the game definition vague, ready for posterior changes. The high concept should also not have a title page, and should start with the game’s title and the author’s name, immediately followed by the text.

Next, I’ll list the different sections of the document, with a brief explanation of what they should contain:

High Concept Statement: Placed after the title and your name, this is a two lines statement of the main idea of your game. It should be easily understandable and work as a way to get the reader’s attention and interest. There are cases where this may not be executable (describe Pacman in two lines in an interesting manner), but it is usually feasible.

Features: Occupying the rest of the first page, this is a bulleted list of key features, with no more than 2 or 3 sentences for each idea. In this list, you should describe the game’s look and feel, allowing the reader to build a mental image of your game, and understand what it would be like to play (experience) your game. Usually about 10 items, all of them in the first page should do the trick. Give emphasis (bold) to the ones you think are most fun, innovative or important.

Overview: This is where you summarize the key commercial considerations about the game, including some (or all) of the following items:

• Player Motivation. A short statement indicating the player’s role and goal. This defines what type of player will play the game: one desiring to compete, solve puzzles, explore, or anything else.
• Genre. Indicates the genre of the game. If the game is a mix of genres, indicate that.
• License. If your game uses a licensed property (like a Batman game), you should indicate it here, describing it briefly, and saying its appeal. But let’s be honest… you probably don’t have money to buy the rights to a License.
• Target Customer. Describe who will buy the game. Describe age, sex, race, type of player and every other trait IF it is important. Also, indicate what other types of games they like to play.
• Competition. Indicate games on the market like the one you’re describing (if any), indicating why yours is better or at least different.
• Unique selling points. What really REALLY stands in your game, making it new, or better or amazing?
• Target hardware. Indicate what machine will it be played on, and if it needs any type of special hardware or accessories. Note: You may be using this document for a board game, or not be sure about what is your target platform. It’s ok, ignore this section.
• Design goals. Here, you define your aims for the game as an experience. Don’t be too minimalistic, like stating your game is meant to be “fun”: define more clearly how is “fun” supposed to be achieved (humor, tension and suspense, etc.). For each item, define briefly how the game will achieve the goal.

Further Details: In the last section (or sections), you may add any additional material you think the reader will enjoy, notes about the characters, artwork, music, plot, or anything else you think may interest the reader. Don’t be to exhaustive here, to not make the document too long. Personally, I think of this as the appendix of a book: it may be useful to include, but it is not necessary.

Before introducing my High Concept to “Downhill Royalty”, I must state that if you’re making this document for your eyes only, no harm is done if you don’t respect all the rules. However, if you’re making this to send to some publisher, you should try to “stick to the plan”. Usually, when Ernest Adams says something about anything on game design, you should be very certain about your beliefs to do otherwise.

Downhill Royalty’s High Concept

 

 

As you can see, the initial idea grew a little while writing the High Concept. Now, I have a primary idea of how the game will be played, how will it look, and some of its characteristics which will (hopefully) appeal to the players.

An important thing to keep in mind is that the ideas are mutable. We can, at any time (preferably as soon as possible), discard ideas that, no matter how good they are, are prejudicial to the game as a whole. But for now, I have a good first “image” of my game.

Hook Evaluation

So, now we have a game in our mind and in our paper. Maybe it has the potential to become the future “best thing that ever happened to gaming anywhere, anytime”. Maybe not. For now, you should have a way to evaluate it, to find some “weaker traits” to improve or discard. It’s way easier to change a game on the earlier stages, especially when there is no “game”, but only an idea.

One way to evaluate your ideas is to discuss them with someone. Try to get a friend or relative who you believe will give you an honest opinion (not fearing to hurt your feelings with critics), who knows something about game design, or at least who likes playing games. It’s not an ideal “study group”, but will eventually give you some new ideas.

Other way to evaluate your idea is to create yourself some distance with it. Just let your high concept in your drawer or your hard disk for a few months, forget about it, and then read it again. I find this useful, for I tend to be critic with my later ideas, and usually tend to suffer from the syndrome “I would do that different, if I was to do it now”, so this is a cool way to do that.

This two evaluation methods, which I usually use, and sometimes prove useful have several problems. One of them is that they are dependent on “human evaluation”, which may be biased, especially when relying only on a small number of “test subjects” (potentially only yourself). They also have the problem of lacking a real “method”. They’re pretty much a qualitative evaluation. I will try to introduce a more reliable way (especially if we consider where I got it from) to evaluate ideas.

The real evaluation method I want to introduce here is related with hooks, and may be found in one of the greatest books I’ve read about game design: “On Game Design”, by David Perry (link). This gigantic book/toolbox is a must have (emphasis on MUST) for any game designer/game design curious/game designer wannabe. I’ve read it all, and keep him close at all times, for it talks about EVERYTHING there is to talk. If you think I’m exaggerating, just check it out. It’s “game design’s Google” on paper.

Perry defines hooks as something that makes your game unique that probably was not seen before anywhere, making it recognizable instantly, making it noticeable by players, press and retailers.

A hook has the benefit of being something to focus while trying to get a publisher for your game, something to test with your audience, something to focus your advertising, something for you (and your team) to base your decision upon (test if something is helping you deliver your hook), something the press can talk about, and something gamers will buy to experience for the first time.

Perry also introduces a 40-questions’ hook evaluator, which I will now use to evaluate Downhill Royalty. You should answer each question with “No”, “Yes”, or “Heck Yeah!”. You get 1 point for each “Yes” and 2 points for each “Heck Yeah!”. The author states that if you score more than thirty points, you’re onto something good.

I will now copy here the 40 questions, applying them to my game, and answering them. Notice that I do not have any permission to use them here, so you really should buy the book. It would be cool to state in court that my plagiarism increased the book’s sales, to try to escape a big fee, after being sued by the author.

 

1. Does the target audience already respect the developer of this game? No.
2. Does any aspect of this game design brings back fond memories or nostalgia for the target audience? Yes.
3. Are the graphics generally likely to be better than rival/competitive products? No.
4. Are your artists going to be able to make this subject matter look breathtaking? No.
5. Based on the story scenes, do you expect people to want to watch every minute of the cinematics? (Get a point if there are no cinematics in your game.) 1 free point.
6. Will the game feel new/original/fresh? Yes.
7. Will it be easier to play (easier to get into by design) than competitive games? Yes.
8. Is the functionality/depth/range of features planned for the game more impressive when compared to other games in the same genre? Yes.
9. Do you think a player would be perceived as “cool” by his friends if he introduced them to this game? Yes.
10. Would most people (not just hardcore gamers) be able to play your game and get into the most fun parts relatively quickly? Heck Yeah!
11. Does the game have a cool-sounding, easy to remember/easy to say/easy to spell name that suggests or reveals what the game is about? No.
12. Is there an exciting feature that can be saved for the Limited Edition version? No.
13. Does the game potentially have any collectable value? (Is it part of a series, for example?) No.
14. Can the owner play the game with his friends sitting on the sofa next to him? Yes.
15. Can the owner play the game with his friends through the Internet? No.
16. If playing through the Internet, can the player chat with his friends easily while playing? No.
17. Can the player share or trade his success (his spoils of war) with his friends? Yes.
18. Can the game be customized or personalized? No.
19. Is the game going to be presented by a respected game designer/programmer or producer? No.
20. Will the game star a really well-known celebrity character, actor, or actress? No.
21. Will the soundtrack be crafted by a very (globally) popular or famous composer or band? No.
22. Is the story written by a famous or respected writer? No.
23. Is the focus on a subject matter that the target audience is really excited about these days? (One that hasn’t already been done many times before?) Yes.
24. Will people be amazed by the visual effects? No.
25. Does the global gaming audience really love this game genre? Yes.
26. Is there any controversy regarding this game that the target audience will hear about? No.
27. Is there a way to make the price lower than that of your direct competitors? No.
28. Do you have any clever plans for marketing the game? Yes.
29. Will the game engine have a way to avoid long boring periods, long load times, or other elements that try a gamer’s patience? No.
30. Are you sure people won’t think this game is weird or strange? Yes.
31. Will gamers playing this game laugh out loud at any time while playing? Heck Yeah!
32. Would it be possible to reveal the unique hook in this game in a television commercial of 30 seconds? Yes.
33. Can you play this game without ever reading a manual (by design)? Heck Yeah.
34. Will you have movie-quality sound effects/ambiance/speech in the game? No.
35. Will the game offer immediate replayability? Heck Yeah!
36. If a player gets stuck, will the game detect this and help him out of this problem? No.
37. Will the game have interesting “very memorable moments” (high points), as opposed to repetitive gameplay? No.
38. Will the story have an exciting start? No.
39. Will the story have a surprising ending that will compel people to talk about it? No.
40. Will the game have a fun and interesting learn-as-you-play in-game tutorial? Yes.

 

With a score of 22, the idea is far from perfect (but we already knew that). The good thing about these questions is that they make you think about aspects that you haven’t thought before. I know some of them seem to have no utility whatsoever, but as I said about Ernest Adams before: you should be very sure about your idea to disagree with David Perry on a subject regarding game design (link).

Now, I advise you to check your negative answers and try to find out a way or two to turn them into a “Yes”. Some of them will be impossible, but this exercise will surely give you new ideas to include in your design.

Note that some of my positive answers are easy to justify, and just by reading my High Concept document you can identify how I will “probably” implement them. On the other hand, some of them live only in my head. No problem here, the High Concept is not supposed to have everything specified: there’s a lot more documentation in the future to do that.

By now, I should write a new version of the High Concept, and submit it again to the same questionnaire. And again and again, until it satisfies “freely” (it doesn’t need to get 30 points to be good) the requirements. For this tutorial, I will not include more than one High Concept (it is not the tutorial’s objective), but be sure that based on my answers and my posterior analysis, changes were made to my idea, and will be included in the next tutorials. Making a new version or only keeping your answers somewhere and the ideas you had by trying to turn “No” into “Yes” is up to you. Except if you’re making a High Concept to send to some producer. In that case, you should not be happy with the first version.

Before ending this section, I would like to say that this method could be applied earlier on the design. For instance, after getting an initial idea, it will not hurt to test it, even before writing the High Concept. I only chose to do it now because my initial idea seemed too “initial” for my taste. Also, this method may be used not only to improve an idea, but as a choice helper: imagine you have 4 ideas which you consider “good”. Run this test on all of them, and go with the one which scores higher.

Conclusion

This tutorial was the first one about documenting stuff. On it, I taught you how to write a High concept document, and why this is an important deal while designing a game: it is the first document you produce to present your idea to producers. More than that, while writing this document, you will find yourself thinking in aspects of your game you didn’t thought before.

I also introduced David Perry’s 40-questions’ test, used to evaluate a game idea. This test is useful to identify weaknesses in the early stages of design, allowing you to improve your idea. A cycle composed of document-test-improvement-document-test… will allow you to create a high concept that you may use to describe your idea to the game.

By the end of this tutorial, we’ve seen how an initial idea was taken one step forward into a game that players will want to play.