1. Contest overview

In this programming contest, there is a game map with 2 players on it, each controlling some number of robots: 

XXXXXXXXXXXXXXXXXXXX
XX....XXX...XXX...XX
XX....XXX...XXX...XX
XX.>........XXX.<.XX
XX....XXX.........XX
XX....XXX...XXX...XX
XXX..XXXXXXXXXX..XXX
XXX..XXX....XXX.XXXX
XX...X........X...XX
XX................XX
XX...X........X...XX
XXXX.XXX....XXX..XXX
XXX..XXXXXXXXXX..XXX
XX...XXX...XXX....XX
XX.........XXX....XX
XX.>.XXX........<.XX
XX...XXX...XXX....XX
XX...XXX...XXX....XX
XXXXXXXXXXXXXXXXXXXX
Sample map with a total of 4 robots (2 per player). Top 2 players belong to one player, bottom two to the other.

The initial map consists of walls (marked with 'X'), and points (marked with '.'). As gameplay proceeds, it will also have empty tiles (marked with ' '). The goal is to collect more points than the opposing player.

To collect points, one must simply move their robot over a tile with a point on it. Up to here, the game is similar to a multiplayer version of Pacman. In addition, robots may destroy opposing (or even allied) robots with a laser.

2. Technical details

In each round of the contest, the following events take place:

  1. All robots over a point gain a point
  2. All robots move (rotate or forward)
  3. Lasers fire. All robots in the path-of-fire for a laser are destroyed simultaneously.

If a robot tries to move into a wall, into another robot, or two robots try to move into the same tile, no movement happens.

If a robot fires a laser, all robots in the line-of-fire of the laser are destroyed. The line-of-fire includes all squares in front of the robot up to the first wall (lasers do not pass through walls).

At the end of every round, all robots are given an updated version of the map. Each robot must respond with one of four commands:

Any other commands will be treated as 'X' (skip round).

2.1 Scheme libraries provided

To load the game framework:
(load "framework.scm")
To initialize a game:
(define game (mouser-init))
To deinitialize a game:
(deinit game)

3. Contest details

The contest will consist of double elimination.

Moves will be timestamped. A player who takes more than 1 second to process a move may be disqualified, at the discretion of the contest organizers (we will do this if a round is taking unreasonably long).

4. Team selection

Teams may be composed of 1-4 people, but we recommend selecting a team size of 2 or 3 people. You may select your own teammates. If you don't know people in the class (or for other reasons, cannot choose teammates), speak to us, and we will try to partner you with other people in the class.

5. Suggestions

Begin small, and develop the system further from a working prototype. Once that is working, add features. A suggested development strategy:

In other words, do not try to find a near-optimal global solution and implement it. Begin with a small, working system, and try to grow it into a more advanced system.

As you are building your system, try to learn to use the available on-line resources. In particular, the MIT/Scheme manual gives useful information on the libraries provided with Scheme. Making good use of these libraries will dramatically shorten development time. In addition, SICP, the 6.001 textbook, is also available on-line, and may be a useful reference.

6. Background information

Students at MIT hold a number of programming competitions. The most popular three are held during the Independent Activities Period in January:

All of these competitions are organized and run entirely by students. Students learn tremendous amounts by participating, and organizers learn a tremendous amount by developing the contests. In the case of 6.370, students only learn programming, but in 6.270, and especially MASLab, students from different disciplines will work together on teams, and will learn from each other across disciplines.

Mouser is designed as a small demonstration of this sort of programming competition.

The idea behind many of the details of the game came from a very similar one-day competition run by Trilogy (as a recruiting event).

At MIT, although the contest often have substantial prizes, they are at least as cooperative as they are competitive. Teams will generally try to help each other (e.g. in the case of bug in the contest, or otherwise). We would like to encourage teams here to also cooperate, share knowledge, and try to help each other succeed. While the direct goal of participating in the contest is to win, the overall goal is to learn, and to gain practice working on a substantial piece of code under deadline.

Downloads