CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 2
Concept Document

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


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

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.

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


Game Mechanics

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

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.

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

]

Competition

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.


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.

A better example of additional detail can be found in the concept document for Aphelion (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.


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

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.


Examples

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

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

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 Competition section.

Aphelion

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

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

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


Submission

Due: Saturday, February 11th at 11:59 pm

For this assignment, the team should submit two items:

  1. To CMS, upload a PDF file called conceptdocument.pdf
  2. 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.