Due: Saturday, February 13th at 11:59 pm
For this assignment you should submit a concept document for your game. Our format
for this document will be slightly different than it was for CS/INFO 3152. In that class,
you submitted a traditional 2-3 page document. This time around you will be submitting
presentation slides (though you will not be giving the actual presentation). These slides
will contain bullet points succinctly describing what your game will be like.
As with the concept documents in CS/INFO 3152, the key thing to remember is the
audience of your document. The audience of this document is a publisher.
These slides are supposed to capture a presentation that you might make to secure
funding. You are not actually making the presentation; you are just submitting the
slides. But everything should still be short and to the point without a lot of
text. Sketches are okay (and welcome), but do not go into a lot of details about
the game mechanics or software architecture.
The format of this document was inspired by the Concept Document for the iPad game
(later retitled Alone in the Light). This project was proposed by a GDIAC alum
who has since gone on to become a successful designer. It is not a perfect document,
and we have made several improvements on the format. But we use it as a running example
in the instructions below.
The title page should have your project name (e.g. the working title for the game) as
well as your "studio name". Do not put the names of any of your team mates on this page;
Chelsea's name is on this document because she was a non-student (an alum actually)
recruiting students from the course to work on her project.
You should follow the structure used by the Project Aurora. List the platform,
genre, and release date. You do not need to give the language or development
tools (that is for the Architecture Specification).
The most important part of this slide is the high concept statement. You
should remember these from CS/INFO 3152. This is a short statement of the core vision
of your game. It is one or two sentences and should be player focused. That
means it should describe what the player can do, not what happens to the player.
As a great example of a high concept statement, consider this example from
Forgotten Sky (Spring 2008):
Eons after a forgotten catastrophe drove mankind to take refuge deep within the earth,
a young man has the audacity to dream of the sky. With nothing but a thin, swaying rope
preventing an untimely end, guide Caelum through the ruins of past shelters as he
ascends to the surface.
Note the structure above: one sentence to set the scene, and another describing what
the player can do in it.
On this slide (or slides) tell us what you are trying to achieve in this game. Who is
your audience, and how do you plan to reach them? It is not enough to tell us what your
audience is; you have to justify why your game will reach them. Otherwise you are just
going to tell us that you "plan to appeal to core and casual gamers alike".
Design goals are also where you tell us what types of feelings or emotions you expect
your player to experience. If you subscribe to the Earnest Adam's "wish fulfillment"
school of game design, now is the time to say what wish you are fulfilling.
Design goals are the one area in which the
concept document goes a bit overboard. After a single slide of design goals, it has
five slides on story accompanied by player mode diagrams. These story slides are
intended to support the claims about player emotion on the first slide, and do a
very good job doing it.
However, we do not want six slides on design goals. Give us at most two (and even just
one is okay). Make sure that the first has all of the important goals. The second, if
it exists at all, should have a single illustration showing how you expect these design
goals to be realized.
Here you describe the core mechanics of your game. Remember that mechanics mean actions
(verbs) plus relevant interactions (environmental behavior). You can include challenges
if you wish. Even more so than design goals, this is where a player mode diagram is
Once again, the
concept document goes a bit overboard on this. It has an exhaustive description of
all the major mechanics of the game, and then a separate slide (and player mode
diagram) for each mechanic. There is no need to go into this level of detail; that is
what the gameplay specification will show.
All we want is a few bullet points describing your core mechanics together with at least
one player mode diagram. The diagram should clear show off the relevant mechanics. If
you look at Project Aurora, you will note that the diagrams in the story section
actually show off mechanics. This is the style that you should use.
As Project Aurora is an iPad game you will notice that the players' hand is
figured prominently in many of the illustrations. This shows how the game corresponds
to touch events. If your team is making a game that requires custom gestures, you
should follow this cue to show action.
This is a brand new section this year, and it does not appear in any of the
examples below. Simply put, we want you to seriously look at
your market competition. What games are you most like, and what makes your game
uniquely appealing. In particular, we want you to identify some games that have similar
audiences to yours (so no AAA $30 mobile games), and answer the following questions.
- Why does your game share the same market/audience as this competitor?
- Why will your game appeal to people in this audience?
- What differentiates your game from this competitor?
- What price point should your game be, based on this competitor?
To design this section, the team should fill out, in whole, the
Competitive Analysis Worksheet/Table.
We are requiring this as it will help give you insight into your own game versus other
games that you may not have thought about in an organized, logical way. Seeing the
qualities of the games altogether, in a table, provides an overview for the team that
may be otherwise somewhat scattered.
Once that table is complete, pull from it the important bits for the Concept Document.
The elements that you need to highlight will pop out from the table. Are you too much like
Game XYZ? Who really *are* your players? Why do strategy games seem to appeal to players
in ABC demographic? How do we reach those players? Is any cost too much for this game?
Those larger-order flashpoints of information should be pulled from the table directly
into the Concept Document.
Side note: Your players cannot be "everyone." Think clearly about who, truly, is
the audience/purchaser of your game. Some people like war games; others won't touch them.
Some like "cute" games; some won't go near them. Some folks will pay for games; others
never will. Some want coins and treasure; others just want to level up. Some want visual
beauty in their games; others don't care about that at all. Some will be ok for kids; some
not. Drill down into your true vision of who your players will be and what they are looking
You should spend no more than one or two additional slides telling us anything else
that you might find useful. This can be a description of sample challenges, or a more
detail into the game story. In the
concept document, you will notice that it spends the last slide on aesthetic decisions.
This is not a bad idea if you wish to do this as well.
With that said, theses slides (starting with Explore the World) are actually
the weakest part of the Project Aurora concept document. They are dense and
full of text with no illustrations. This makes them much harder to skim than the
previous slides. You do not need to illustrate everything (your artist can breathe
a sigh of relief now), but keep everything short and concise.
As always, the concept document is not a treatise. It is a pitch document in order
to secure funding for your game. It should be easy to read, punchy, clear, and direct.
Notice how the example has short, but descriptive sentences. Bullet points are used
effectively to convey information so that we do not need a person presenting it to
understand what is going on.
If you are unsure about our requirements, we have included some
to help you with the documents in this course. This should make our expectations
clearer. While most of you have already satisfied the technical writing requirement,
we will still grade all of this assignments like an official technical writing
course. Take these style guidelines seriously.
Most of those guidelines are for a written document, not a presentation. The
most important thing to pay attention to is the guidelines for
You should never have a call for more than three levels of nested bullets. If
you do, your should rethink about how to split this information over several slides.
In addition, presentations should use a font size of at least 20 points. If you need
a smaller font, you have too too much information on the slide.
Because we are asking for slides, many of you will wish to use PowerPoint or Keynote.
That is perfectly fine. Just exercise restraint in your document. Do not add a lot of
flashy graphics that detract from the information; only show what you need. Pick a
background style that complements the document, but does not overpower it.
We have only used this format for two classes now, so that limits the number of examples
that we have to show you. Furthermore, even with its flaws, few of them are as good as
concept document. The contents of these samples documents is okay, but the presentation
could be a lot better. Furthermore, none of these include the new competition
section. As always in this class, use these examples for inspiration, but do not emulate them.
Over the Artic Hills won "Most Innovative Game" in the mobile division during the
2014 showcase. It is also the best of the 4152 concept documents that we have ever
received. It is clear, concise, and has excellent illustrations to emphasize its main
points. It also uses bullet points effectively, avoiding our main concerns.
A more recent game, Brutus Break was an iOS game from Spring 2015. While the game
itself suffered from feature bloat (some of which can be seen in this document), this is
a beautiful example of a concept document.
Beam was an extremely well-designed puzzle game that won "Most Polished Game" in
the mobile division during the 2014 showcase. This is very minimal concept document,
representing that absolute minimum that we will accept. The illustrations at the end
are good, but they unfortunately only show a minor gameplay feature (e.g. painters) and
not the primary gameplay (e.g. forming beams).
Apsis was the 2013 showcase winner in the advanced division, and has since gone
to win "Most Promising Game in Development" at Casual Connect 2014. The bullet points
could be a lot cleaner in this document, particularly in the design goals section.
However, the document is short and concise and gets the idea across.
Phantom Escape was an iOS platformer that used some innovative pinch-and-zoom
mechanics. This concept document document does an excellent job of describing what
the game is about. Again, the bullet points are not the best; they are cramped and
could make better use of vertical space.
Due: Saturday, February 13th at 11:59 pm
You should submit a PDF file called conceptdocument.pdf
containing all of the information above. We ask that the file be a PDF so that we can
annotate it in order to return it to you with feedback for possible revision. It is fine
if you create the document in a program like PowerPoint, but you should convert it to PDF
In addition, please submit the competitive analysis worksheet so that we (the instructors
and TAs) can see the overview in full. It will function like an Appendix.
As the prospect of revision implies, this is not the final draft of your concept document.
You will have later opportunities to revise your concept. However, you should take this
assignment very seriously, as we will use this assignment to evaluate the suitability of
your game (e.g. is it feasible, is it suitably difficult, etc.). If your proposed game
idea is rejected for whatever reason, then you must address all the our concerns in a
revised concept document within one week. If the game proposal in your revised concept
document is not acceptable, your group can no longer receive an A for your project grade.
With that said, this almost never happens in this class. We always try to provide extensive
comments on this assignment so that your group can be back on track by the revision.