• View
• History
• Print

GameProject / FinalHandins

The "final" final projects will have three parts:

1. The group handin ("GoldMaster")
2. The individual handins
3. The demo at the Festival of Games

Now for a description of each part

The Group Handin

Each group must provide:

1. A ZIP file with everything needed to build the game, including a README with instructions.
2. A ZIP file with the executable and all the data files needed to play the game. It should be set up so its as easy as "unzip, and double click on the exe" - but if there are some other steps, be sure to explain it in the readme
3. A public web page (on the Wiki) for the game. (note that by public, you can choose to make it public to the class only)

You can put the ZIP files in one team member's wiki "pub" directory and send email to the TA so we know where it is. We will move the ZIP file to a safe place (since you probably don't want your project on the web), UNLESS you specifically say you want the files to be available on the wiki. (if that's the case, you need to link to it from the web page).

Before the deadline, one member of the team needs to send email to the TA telling them where to find the ZIP files, and a link to the "main page".

The Web page for the game consists of several parts:

1. A "main" page
2. Player Documentation
3. Technical Documentation
4. Playtest Summary
5. (Optional) Plan Review

There should be links to each one of these pages on the main page. There should also be a link to the original game proposal, as well as the approved game "plan".

Some notes on these:

Main Page

This should give an overview of the game - think of it as the marketing. It should describe the game, and make the reader want to try it out. Include pictures.

During play testing (or even later evaluation), we might not get to see the coolest parts of your game. This document is where you get to really show off.

Player Documentation

What the player needs to know. This might be the thing you print out to hand to the player. It might just be a screen shot of your help screens.

Remember, your game needs to be self-sufficient (not require additional help to the player beyond what you provide).

Technical Documentation

Tell us what's going on inside. What cool algorithms and methods did you use. What tools did you use? How is the code organized? Anything particularly interesting about how you built the game? Anything clever in how you organized things so that your team could work together? Anything you are particularly proud of?

We will look at your source code, and look through the other non-code components, but we can't really look too closely. So this document is your chance to tell us why what you did was interesting technically.

Playtest Document

Describe the feedback that you got at the playtest. What did you learn from the experience of having others play your game? What did you do based on this feedback?

Three specific things that should be in this document:

1. What did you learn from the playtest?
2. What changes did you actually make based on the playtest? (this is important so we know what to look for in the final game).
3. What changes would you like to have made based on what you learned from testing?
4. If you had more time to work on the game, what would you do?

3 and 4 are similar - they both ask what you'd do with more time. But we are curious as to what things were influenced by testing, and what things you just want to do in general.

You might also want to comment on whether you would have figured out what you learned from the playtest from just playing the game yourself.

Optional: Plan Review

You don't have to do this, but we're curious...

Go back to your original plan (the one that was approved).

• Did things work out as you expected?
• How did things change as the project progressed?
• Could you have (or should you have) seen the trouble spots?
• Could better planning have lead to a better result / experience for the team?

The individual handin

There are two parts to this: a "post-mortem" and a class evaluation.

Each person must write their own "post-mortem". This should be done by each individual. You can send this as a text document via email to both the TA and the instructor. All the feedback that we receive is confidential. You may choose to put the first few parts publicly on the Wiki, but if you do, put a link to it in the email you send.

1. Your own assessment of your game. Do you like it?
2. A list of what you think went right, and what you think went wrong. This should consider both the process, and the final product.
3. A list of what you would have done again, and what you would have done differently.
4. Any advice you'd have for future students.
5. A discussion of what you learned from this whole adventure. (note: there will be an opportunity to critique the project in the anonymous part below)
6. An evaluation of each team member's contribution (including your own), and of the overall group dynamics.

Please take this seriously. The act of reflecting on what you have done is a key component of learning from it.

Class Evaluation: I really want to know what you thought of the class, and what I might do in the future to make it better. You've already had some opportunity to do this, but I have some specific questions I'd like to ask.

To keep this anonymous, print the form, fill it out, put it into an envelope, put your name on the envelope, and give it to the TA at the final. He'll use the names to check off that everyone turned it in, and then throw away the envelopes.

So, you have to turn in an envelope, but if you don't want to give any more feedback, you can just turn in a blank piece of paper. But I really would appreciate feedback. (making everyone turn in an envelope makes it harder to figure out who wrote what. also, if you go through the trouble of writing your name on the envelope, hopefully, you're write something)

You can write whatever you want, but I'd like you to think about the questions here.

The Festival of Games

FestivalOfGames

Your group should have a prepared 15 minute presentation/demo. Yes, it will be evaluated. In addition to showing off your game (either live or just with screen shots), you probably will want to have some other visuals. Plan how you will use your time. Use it as a chance to show off how cool it is both from the user's perspective, but also in terms of how it was built.

You don't need to fill up the whole 15 minutes.

The exact mechanics of how we'll do the presentations and demos will be determined later - we're working on borrowing a 1358 computer, but you might have to put things onto my laptop.