In the April 4 lab, you must demonstrate at least a minimal fire avoidance plan.

In this lab you will extend your battlebot program (or write a new one -- its up to you!) to make it smarter and better. We will again have a one-on-one contest, and 2 extra credit points will go to the winner, and 1 to the runner-up.

Your robot must:

• Still try to find and destroy the other battlebot.
• Remember obstacles and try to avoid them.
• Have some fire avoidance plan. In lab 8 you probably just headed right towards the other battlebot once you found it. The problem is that that one is probably heading towards you, too! Or, it may have found you and started firing even before you know it! In either case, you need to have some better plan which includes both avoiding taking hits and still trying to attack the other battlebot.

The game controller program has a few new features and fixes:

• Scanning now returns the closest object or battlebot that is in the scan window (it used to give priority to battlebots). This means that you can not scan battlebots behind objects anymore.
• The old scan window was too wide -- it is now a 10 degree arc. This, along with the first change, means it is harder to scan battlebots. The range is increased from 300 to 400 units (the entire playing field is 500 by 600 units).
• A new battlebot action is available, which is the single word "longscan". It is a long-range scan, and costs 5 fuel units. It is not very accurate, but it always detects the opposing battlebot (not any objects), it doesn't matter which way your battlebot is facing. All it returns is the quadrant that the opposing battlebot is in. The reply string is "2 <quadrant>", where quadrant is 1 for upper left, 2 for upper right, 3 for lower left, and 4 for lower right.
• Shots will not hit a battlebot behind an object anymore.
• If a shot hits the opposing battlebot, the second input line on the next turn will report a rough estimate of the total damage the opposing battlebot has sustained so far (not just of this shot). The estimate may be up to 25 percent off. This second line will be of the form "3 <damage>", where the damage is a positive integer. If a shot misses, the second input line on the next turn will still be "0 no scan".
• A maximum speed is enforced, of 15 units per turn.
• Colliding with an obstacle or wall costs 4 units of damage instead of just 1.
• I am pretty sure that the "damagetype" field in the first input line is now working. You should be able to tell when you are hit. (Lab 8 said that this field was unimplemented)

You should grab the new game controller.

For this lab, your program must be a C++ program. It must use classes and objects. For example, your bot itself could be defined with a class and it could be an object of that class. (even if it is just a global object variable -- in OO programs it is VERY common to have classes that will only have one object ever created -- these are called singleton classes). I'm sure there are other things your program is doing that might be potential classes/objects. Certainly obstacles is another example.

You can still use C-style I/O (e.g., printf, scanf, ...), or you can use C++ iostreams if you want (we haven't talked about them, but they're in the book).

Lab 8 might still be helpful for documentation.

Design quality, code quality, and documentation quality will, as always, play a part in your grade for this assignment.