Project 2 is similar to project 1. Make a game. Very limited time. Small team (3 this time). A lot less restrictive in terms of content. 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 5 – team planning email
- Friday, October 12 – signs of life
- Friday, October 19 – show-and-tell / play-tests
- Friday, October 26 – Festival!
Project Objectives
- To have you make another game
- To have you try to apply some ideas from game design in order to make a good game
- To have you work in a group of 3
- To force you to write some shaders
- To have you try WebGL
Some Ground Rules
- You must work with your assigned partners.
- Your programs must run on the computers in the 1366 CS lab.
- Your program must run in a web browser. You may specify which one (within reason) – so it’s OK to say “it must be Chrome.”
- Your game must use shaders. Each person in the group must write a pair of vertex/fragment shaders. Ideally all 3 pairs should be used in the game (if not, you’ll have to have a separate page that shows it off). You could use WebGL for the instructions/splash page, and that qualifies as well. (but 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 or three.js). 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)
Some thoughts…
- While you are required to use WebGL and shaders, you are not required to make a 3D game. WebGL and shaders can be very useful for doing 2D things as well.
- Balance ambition with reality. A simple game is better than a complex non-game.
The Milestones
Kickoff: Tuesday, October 2 – teams announced. In class, we’ll announce the project 2 teams. You’ll want to start quickly.
Milestone 1: Friday, October 5 – 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. The more details you give us, the more feedback we can give you. In Lab session, we’ll have a WebGL tutorial, to help you get started.
Milestone 2: Friday, October 12– 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.
Milestone 3: Friday, October 19 – 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. (this is similar to what we did with Project 1)
Milestone 4: Friday, November 4 – Festival! We’ll meet in the lab and play games. (the ones you’ve written), to have some fun and give each other feedback. This is effectively the final handin for the project.
There will be a “post-mortem” assignment due after the playtests (similar to project 1).
