Project 1: update: Final Handins

Turning in Project 1 has a few parts. Be sure to do all of them

1. The game itself (everything necessary to play it)
2. Your group “reflection” exercise
3. Your individual “reflection” exercise (which includes the recommendation letter for your partner)
4. Your playtest feedback (of other people’s games)

In class, on Friday, September 30th, we’ll play the games. This means you need to have it working, and in the directory before 2:30 on Friday, September 30th.

Handing in the game

Your game must be accessible via the web. Your handin directory is on the web at:

https://graphics.cs.wisc.edu/Courses/Games11/Proj1/YOURGROUP (where YOURGROUP is the directory name). Note: if you are willing to make this readable to people outside of CS, just remove the .htaccess file from your directory.

The “index” page (index.htm, index.html, …) in this directory should be the entry to your game. It might just have the instructions (with a link to the game), or it can have the game on it. Remember: your game must stand alone (so it needs to have instructions).

Please check to make sure your game is playable when someone goes to this link.

You must have the playable game (with instructions) in place before class time, since we’ll play the games in class. If something comes up during play testing, and you feel compelled to change the game after 2:30 on 9/30, please make sure that there is always some playable version on the web.

Playtesting

Critiquing games is a good way to learn about them. Getting a critique is a good way to learn. Watching someone use your program is a good way to learn.

Note: the the critiques here are not to determine your grade, although the fact that you write critiques is a requirement for the grade. Getting practice thinking critically about games is one of the goals here.

During the in-lab class time (on Friday, 9/30), we’ll play test games. The idea is that everyone will play everyone else’s game. There isn’t time for each person to play 14 games, so we’ll each get to play a few.

Each group should log in and set up one computer to play their game. Your game should be self-explaining, so other can just walk up and play. However, we recommend that one person stays to watch others play the game (hint: try just to observe), while the other partner plays other people’s games. Then switch roles after a while.

Each person will be required to give feedback on at least 5 other group’s games – you will be allowed to do this anonymously. For each game you play, take a 3×5 index card (we’ll provide them) – write the name of the group, and your feedback. If you want to be anonymous, do not write your name on the card. When you’re done, take the cards you have filled out, place them in an envelope, and put your name on the envelope. This way the TA can check that you have given feedback to others. He will sort the cards and give them to the groups who wrote the games.

Please be constructive but critical in your feedback. Saying “great game” has little value – but if you can be specific about good points and bad points, you can be helpful. Consider both the game aspects (was it fun?) and the technical aspects (which you should now appreciate since you’ve done it too). Remember: critique the game, not the people who made it. And remember, all the groups were working under the same insane time pressure.

Note: if you don’t get to play enough games during class time, you may play the games over the weekend (since they are all on the web!).

Bring your envelope (your name on the envelope) with 5 or more cards (each one has the group name and the feedback) to class on Monday, October 3rd. The envelopes are due at the beginning of class.

Group Reflection Exercise

After doing a big project, an important aspect of learning about it is to reflect on what you have just done.

Please answer the following questions. You can write about other things too if you want.

1. How happy are you with the game you produced?
2. If you had another week, how might your game have been better?
3. Describe your design/development process. What went right/wrong? How did you divide up the tasks?
4. What would you have done differently? (or will you do differently next time)
5. If we give this assignment again next year, what should we (the course staff) do differently to improve the experience for the students?
6. What might we not appreciate about your game, if we grade it simply by playing it and looking at the code?

Note: it is much better to be honest than delusional. If you simply say “our game was great” (without much thought as to why), its not as good as giving a thorough critique (even if negative). We’re looking for the depth in your thought. We’ll judge your game ourselves (modulo #5), and are probably more realistic in our expectations than you are.

Please send your group reflection to the TA and professor (a copy to each by email) on Monday, October 3rd. (any time – e.g. not Tuesday). We prefer that the content is in the text of the message, rather than as an attachment.

Note: while reflection is important, we don’t expect this to be a big deal – it should take about 30 mintues (of time with the group together).

Individual Reflection Exercise

We like to give people a chance to talk about the project without their partners, for much the same reason as the group reflection.

1. What did you learn from this project experience?
2. How well did your group work together?
3. For the next project, Javascript may be optional. Given the option, would you choose to work in Javascript?
4. Is there anything else we should know?
5. If you disagree with what was written in your group reflection response, you can give your opinion here.

Please send this by email to the TA and Professor. We will make our best efforts to make sure this feedback is not shared with anyone else.

As another part of this, we ask you to write a “recommendation letter” for your teammate(s). (As a Professor, I have to do this all the time). Imagine your teammate is applying for a job developing games, and you receive a request like:

• PERSON has applied for a position as a game developer with our company. The position involves team oriented development of games, including programming and design. We are interested in your candid assessment of their fit for such a position. We would appreciate your thoughts on their strengths and weaknesses as a member of a game development team, including their technical skills and ability to work together with a team to design, develop, and deploy games. Your response will be kept in strict confidence to the extent allowed by law.

Please write a recommendation for each of your teammates, and send it (by email) to both the professor and TA. Again, we will make our best efforts to make sure the information is kept private.

We may use this information in forming teams for future projects. (in case you haven’t figured it out, you will have different partners for future projects).

Again, we don’t expect a huge essay for this – spending 20-30 minutes should be sufficient.

Improvements After the Playtest

Based on the feedback you get at the playtest, you may have lots of ideas for improvements to be made to your game. Or fixed and additions that didn’t quite make it in on the rushed schedule. You are welcome to make changes later – in fact, if you have improved versions, let us know since we’re curious. However, these after-the-playtest additions will not be graded.

And, to honest, the grading expectations are pretty light: if you have a complete playable game that has some flocking going on, you’ll get a good grade. Making a great game is for your own personal satisfaction: if you work this hard, its nice that the result is fun.