Your mission in this project is to write a game that runs in a web browser using javascript that implements flocking (or something like it) in some way.
The schedule (details on each phase follow later on):
- Friday, September 7th – partner requests due
- Monday, September 10th – partners announced
- Friday, September 14 – signs of life demonstration
- Friday, September 21 – flocking “toy” demonstration
- Friday, September 28 – final demos
Note: many of the concepts that are important for this project will be discussed in lectures along the way. Not everything will make sense when the project is first announced. For example, you are probably wondering about the difference between a toy and a game, what we mean by flocking (or local control), …
Project Objectives
The goals of this project are:
- To have you make a game
- To have you make something that runs inside a web browser, written in Javascript. And to see how to do in-browser graphics with HTML5.
- To have you work in pairs.
- To have you implement flocking (or something like it), and Experiment with the kinds of behaviors you can create by mixing together simple behavior rules. Mainly to get a feel for “creative tinkering”.
- To get a sense of where efficiency issues may come into play.
- To demonstrate a notion of the difference between a toy and a game.
For some of you, one or more aspects of this project might not be so new. You might already be a Javascript programmer, or you may have already experimented with Flocking (for example in 559). If this is the case, we hope that you’ll make something extra cool, and find other things to learn from the project.
A Caveat: It is much more important that you produce an actual, playable game that has flocking for the deadline than you produce a good game, have a fancy premise or artwork, …
The Ground Rules
- You must work with your assigned partner. We will take requests (send email before class time (2:30) on Friday September 7th, however, we make no promises that we can honor requests.
- You must fill out the class survey by noon, September 10th. If you do the survey late, we might assign your partner late.
- We will assign partners on Monday, September 10th. You should start thinking about the project before this date – in fact, you might start learning about Javascript.
- Your programs must run in a web browser as installed on machines in the 1358 CS lab. These machines should have current versions of Chrome, Firefox, and IE. Your program just has to run in one of these browsers (and you can tell us which one).
- Your program should be written in Javascript, and cannot require any browser plugins (so no Java or Flash).
- You may use any open-source (or freely available) libraries for Javascript (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 (you can have hierarchy), and make sure everything works with relative links. (we may copy all the files to a laptop and look at things off-line).
- You should do things in 2D. We’ll talk about issues in 3D orientation later in the class.
- You need to experiment with scalability and performance (in the toy, at least). It’s OK if your program gets really slow with more than 50 boids, but you need to be able to change the number of boids (and obstacles, if those are a limiting factor) so you can see the tradeoffs.
- 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 program must implement some kind of flocking behavior (with a reasonable number of “boids” or agents that move around and influence each others’ movements). You can get a sense of what I mean by flocking from my old notes page http://graphics.cs.wisc.edu/Courses/Games08/Main/Flocking.
- Your handin directory will make your program available on the web, so that the instructors and your classmates can look at it. By default, assignments are world readable (so anyone can play). If you prefer, we will provide a mechanism so you can limit who can see the game (although, the instructors and class must be able to see it). (we will provide handin directories before the Sept 14th deadline)
- You should use HTML5 Canvases for drawing. You may use SVG (but this is probably harder). We discourage you from using WebGL (since we’ll get to that later in the class). For this assignment, we will only provide help with Canvas.
- Final handins must include user documentation. There will also be a set of “personal reflection” questions to answer.
Catastrophes:
- If you drop the class, please let the instructor know ASAP so we can make arrangements for your partner.
- If your partner drops the class, let the instructor know ASAP so we can figure out what you should do.
- If you have issues collaborating with your partner, please inform the instructor, and we’ll try to help.
The Milestones
We’ll have a “Javascript Jam Session” where we help people get started with Javascript and doing graphics in the web browser. This should give you enough of the mechanics to get the project done. In fact, the tutorial will probably fulfill the requirements of the first milestone. Note: the turn in mechanisms will be announced closer to the assignment dates.
Milestone 1: Signs of Life (due before class time, 2:30 – Friday, Sep 14): Your team must show that you’ve written a Javascript program that has objects moving around on the screen, and does something with user input (respond to keys or mouseclicks, or …). This is just a check/no check thing. It doesn’t matter what the program does – as long as it meets the simple requirements. We just want to make sure you’ve gotten started, and figured out some Javascript.
The bar is pretty low here – we just want to make sure you’ve gotten over the hurdle of getting started with Javascript and working with your partner on the project. Of course, we’re happy to see something cooler. In fact, if you go through the tutorial, you will have something that fills the requirement.
To turn it in, you can do one of the following:
- Come to the lab session on Friday, September 16th at 2:30 and show us your program. Make sure we cross you off the list.
- Send us email (before Friday, September 16th at 2:30) with a URL where we can see your program running. (this should be in our handin directory)
We’d prefer to see people (even briefly) on Friday, so we can check in with you and see that you’re on track for making something for the next milestone. But showing up for this session is optional. Only one person needs to show off the program (in fact, if you send things by email, we’d prefer to get one email from the group).
Milestone 2: Flocking Toy (due before class time, 2:30 – Friday, Sep 21): Your team must show flocking in the web browser, with some interaction and ability to tune things / affect things. We call this a “toy” since it may not be a game, but playing with a flocking simulator is often fun. You will need to be able to experiment with the number of boids in your flock, and give some idea as to the performance bottlenecks. You will be asked to turn in your program, and answer a few questions about its performance (as a text file in the handin directory).
The demonstration requires you to demonstrate a flocking “toy” – a program that demonstrates flocking behaviors, and allows some fiddling with it (so that it might be fun to play with – we did not require it to be a good toy). It’s OK if the “interaction” is to tweak internal parameters in the code, but if this is the case, you’ll need to demonstrate it in person. The tutorial program (which requires editing code in order to fiddle) probably doesn’t fulfill the spirit of the assignment.
For the demonstration part, we will have a lab session during the class lab time slot on Friday, September 23rd. You can show your program to the course staff – make sure one of us crosses you off the list. I think we’re all interested in seeing what you’re doing, so preferably you will show it to all of us.
We encourage people to take advantage of the lab sessions. It’s an opportunity to see what others are doing, and share what you’ve learned about implementing Javascript graphics and whatnot.
Milestone 3: Flocking Game (due before class time, 2:30 – Friday, Sep 28): We’ll do in-class demos of projects, so your program must be done (in terms of its functionality). Before class, you’ll need to put your game into the handin directory so everyone can play everyone else’s game during class time. Remember, the important thing here is to deliver a playable game (that contains flocking) on time: it is better to have a slightly simpler game, than to not have a game (e.g. to turn in something that is incomplete or doesn’t work).
In the lab session, everyone will play everyone else’s game and provide feedback to one another. The mechanisms for this will be explained in class.
Your final handin is due any time on Friday (e.g. before Saturday), but we will judge your game at demo time. You can use the extra hours to add documentation, etc.
Your “index page” (the thing that comes up when we go to the directory via the web) must have user instructions, as well as a link to play the game (if it doesn’t start automatically). Your “personal reflections” can be sent by email to both the TA and Professor. Each person must do the reflection independently. The reflection questions will be provided closer to the due date.
Some thoughts…
- We understand that learning a new programming environment, learning and experimenting with a new technology (flocking), designing and tuning a game, … is a lot for 3 weeks. Our expectations are only slightly unreasonable
But part of the challenge is to see what people can do within the constraints of time. We did this last year and students did some amazing things! (we’ll show them to you) - While it’s preferable that flocking is part of the game, it is OK if the connection is weak. A good example is that we’ve seen games where the user must influence the flock to achieve goals (for example, to heard the flock into a corral, like a sheepdog). A cop-out would be to have the flock be eye candy in the background while the player did something else like play tic-tac-toe.
- Why are we making you use these tools? In the real world, the decision of what tools/platform to use are usually given to you by the management. Often, these give you artificial constraints that you have to work within.
- We want you to be creative in seeing how you can best use a highly constrained setting. Anyone can make something cool given infinite resources 🙂 Your challenge here is to make something as cool as possible, given that you have a simple, slow implementation platform.
- To get an idea of how simple it can be, look at the Tutorial. (remember, the tutorial is a Mercurial archive – clone it and you can see all the versions of the code to see how it developed).
- For some better examples, check out some of last year’s projects. Last year’s project (basically the same as this years) results are here. The 2010 assignment (here) was different: students had less time, different constraints, and slower computers. But there were still some interesting projects, such as: Ian and Irene, Jeff and Chris (sheepdog toy), Jordan and Tom’s Flocking Project – Zombie Flockalypse (which requires Java), Brad and Will’s Super Space Tempest: Revenge of the Boids, and there are many others…
Some of the Missing Details
Inevitably, there are some details that are missing from this project announcements. Updates will be announced on the course web, or in discussions on the class forum.
However: some things you might be wondering…
- We are not assigning project partners until Monday, September 10th. You can get ready for the assignment before then (like starting to learn Javascript, etc).
- We will have lectures and help sessions that will help you learn about flocking and this project. The flocking lecture will probably be September 6 or 11.
- The exact handin mechanisms will be determined. For Milestone 1, we will allow you to just show us in the lab session, or send us email with a link.
- For the final handin, expect to be asked about “why is your game a game” and to discuss the various design elements (for example, in the MDA framework).
- We will provide you with handin directories closer to the handin date.
- My old (2008) notes on Flocking are still available at http://graphics.cs.wisc.edu/Courses/Games08/Main/Flocking.
If you have any other questions, please ask (post a question on the forum, send email to the instructor, or ask in class). If you have a question, I’ll bet that several other people have a similar one.
