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 via email. 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:
- Both layers must be substantial: they must both add value to the controller
- Layer 1 will handle STEAL processing (both directions)
- Layer 2 will provide high-level control
- Layer 1 will be a team effort
- Layer 2 will be an individual effort
Each team must decide exactly what functionality will be considered high-level or low-level, but I suggest the following general principles:
- Layer 1 contains that functionality that every strategy is likely to use
- Layer 2 contains individual strategy, which isn't common to all
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.
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:
- choose a team colour from the six allowed by STEAL (done)
- select a flag location at the beginning of every round (done)
- move a player to a particular point on the field (done)
- attempt to capture a visible Attacking enemy with a particular Defending player (not done)
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.
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.