• View
• History
• Print

Main / Project1

Project 1: Flocking

Deadlines:

• Monday, January 25th, before noon - partner requests
• Monday, January 25th, during class - partners assigned
• Friday, January 29th (during class time) - "Signs of Life" - you need to demonstrate at least something working (during the open lab session).
• Monday, February 8th (before noon) - Project handed in. Web page with documentation and the executable available.
• Friday, February 12th (before 7am) - Final handins.

1.  The Basic Idea

You will implement an interactive program that simulates a flock of objects "flying" (or driving, running, ...) around. Flocking was described in class, and resources about it are given later.

We want you to:

• Experiment with the kinds of behaviors you can create by mixing together simple behavior rules. Mainly to get a feel for "creative tinkering".
• Build something interactive - the user really must be able to influence what is going on with the flock.
• Think about game design. Try to make this fun for the user. Can you make it a game? Or at least a fun toy?
• See where numerical and efficiency issues come to play.
• Make something that runs in a web browser.

2.  The Ground Rules

1. You must work with a partner. You may request a partner (before noon, on January 25th), but ultimately we will assign partners.
2. We recommend you use some form of source control. If neither you or your partner have any experience with this, we'll help you set it up. We can provide a repository space if you need it.
3. Your program must run in a web browser, preferably without Java. Ideally, your program should run in a wide variety of places, but at a minimum, it should run on the standard web browser installed on the machines in 1358CS. (which I believe is Firefox 3.5.X running under Windows XP).
4. The user must be able to interact with the flock (influence its behavior). Using the mouse to add another boid (which is what the processing demo allows) is not acceptable (see below for a reason I single out this example). The user should be able to guide, steer, chase, or ... the flock
5. You should do things in 2D. We'll talk about issues in 3D orientation later in the class.
6. You need to experiment with scalability and performance. 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.
7. At least one member of your team must come to the open lab session and demonstrate that you have a program in a web browser with some boids moving around.

The rest is up to you. You don't need to draw things in a fancy way (triangles are great), but if you want to make things pretty, that's great.

Beyond the basics, its up to you how to make it interesting. You might try to make really cool behaviors. You might try to make it look really pretty. You might make it work with massive scales (hundreds or thousands of boids).

One thing we'd like beyond the basics is for you to design something that is fun for the user. Can you make your program into a game? (Maybe the user has to interact with the flock in some way to achieve something? Maybe preditor/prey? ...). It would be awesome if you could actually implement the game aspects, but given the time constraints we understand this might be challenging. You will be required to describe ideas for making a game using flocking (e.g. do some of the initial design aspects), but you won't necessarily have to implement it.

3.  Implementation Notes

We want you to make this run in a web browser.

