The distribution is the same as that used for previous labs. For this lab, you will use a simple tracking agent as your adversary. You can use the sample agent in Python that has been provided at puppyguard.py (with no forward velocity) as your opponent.

This lab is designed to get you thinking about state-machine based agent design, as well as to get you thinking about strategies that may be useful in the tournament lab. This lab will also allow you to start using your search code to move your tank.

You will code up two cooperating agents which use internal states to win a simple scenario. In the BZFlag environment, agents often choose between attacking and defending. There is nothing stopping a defensive agent from “puppy-guarding” its flag: it just sits in front of it and fires while rotating to track agents which come near. Since attacking tanks cannot move sideways, a tank which wants to destroy at a puppy-guarding defensive agent must point at it to shoot at it and cannot sidestep to avoid reciprocal shots. Likewise, if an attacking tank is moving sideways to avoid fire, it cannot shoot at its attacker, since it is pointing in the wrong direction. In this lab, each team is given two tanks. The TA tanks are defenders. They are simple and dumb and simply sit in front of the goal, tracking the closest enemy tank while firing continually at it. Your tanks will be attackers.

To ensure that you are comfortable with applying searches, your home base will be buried within a simple maze. Your tanks will have to navigate through the maze and exit onto the empty half of the world where the TA base resides. You must then annihilate the TA tanks without any casualties of your own. The strategy you will employ is simple: one tank will be a decoy: it will drive back and forth in front of the enemy tanks, drawing their fire. Since the enemy agents always track the closest agent, they will ignore your other tank. That other tank will be a sniper, who will maneuver into some position and pick off the two defenders. Finally, you will retrieve the enemy flag and navigate it back to your home base. The enemy tanks will not resurrect for this lab, but both of your tanks must survive. To complete the lab, your attackers must retrieve the flag using state-based agent design. Your global state sequence may look something like the following:

State 1: Maneuver both tanks through the maze and to a safe position.

State 2: Assign one tank to be a DECOY, and one to be a SNIPER.

State 3: Move SNIPER into pre-position.

State 4: Move DECOY into pre-position.

State 5: Start DECOY maneuvering.

State 6: Move SNIPER into true position.

State 7: SNIPER snipes defending tanks.

State 8: Retrieve the flag.

State 9: Return the flag to home base.

While moving through the global states, the individual agents may be assigned to specific individual states. Some of these states may have sub-states within them. For example, your DECOY tank will be driving back and forth in front of the enemy agents. Two potential fields, combined with two states, might be appropriate to implement this behavior. The first state might be a “HEAD-NORTH” state; when active, an attractor could be placed somewhere on the north end of the world. Once close enough, the DECOY agent could transition to a second state, which could be a “HEAD-SOUTH” state. A different attractor could be activated to pull the tank south. You will need to develop a mechanism for tracking which state you are in, implementing the behavior defined by that state, and defining how and when to transition between states. Be creative.

Use the world called maze1.bzw, which is half maze and half empty. Make sure that your navigation techniques are general enough to deal with this (that means that you need to search to find the way through not just hard code your path).

To make TA (defenders) respawn slowly give the following flag to bzrflag:

--respawn-time=300

• Take things one step at a time. Navigating through the maze and dispensing with the enemy are mostly independent tasks. Either work your way through the maze and then start fighting the enemy, or else fight the enemy on empty world and then add maze searching.
• Printing pretty search lines will slow down searching. Once you have the search working, you may want to turn off the code to output the path data. In the future you will need to think about how often you want to search and at what granularity. This may also be one place to consider using a separate thread, but you can succeed and even win without it.
• In the world for this lab, you will need to deal with the buildings and navigating around them so you do not get stuck. Some kind of discretization code should help with some of this, but you might want to make a “plan B” in case you get stuck.
• You should not be using the occupancy grid for your search in this lab. The point of the occupancy grid in the search lab was so that everyone had the same graph to search, and we knew what the right answer was. It is not suitable for use for searching in a real-time capture the flag environment. You also do not have access to the whole occupancy grid in this lab. You should not be using the command –occgrid-width=800 or –occgrid-width=1600. You should probably not even be requesting the occupancy grid at all in this lab. If you already started using the occupancy grid, we will not take off points (only for this year, 2010 - next year change this sentence to “We will significantly mark down your grade for requesting the occupancy grid”). However, we very much recommend that you switch to something else for this lab if you can, and certainly for future labs, as searching the occupancy grid is really intractable in real time, and you cannot use –occgrid-width=1600 in any lab except the search lab.

To pass off this lab, you will:

• Submit all of your multiagent code electronically
• Turn in a detailed lab report
• Turn in a declaration of time spent by each lab partner
• Demonstrate to your code to one other team

Your report should discuss issues such as what states you used and how you transitioned from one to another, how you used potential fields, how you converted a search path into a sequence of acceleration instructions, what other CS 470 principles you applied, and what improvements you will make for the final project. Report also on your experience demonstrating your code to another team and your experiences watching other teams demonstrate their code to you. If you hand in your report, but later have a team demonstrate their code to you, please follow up with a short e-mail about what you saw. If we have an odd number of teams, the last (odd) team may request that another team exchange demonstrations. In return the the team that does the extra demonstration will get 5% extra credit on the lab write-up.

I would like to note that this business of demonstrating your code and watching other teams demonstrate their code is really not just a way to lighten the TA's load. In the past, teams have only seen the behavior of other teams' code in the tournament. Watching other teams is a way for you to get a feel for what other teams are capable of. Past classes have all asked that I force interaction before the tournament.

Your report will be graded out of 100 points. We expect that a good length for the report is 2-4 pages. Shorter than 2 full pages is very likely inadequate (and 2 pages very likely is too), and longer than 4 pages is likely too wordy, unless you have a lot of pictures that take up most of the pages (having lots of pictures doesn't hurt anything).

The points will be allocated as follows:

• 18 points for your description of the finite state machine that controls your tanks. A diagram is nice, but by no means necessary (you can get full points on this without pictures).
• 18 points for your description of how you used potential fields. Again, plots or diagrams are nice, but not necessary. If you didn't use potential fields at all, that's ok too, as long as you describe why not and what you did instead.
• 18 points for your description of how you built and searched your graph. This is where we expect that pictures would be most helpful.
• 18 points for describing how you moved along the search path you found. This is (potentially) different from the potential fields section (pardon the pun…), because potential fields can be used for other things, like staying away from obstacles and enemy tanks while moving along a path.
• 18 points for your description of future improvements that you will make for the final lab. Potential improvements related to the work of this lab are most helpful, but you needn't limit your discussion to those only.
• 10 points for describing your experience demonstrating your code to another team. Remember that you should report both on what you learned from showing your bots to them and on what you learned from them showing their bots to you.

All of the “descriptions” mentioned above should be detailed if you want full credit for the section. You don't need to take a page for each section, but a couple of sentences is too short. Also, the lab description says that you should mention other CS 470 principles you used in your lab. That section is not necessary in your paper, as you might not have used any other principles from class, but its presence cannot hurt you and may mitigate deficiencies in other areas.

This should be a professional-looking report. Section headings are a very good thing. An introduction and conclusion are also very good things. If your paper looks sloppy, don't expect a good grade. If you want an A you need to find something interesting to say; getting an A is about excellent work, not just jumping through a hoop. If you send in a short, unformatted e-mail that only barely covers the items I explicitly required (described above), you should expect a C.

Thanks to Chris Monson, Andrew McNabb, David Wingate and Kirt Lillywhite