Deliverable: Controller Layer 1

The second major module of the Capture the Flag system is the CTF Controller. A Controller connects to a Simulator for the purpose of controlling one team's players via accelerate and spin commands.

I have provided a version of most of Layer 1, which is available in subversion at svn://tera.engr.mun.ca/7893-f2009/share/ (use your normal 7893 subversion login to access this; you have read-only access). You may use any part of this as you see fit.

A controller should be split into two layers, aptly named Layer 1 and Layer 2. The exact division between layers must be decided by each team within certain constraints:

Each team must decide exactly what functionality will be considered high-level or low-level, but I suggest the following general principles:

Stated another way, your Layer 1 should support reusability (each team member shouldn't need to "re-invent the wheel"), and your Layer 2 strategies should be cohesive.

At the final competition, there will be an incentive to have the best controller on your team, but there will be an equally strong incentive to have the overall winner come from your team (even if it isn't you). This will reward work on both Layer 1 and Layer 2.

Design Requirements

For the first Controller increment, you are required to design and implement Layer 1 of the controller, including the API that Layer 2 will use to interface with it. This API should be written in CTF terms (e.g. players, trees, positions) and not STEAL terms (e.g. getState, and Point := (Float,Float)).

The Layer 1 API should, at minimum, allow a "stub" Layer 2 to:

Testing Requirements

Controllers are not like simulators: there are many valid Controller responses to STEAL inputs. Thus, official testing will be very limited.

Teams are not required to design and produce system-level tests for controllers, though the internal use of unit- and system-level testing is encouraged. I recommend testing your controllers to ensure that they can evade capture, capture evasive enemies, and perform any other functionality exposed in your Layer 1 API.

Submission Process

A particular revision of your whole repository will be "tagged" (See Creating Tags in the SVN Book) with the name cntrl_incr_1_submit and this will be taken to be the submitted files. You may choose a revision yourselves and add the tag before 0900 on the due date. If the appropriate tag is not added by the due date, the revision in the repository at 0900 on the due date will be tagged and used.