You could write it in Javascript, using HTML5 Canvases. That sounds hard (especially if you don't already know Javascript).

You could write it as a Java applet. This is OK, and is probably very comfortable for most of you. We'd prefer if you didn't choose this approach. If you do, we hope you make up for it in other ways (like making it exceptionally cool).

We recommend that you try processing.js. This is a little programming environment/language/toolkit that runs in javascript that is designed for making interactive things. The syntax and libraries are a subset of Processing. One nice thing about choosing processing.js is that it is a subset of processing: if it turns out that its too slow, too buggy, or has some other issue, you can always run your program in regular processing (which is effectively Java).

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.

(the alternative was to try to make you implement things to run on a GameBoy - or at least in the emulator, but there's another whole set of issues with that)

We will provide you with some html/javascript that will make using processing.js easier. (coming soon!) You can also try writing things is regular processing first, trying to limit yourself to the parts that work in JS.

4.  Isn't this a bit much for 2 weeks?

Look at the processing.js flocking demo. It doesn't meet all the requirements (it doesn't let the user influence the flock, other than just adding more boids) - but its 350 lines, of which 120+ of it is a a vector math library. And if you want, you can use this as a starting point if you want (please be sure to give proper attribution).

And also, part of the challenge here is to see what you can do given the constraints of time. We understand that what you produce in 2 weeks won't be as much as you can do in 4 or 6.

5.  How do I learn more about flocking?

My notes for the flocking discussion are here. At the bottom, there are some links to some web pages with far more information that I could possibly list.

A different variant of this assignment was given in 2008. You can see what the students did here. There are some creative ideas mixed in. In this assignment, students generally worked in C++, and were asked to understand/evaluate the performance and scalability tradeoffs. That project was described here. Your assignment is different.

6.  But what grade am I going to get?

Students (justifyably) complain that I don't give clear metrics on how things will be assessed and evaluated. I am doing it again. It's the most common thing on the course evaluations.

You'll get an A if...

• you do everything required (meet all the deadlines, fullfill the minimum requirements, turn in a writeup)
• give evidence that you did some experimenting
• get along with your partner

The bar is slightly low (IMHO), but I hope you'll want to thoroughly exceed it not because of the grade motivation, but because you're having fun and learning.

7.  Discussion

I will try to use the collaboration site as a way to hold an online discussion about the project. Post questions, answers, ideas, etc. as comments on this page

8.  Turning things in

To turn the project in, place all your files in the directory assigned to you. You should check to make sure that things actually run in a web browser.

If your handin directory is:

    /p/graphics/public/html/Courses/Games10/proj1/FOLDERNAME

this will be available on the web as:

    http://www.cs.wisc.edu/graphics/Courses/Games10/proj1/FOLDERNAME

(remember to replace FOLDERNAME with the appropriate name)

Your handin should contain (at least):

1. all the code to run your demo (s) - if there are multiple versions (for example to show off different things), turn them all in
2. an "index.html" page - that describes the project, and runs some version. if we go to the web address some flocking should be seen. you may not want to put all the documentation on this page (or have all the examples running), but you should have links from this page to everything
3. documentation. explain what your program does, what extensions to flocking you've tried, what kinds of behaviors you create, what implementation tricks did you use to make it go fast, etc. is there any coolness that we cannot see? (or may not be obvious)
4. a discussion of the game aspect: as described above, you can make your demo into a game (be sure to explain how to play), but you must (at least) give a description of what kind of game you might have made with it (if you had more than 2 weeks for the project)
5. some performance analysis. how many boids can you simulate before your frame rate dies? where are the bottlenecks? what might you do to make it scale better? what might you do to make it perform better (aside from switching to a more modern web browser or faster computer)
6. some discussion of the experimentation you did to obtain various behaviors.

Basically, we will go to your web directory

    http://www.cs.wisc.edu/graphics/Courses/Games10/proj1/FOLDERNAME

and expect to be greeted by an index page. We'll look around at everything it points towards. We'll read everything that it tells us about. We'll look at all the demos that you link too. But we won't go digging around to find it - everything needs to be linked.

If you want to do your writing in something other than HTML, like Word or LaTeX, create a PDF and link to that - we will only look at stuff that we can see in the web browser.

We will ask you to make 2 postings on the "collaboration site" - one in which you'll describe what you did, and a second in which you'll talk about a design to turn it into a game. We've asked you to add this information(or information similar to it) in the files you'll hand in, rather than on the collaboration site.

We may provide additional details on expectations, based on questions we get from students. So check back here.

8.1  When is it really do?

The official due date is Monday, Feb 8th, at noon. At this time, we will check to see if everyone has something turned in (including an index page with a demo on it). We may even provide some initial feedback.

We will begin evaluating projects on Friday morning, Feb 12th. If something isn't turned in by then, we won't look at it. In fact, we will probably lock the directories so you can't change it. You may only turn in things after this time if you get specific permission from the instructor.

A note on lateness: in reality, providing you have at least something turned in by the Monday deadline, you have a free extension until Friday. We gave the extension to provide time for meeting the documentation requirements, but you may continue to fix your program up to Friday morning. Providing that you meet the minimum requirements on Monday, there is no penalty for updating your work up to the Friday deadline. If you ask for an extension beyond Friday, there will be a penalty (to be negotiated).