Project 1: An in-browser flocking game!

Your mission in this project is to write a game that runs in a web browser using javascript that implements flocking in some way.

The schedule (details on each phase follow later on):

• Friday, September 9th – partner requests due
• Monday, September 12 – partners announced, real work begins!
• Friday, September 16 – signs of life demonstrated
• Friday, September 23 – flocking “toy” demonstrated
• Friday, September 30 – in-lab demo session
• Monday, October 3 – final handins

Project Objectives

The goals of this project are:

1. To have you make a game
2. 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.
3. To have you work in pairs.
4. To have you implement flocking, and Experiment with the kinds of behaviors you can create by mixing together simple behavior rules. Mainly to get a feel for “creative tinkering”.
5. To get a sense of where efficiency issues may come into play.

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.

The Ground Rules

• You must work with your assigned partner. We will take requests (send email before class time (2:30) on Friday September 9th, however, we make no promises that we can honor requests.
• You must fill out the class survey by Friday September 9th. If you do the survey late, we might assign your partner late.
• We will assign partners on Monday, September 12th. Technically, no work on the actual project should begin until you know who your partner is. However, the Javascript tutorial session will give you a head start, and you can start thinking of things to talk to your partner about before you find out who they are.
• Your programs must run in a web browser. Preferably, the web browser installed on the computers in the 1358 CS lab. However, if you want to require a specific browser, make sure there is a “portable” version of it available. (in particular, you might want to use Portable Chrome)
• Your program should be written in Javascript, and cannot require any browser plugins (so no Java or Flash). If you find Javascript programming to be problematic, you might consider using ProcessingJS. If you really get stuck, you might just fall-back to writing things in Processing (which is a variant of Java). However, we strongly encourage you to try to do everything in Javascript.
• 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, 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 other’s movements).
• 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).

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 on September 9th. This should give you enough of the mechanics to get the project done. In fact, the tutorial will probably fullfill 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 16): 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.

Milestone 2: Flocking Toy (due before class time, 2:30 – Friday, Sep 23): 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).

Milestone 3: Flocking Game (due before class time, 2:30 – Friday, Sep 30): 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. We may lock the directories to discourage last minute hacking. 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).

Milestone 4: Final Handin (due before Monday October 3, that means anytime on Sunday) – while your code should have been finalized for Milestone 3, you will have a few days to finalize the writeup (requirements to be provided), and clean up the instructions and other documentation. Each person will also have to turn in the “reflection exercise” (details coming) by email (note: the group parts are turned in by placing them in the handin directory, the individual reflections are sent to the instructor by email).

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 only gave people 2 weeks, and they did some amazing things!
• 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.
• If you want to see some simple in-browser examples, check out the processingjs demo, or Prof. Gleicher’s first experiment.
• For some better examples, check out some of last year’s projects. Last year’s 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

Because we wanted to get the basic assignment out ASAP, we are releasing it in an incomplete state. As more details get announced, this posting will be updated (and we’ll make an announcement on the “news” page of the course web).

However: some things you might be wondering…

• We are not assigning project partners until Monday, September 12th. You can get ready for the assignment before then (like starting to learn Javascript, etc), but you can’t really start on the actual design or coding.
• We will have lectures and help sessions that will help you learn about flocking and this project. The flocking lecture will probably be September 12 or 14.
• The exact handin mechanisms will be determined. For Milestone 1, we may 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.

If you have any other questions, please ask (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.