Assignment 02 - Game Documentation
- Marks: 11
- Weighting: 11%
- Due: 5:00 pm, Friday 19th January, 2018
The goal for this assignment is to work as a team to present a clear, concise description of the game you plan to build. The documentation you submit should demonstrate that your team has considered the process of implementing the game carefully and objectively. With only four weeks to prototype and build a finished game, careful planning and estimation of what is achievable will be crucial.
Only one team member must:
- Create a new project on GitLab. Give it a meaningful name, because this will be the main repo for the game that your group is going to develop for this paper.
- Set the project privacy level to "Private", but add other team members as project members with "Developer" or "Master" access privileges.
- Give Lech and Nick read access to the repository, with "Reporter" access level.
At this point, any team member can:
- Clone the project to get a local copy of the repository with ability to pull and push to the central repository on GitLab. You shouldn't need to fork the main repository, just clone the main one created by your team-mate.
- Contribute to the "Wiki" page associated with this project (click on the "Wiki" link on the right-hands side of the menu on your project page).
This is a team assignment. Your mark will be the team mark, so you all have a vested interest in ensuring these documents are as good as possible.
Turn the wiki page of your Gitlab project into a Game Design Document (GDD). It's probably easiest for me to read when it's in form of a single page broken into different sections. However, if you deem it necessary to break it into multiple wiki pages, that's fine too (as long as it's obvious what I need to read). It might be a good idea for different group members to work independently using different document/pages that address different aspects of your GDD, and then for one of you to put up/combine everything onto the project's wiki just before the submission. The document is to be informal, and humour is appreciated, but keep in mind that these GDDs are going to go up on the course website along with your games at the end of the year.
Rather than providing an exact specification for what needs to be in your documentation, below is a list of the things I will be looking for. Feel free to format / present this as you see fit.
Aim to cover all of the points in the list below:
- Game name – a good name will excite people’s imaginations, a bad one may turn them off before they read further.
- Team name
- Who is on your team?
- What roles they will play?
- Core concept / vision - One sentence, sum it all up. THIS IS THE MOST IMPORTANT THING YOU WILL WRITE ABOUT YOUR GAME - MAKE IT GOOD.
- Theme (see The Art of Game Design for more details - don’t forget there’s a Lab copy).
- Game overview – expand on the core concept and provide maybe 1-2 paragraphs describing the game at a high level.
- What is fun about it?
- What is unique about this game?
- Non goals
- Feature list
- Sample users
- Demographic / target audience
- Planning – what questions need answered? Who will tackle what, and in what order?
- Planning – map out 3 week production schedule
- Control scheme
- Game Mechanics
- Describe basic game logic
- How will it be balanced?
- Control scheme
- Tech overview
- Sprites, animation, level / world rendering
- Path finding
- Loading / saving (levels, game state etc)
- Anything unusual / pivotal in terms of technology used
- Content overview – provide detail of how many, and what type things will be
- Power ups
- Models / sprites
- Sound / music
- Anything else appropriate in terms of content required to produce the game
- Screen layout
- Screen flow
- Concept art
- Character art
- Aesthetic demonstration (‘actual’ game art)
For those of you who insist on knowing how marks will be allocated, here is an approximate guide:
- You’ve handed in something with your names on it which vaguely resembles a game and you suggest you might work on it over the next 4 weeks. (5 marks total)
- There’s the essence of a good game here. I can see what sort of game it will be. It seems achievable in 4 weeks and you have a clear plan heading into the prototyping week. (8 marks total)
- The core game is clearly described. All aspects of the game design have been covered. Uncertain areas are clearly identified and risks discussed. There is a well laid out plan for prototyping and development that also describes where there is buffer in the time estimates should (when) things take longer than expected. The document is a pleasure to read. (11 marks total)
- Drawings and pictures of some kind will help to convey your team’s ideas. You don’t need to be an artist, simple sketches or even Google image searches at a pinch can work well.
- Make it interesting. I should look forward to reading the entire document, not dread it. Think of this assignment as a game in itself, with your marker as the player. Get them interested, keep them hooked.
- Be wary of too much detail. Show that you have thought about the problem, understand it and have a plan. Be clear and concise.
- Don’t be vague. Don’t say there will be three different worlds to play on, say there will be an ice planet, an asteroid and a jungle world. Identify what makes playing each world unique (slippery surfaces, low gravity, hidden snakes). Vagueness implies you haven’t thought things through enough. If something is not decided yet, say so, or make an initial guess and highlight that it is subject to change.
- Different team members will probably end up working on different parts of the document. Make sure that each part gets more than one set of eyes on it. Incorporate feedback and iteration the same way we would for the coding of the game. This will keep things consistent, help catch omissions and raise the quality of your submission.
Submissions must be made by 5:00 pm, Friday 19th January, 2018. Late submissions will not be marked.
To submit your assignment:
You will be submitting the assignment via GitLab.
Only one team member needs:
- To submit the assignment, send an e-mail to firstname.lastname@example.org with the Subject: "COSC360 <team name> Assignment 2 submission", and the link to the wiki on GitLab pasted in the body. It's ok if you decided to change the team name from the one given, as long as I can figure out from your GDD which team you are (remember, should list all the people and roles in the document). This e-mail constitutes your submission and it must be sent before 5pm, Friday 19th January, 2018. Late submissions will not be marked. Don't forget to give Lech and Nick read access to the repository, with "Reporter" access level.
- Any extras that can't be incorporated into the wiki page can be submitted as attachments of the submission e-mail. Please do not take this as an excuse to not make an effort to put as much as possible onto the wiki.
GDDs from 2017 (available only when viewing the games from the campus network)
Art of Game Design
- Pretty much the whole book is interesting, but particularly the chapters on theme and documentation
Joel on Software