Deliverables for PMU199
The marks for this course come from several sources. The most significant of these is the course project, which involves the development of a complete video game that has an impact on the player. However, this project mark is made up of several smaller components, such that the deliverables for the course are spread out evenly throughout the semester.
It is very important that you review the deliverable schedule from the course information sheet, and to mark the due dates on whatever calendar you use to schedule your work.
Deliverable Schedule
| Week | Deliverable | Description | Weight |
|---|---|---|---|
| 1 | Game Jam | One-day game hackathon event. | 5% |
| 2 | Game Brainstorming | Submitting ideas for potential games for the project. | 3% |
| 3 | Design Blog Creation | Create your game blog, add a first entry and add a link from the main course blog to your own. | 2% |
| 4 | Pitch Presentations | Within your groups, decide on the approach(es) your game will take to achieve both fun and impact. | 5% |
| 5 | Background Research | Look at other games and interactive media that achieve your goals, and determine how they will affect your design. | 5% |
| 6 | "Design Doc" Presentation | A detailed desciption of the imploementation of your game. | 5% |
| 7, 9, 11 | Mini Demos | A 5-minute update on development progress, including demos, wherever possible. | 5% each |
| 8 | Alpha Demo Presentation | A playable prototype of your game | 5% |
| 9 | Playtesting Report | A report describing the reactions of the general public to your game. | 10% |
| 10 | Beta Demo Presentation | The feature-complete version of the game. | 5% |
| 12 | Game Release | The fully complete game, ready for public consumption. | 15% |
| 3-12 | Design Blogs | A development journal, outlining your game's progress and setbacks throughout the development process. | 10% |
| 1-12 | Participation | Participating in class, presentations, etc. | 10% |
A note from Dave (a former TA) about file submissions:
When submitting a game to the TA for marking, make sure to include your entire project folder in your submission - a zip file containing it all is fine. Or upload the folder with your game to a file sharing site (like Dropbox) and send a link to the TA. Also, you should include a "ReadMe" text file that specifies which file contains the code necessary to start your game running.
Make sure that what you're sending is a complete, fully playable game, even if it's simple. You should always, in some sense, be able to "play" it, whether it's a "game jam" game or your nearly completed project. The TA should be able to control some aspect of it with the keyboard, mouse or controller. There doesn't need to be a story, or an objective for the player to complete (though that would be nice), but it should be working towards something that you think a user would actually enjoy playing. You needn't go overboard with fancy textures or character models, but there should be some evidence of thought in that direction.
What These Terms Mean
Game Jams
The "game jam" is a common event within the game design community, where developers get together for a weekend to hack together a basic playable game in a short period of time. The result is rough and incomplete but playable, and illustrates ideas that could lead to a more complete game.
In response to the growing culture of game jams in the game design community, there will be a game jam "assignment" taking place from 10am to 4pm on Saturday, September 16th in BA3200. During that time, you will create a basic game with another person along a given theme (design in the morning, implementation in the afternoon). When the game jam ends, everybody shows off their game to the rest of the room.
Participation in the jam is highly encouraged. However, if it's impossible to attend, you may also create a game on your own and submit the result to the TAs for the course by emailing it to pmu199ta@cs.utoronto.ca, along with complete instructions on how to run your game. See the notes above on how to submit games to the TA. Assignments submitted that way are due before 11:59:59pm on Sunday evening.
Note that while this "game jam" assignment is primarily a skill-building exercise, you must submit an actual game in the end. Put some thought into the making something that the TAs can enjoy, not just something they can interact with. Also, recreating tutorial levels is not sufficient to get full credit for the assignment.
If you cannot make it to the game jam session
People who participate in the game jam sessions enjoy a great advantage over those who don't, if only because they provide an opportunity to meet potential group members. They also teach you how to make a quick, playable game prototype, and then iterate on that prototype to make a full game. It's also the best way to learn how to use a game design tool, with classmates and the TA present to help answer questions.
However, if you aren't able to attend these game jam sessions (part-time job, family reasons, religious reasons, etc), then you can create a game on your own, and submit it to the TAs for marking, as was done in the past.
Game Brainstorming
When studios decide to start on a new game deisng project, they often take the opportunity to solicit ideas from across the studio. Employees at all levels can submit ideas, and the head of the studio will decide which ones merit further exploration.
What this means for the course is that the project ideas that you'll be working on will come from you and your classmates, but the instructor and TA will decide which ideas have the most potential. It's in your interest to submit ideas during the brainstorming period that are innovating, thoughtful and practical, so that you increase the chances of working on your own idea. And if idea generation isn't your strength, you don't have to worry about working on an idea that will be overly challenging in the long run.
Design Blogs
Game Design Blogs are a weekly record of what you've done on your project, including any progress and decisions you've made, obstacles that you've had to overcome, and current snapshots of your game in its current state. At certain points in the course, it's also where you present key documentation, such as your design document or your playtesting report.
There are multiple reasons for maintaining a design blog.
- From a purely design point of view, it helps you recall why certain decisions were made, and helps you track your progress.
- It also allows the instructor and TA to monitor your progress and understand your game better (especially through the snapshots). This gives us a chance to deliver better feedback throughout the design process.
- From a course point of view, you get marked for working on your game on a regular basis, and your design blog illustrates the pace of your work.
- It also allows us to give you credit for work you've put into your game that might not show up in the final product. For instance, you can feel free to cut any sections of your game that aren't working, instead of feeling tempted to keep them just because of the time and effort you put in.
In the end, this is a good habit to develop when designing anything, and we need it to evaluate your work. So there are marks associated with keeping it up.
Game Pitch
The "pitch" (also known as the "elevator pitch") needs to be a concise way to describe a game idea, along with the key element (maybe two elements) that will make this a novel and compelling game. For instance, the pitch for Pokemon Go might be, "a Pokemon game that you play on your phone, where you explore the real world to uncover Pokemon, gyms and Pokestops". You should be able to expand on your pitch with more details if prompted, but if your pitch is stopped at any point, whatever sentences you've managed to say should have conveyed the most cruicial information possible.
Design Document
The design document is the more important stage in game development, short of the final product itself. When a game studio is producing a game for an external client, the game design document acts as a contract, outlining the details of how the game will be made, and what parts will be worked on by who, and when.
A great amount of time and effort is put into making sure that the game is described in painstaking detail. Not doing so opens up the client to receiving shoddy workmanship that technically satisfies the game description, and opens up the studio to changing requirements that also technically satisfy the game description. When done right, two different studios operating from the same design document should produce exactly the same game.
For this course, we want to see as much detail as possible in your design, such that there are no questions about what the game will look like, what the components of the game will be and how it will behave. A sample design document has been placed in the Links section on the left. The only major difference is that you will include this as part of your design blog for us to inspect and comment on.
Two other things that must be submitted in your design doc milestone. First, a tech proof-of-concept. That is, you should be able to demonstrate the key game mechanisms and technical elements that form the core of your game. Many people propose designs that aren't based in reality, so you need to prove that the game you're designing is actually possible. Second, a schedule that outlines a detailed breakdown of the tasks for your alpha demo, including who is going to work on each part, and when. These tasks should be "atomic", meaning that there is no practical way to divide them into smaller tasks. This should also include the list of features that will be added for the beta milestone, but it's understood that this list is highly subjective to change.
Mini Demos
Mini demos are 5 minute in-class meetins where you update the instructoro on the progress of your game. Included in this are obstacles that you encountered, a list of goals for the following week and where appropriate, a small demo of your current game.
If little or no progress has been made from one week to the next, the team forfeits the mini-demo mark for that week.
Alpha Demo
The alpha for a game is usually the first playable prototype, featuring all of the main eleoments of the game in some recognizable and playable form. It's meant to be rough around the edges, but with all the game elements that you want to get feedback on.
Playtest Report
Playtesting is essential to discovering whether the game you envisioned is the game that others perceive. The report documents how effective the game is at achieving the goals it set out to achieve, and what action should be taken to better achieve these goals. This also requires a simple analysis, the result of which will specifically indicate what portions of the game need to be cut, and which need to be fixed (with a preference for the former).
Beta Demo Presentation
The beta stage indicates a feature-complete game. Which means that no new features are added, and the focus of the remaining two weeks is polishing what's already there.
Game Release
The game release indicates that the product is ready to ship, even if it means that certain features aren't included. It coincides with a final playtesting session, where external testers in your target aduience. Their evaluation goes toward your final mark, as do the peer and self-evaluations. Depending on your contributions to the group, you may get your project mark increased or decreased by a certain percentage, so be a good citizen to your partner.
Participation
The course offers (and sometimes requires) active participation in the course components, which involved giving feedback during presentation sessions, attending game-related events, engaging in class topics, etc.