CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 2
Concept Document

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.

Document Format

The format of this document was inspired by the Concept Document for the iPad game Project Aurora (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.

Title Page

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.

Big Picture

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.

Design Goals

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 Project Aurora 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.

Game Mechanics

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 incredibly important.

Once again, the Project Aurora 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.

Competition (New)

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 for.

Other Details

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 Project Aurora 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.

Presentation Style

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 writing guidelines 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 bullet points. 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 the original Project Aurora 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

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.

Brutus Break

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

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 before submission.

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.