Due: Saturday, February 11th 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 creating
slides that will be used for a talk and the documentation.
Teams will submit the concept document on Saturday. However, on the Thursday and Friday
just before, you will be using that slide deck for a another pitch performance in ENGRC lab.
That pitch performance will not be graded. Rather, it will provide two speakers with a bit of
practice. Other team members will get practice later in the term.
The key element for success is to remember the audience of your document: a publisher.
These slides are supposed to capture a presentation that you might make to secure
funding. Everything should still be short and to the point without excessive text. Sketches
are okay (and welcome), but do not overload your potential publisher with details about
the game mechanics or software architecture. Game publishers don't care about the mechanics
or architecture. They just want to know if the game is fun and if it will sell.
Slide Deck/Doc Format
The format of this assignment 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. We have used this format for
several years now. One of the best examples is Over the Arctic Hills,
which we will use as a running example throughout these instructions.
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.
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.
Look at the design goals for Over the Arctic Hills.
They have three categories which they spread over three slides. They tell us their
goals for gameplay, the intended audience, and the emotions their game should inspire.
You do not need to have this exact breakdown, but it is a good starting point.
It helps to have illustrations with the design goals if possible. This is a place where
does well (and may go 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.
We do not want six slides on design goals. Give us at most two (brevity is an important skill).
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.
Again, look at how the image in Over the Arctic Hills highlights the emotional
impacts of the game.
Describe the core mechanics of the game. Remember that mechanics mean actions
(verbs) plus relevant interactions (environmental behavior). Challenges can be included, if desired.
Even more so than design goals, this is where a player mode diagram is
Once again, Over the Arctic Hills
does a stellar job here. It describes the core action mechanic and then provides several
interactions listed as Additional Mechanics. For each mechanic there is a simple
but clear illustration showing off the mechanics in practice.
is not as strong on this point. The gameplay mechanics are there, but they are merged
with the story. They should be clearly separated.
Do not default to bullets for this section. Over the Arctic Hills has no bullet
points because it is just one idea per slide. If you do use bullet points, remember to
follow the writing guidelines
and use them correctly.
While you did this in 3152, we want you to take a serious 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, we have provided you with a
Competitive Analysis Worksheet
to help you. This worksheet gives you an organized, logical way to compare your game to
other games out there. Seeing the qualities of the various games altogether, provides
an overview for the team that may be otherwise somewhat scattered.
Once that table is complete, put this information into the Concept Document. We do not
want you to just copy the worksheet directly. You should present the material well so
that the important issues pop out. 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?
This requirement was first instituted last year, so Over the Arctic Hills does
not have anything about competition. However, we do have some examples below showing
off this section. One of the most interesting is
Squeak & Swipe.
You will notice that the competition section is very terse but it conveys everything that
we need to know.
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. Drill down into your true vision of who your players will be and what they
are looking for.
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.
A better example of additional detail can be found in the concept document for
(originally Project Mainframe). This document ends with an outline of their
proposed level progression, giving us some idea of how the game will proceed. It is
short and to-the-point, which is what we are looking for.
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 understand, 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. Use bullets sparingly, bring them in as needed, and follow the other advice provided in ENGRC lab.
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.
Use PowerPoint, Keynote, or Google Slides to create the deck/doc. Do not overuse
flashy graphics that detract from the information; only show what you need. Pick a
background style that is complimentary, but does not overpower the team’s pitch. The
focus should be on the game inventors, not the slides.
We have quite a few good examples for you to look at. However, as is always the case 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.
Squeak & Swipe won "Most Innovative Game" in the mobile division during the
2016 showcase. This concept document is a very tight document with just the right amount
of information -- no more or no less. You should particularly pay attention to the
Aphelion was a multi-platform mobile game from Spring 2016. It also has a
Competition section, and shows you the best way to use a table in your document. We also
like the Level Progression section at the end.
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. It shows you exactly how to use illustrations in your presentation.
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).
Due: Saturday, February 11th at 11:59 pm
For this assignment, the team should submit two items:
To CMS, upload a PDF file called conceptdocument.pdf
To Traci’s email, send the actual slides (not in PDF).
We ask that the submission to CMS be a PDF so that we can annotate it in order to return
it to you with feedback for possible revision. Traci's version of the slides will allow
her to give you better guidance for future revisions.
As the prospect of revision implies, this is not the final draft of your concept document.
You will have later opportunities to revise. However, you should take this
assignment very seriously, as we will use this assignment to evaluate the suitability of
the team’s game (e.g. is it feasible, is it suitably difficult, etc.). If the team’s proposed game
idea is rejected for whatever reason, then the team must address all the our concerns in a
revised concept document within one week. If the game proposal in the 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.