600.392: Senior Design Project

Spring Semester 2006: January 30, 2006 - May 5, 2006

The XP Spike

The XP Spike is a relatively small project in which you get to try out the XP practices and learn more about the dynamics of your team. Let me strongly encourage you to apply XP practices right away to see how they work for you. Try test-driven development! Try pair-programming! Set up automated builds and tests to constantly integrate your system! In short: Try it all! :-) Well, you'll have a hard time trying the planning game with no client, but I guess you could "imagine" the priorities I give below as an approximation of those.

Dinner with Ambients

The project is based on the ICFP 2004 Programming Contest. The complete project as used in the contest is specified here. Note that you are not actually doing the task that participants in the contest were required to do: You are not handing in "sophisticated ant brains"! Instead you're handing in only the simulator that can be used to pit different "tribes" of ants against each other.

Priorities

Instead of actual user stories covering little pieces of functionality for the simulator, I'll define your project in terms of three different priorities. Priority One is worth more than Priority Two which is worth more than Priority Three. I hope that's clear?

Priority One:

Develop just the simulator following all the specifications for ant brains and maps from the official project!
You must support output of simulation traces in "dump" format (defined here) so we can check correctness.

Priority Two:

You should support visualization of some kind so you can "watch" the ants roam around; ideally this should be graphical.
You should use object-oriented concepts in your code (i.e. separate classes for ants, cells of the map, etc.) to modularize your simulator.
You should document your code reasonably well, ideally using a tool like Doxygen.

Priority Three:

It would be nice if your simulator were fast enough to actually run complete 100.000 round tournaments in a few minutes; it might be a good idea to allow visualization to be switched off for this.
You are free to add any extra features you want. Personally I'd like a distributed version and a nice "ant debugger" but that's just me. This won't influence your grade at all.

Hints

The project is not very complex, but it can be a little confusing at first. Be sure to read the specification at least twice.
Try to make the high-priority items work first. It's better to hand in something that works for Priority One only than to hand in something that attempts all three but doesn't really work.
Try to establish a fixed schedule for meetings during the week, a schedule that most of you can stick to.

Deliverables

Please turn in a gzip compressed tarball of your project. The tarball should contain no derived files whatsoever (i.e. no .class files, no .html files, etc.), but allow building all derived files. We expect to build your project using make or another commonly used build tool; your project must build and run on ugradx.cs.jhu.edu. Include a README file that briefly explains how your project works and contains any additional notes you want us to check out before grading. Send the tarball to cs392-submit@bloat.org as an email attachment.

Grading

Your project will be graded on the following criteria (the weights are rough ballpark figures):

Functionality (50%): Does the simulator work correctly for our test cases?
Testing (20%): Do you have sensible unit and system tests in place?
Design (10%): Is your design sufficiently modular and extensible?
Style (10%): Is your coding style readable and consistent?
Packaging (10%): Is you distribution (a) in the correct format, (b) organized well, (c) easy to build?