Project 2: An In-Browser Game

Project 1 was a huge success. 14 games. While some were better than others, things really exceeded expectations. Its amazing what was achieved. However, rather than giving more time to clean up the results from Project 1, I think we need to move on to project 2.

Several people commented that they had wanted to have a little more experience with game design before doing project 1. And probably, you have new thoughts about how to use the tools (since you have a lot more experience).

Project 2 is similar to project 1. Make a game. Very limited time. Small team (3 this time). A little less restrictive in terms of platform (we aren’t going to REQUIRE Javascript), a lot less restrictive in terms of content (only a small technical requirement). But, you’ll have more experience, and a few game design lectures behind you.

The schedule (at least as insane as last time):

• Friday, October 7 – team discussion email
• Friday, October 14 – planning show-and-tell
• Friday, October 21 – show-and-tell
• Friday, October 28 – playtests
• Friday, November 4 – festival! (note, project 3 will start before Nov 4)

Project Objectives

1. To have you make another game
2. To have you try to apply some ideas from game design in order to make a good game
3. To have you work in a group of 3
4. To force you to write some shaders
5. To see who is brave enough to try WebGL

Some Ground Rules

• You must work with your assigned partners.
• Your programs must run on the computers in the 1358 CS lab.
• We would like your programs to run in the web browser. We encourage you to write it using Javascript/HTML5. However, you can make a Java applet if you really want to (we suggest Processing to give you easy access to graphics). It’s up to you to figure out Java graphics. If you require a specific browser, or plugin, just make sure you can get a portable version for the 1358 lab.
• We MAY grant exceptions to the in-browser rule. However, we will have higher expectations for this. If you want an exception to the in-browser rule, you must negotiate this with the Professor before October 11th.
• Your game must use shaders. Each person in the group must write a pair of vertex/fragment shadres. Ideally all 3 should be used in the game (if not, you’ll have to have a seperate page that shows it off). If you’re really stuck in getting shaders into your game, you could write shaders that work off-line, and use those to make images that you use in the game. This is, of course, discouraged. but it is a fallback if everything goes wrong. I guess you could use WebGL for the instructions/splash page, and that qualifies as well. (but again, the spirit of the assignment is to try to use shaders to achieve fancier in-game graphics than you could do otherwise).

• You may use any open-source (or freely available) libraries (such as jquery). However, you must include these libraries as part of your handin.

• Your handin must be fully contained in the handin directory – when your program runs, it should not fetch pieces from anywhere else (like loading an image from a website somewhere else). Put all assets into the one directory, and make sure everything works with relative links. (we may copy all the files to a laptop and look at things off-line).

• The final handin must be a single-player game. It should be self-contained. That is, someone should be able to load the web-page, read any instructions necessary, and start playing. Sufficient documentation is part of the handin.
• Your game must be in good taste.
• It must not require any intellectual property that isn’t either yours or freely available.
• You should not use any artistic or code assets that you do not have license to show. (so if you get art or music, make sure its creative commons or open source).
• It must not require code you’ve written previously.
• Many students in class have their hobby projects or code they’ve written previously. You can’t use this.
• While games must be designed so they are practical to build without using previously written code, teams can make use of "old" code from their members providing that the entire team agrees, the person providing the code agrees to make it publicly available, the code is not overly "game specific", and the students get permission (by email) from the instructor.
• It must have a low-startup overhead. You know how the playtests work now. If it takes 10 minutes to read the instructions, people may move on.
• It should not require the player to already know something obscure.
• The target audience for your game includes the TA and professor, and other members of the class.
• If your game requires the player to be familiar with (for example) the scenario from some book, the characters from some movie, or the rules of some existing game, you might be in trouble if the player hasn’t read the book, seen the movie, or played the game.
• It must provide for a short experience, but have replay value (or extended play)

The Milestones

Milestone 1: Friday, October 7 – team discussion email: By the end of the day on Friday, October 7th, please send the TA and Professor an email (one per group is fine), to let us know that your team has met, and that you have an idea for a game. All we expect by this point is that you are working together and have at least an initial design. Please let us know about your implementation decisions (what language you intend to use, …). Given what you send us, we will try to provide feedback, maybe talking you out of things we think might not be feasible in the time limit.

Milestone 2: Friday, October 14 – planning signs of life: In Friday lab session, at least one member of your team should come to show off your initial progress and discuss your game. By this point, you should have some design done, and hopefully the beginnings of an implementation.

Milestone 3: Friday, October 21 – show-and-tell: In Friday lab session, everyone should come to show off what you’ve done, and maybe get some feedback from others. Ideally, you’ll have a prototype game so that people can do some early play testing. But you should at least have something to show so you can get feedback.

Milestone 3: Friday, October 28 – playtests: We’ll have a Friday lab session playtest (like we did for Project 1). Note: we will allow for some game adjustments after the playtest, but the following week you’ll be busy starting Project 3.

Milestone 4: Friday, November 4 – Festival! (note, project 3 will start before Nov 4). Everything must be turned in before class time (including the reflection exercises). This will be similar to the play test, but a little less structured. We’ll just meet in the lab and play games. (preferably, the ones you’ve written).