Re: Tag-playing strategies [was: Re: Preparation for Proposal?]

[Tim Vanderhoek <vanderh@ecf.utoronto.ca>]

On Sat, Nov 20, 1999 at 03:00:05PM -0500, Tim Vanderhoek wrote:
> On Sat, Nov 20, 1999 at 02:24:37PM -0500, Cindy Wong wrote:
> >
> > About the strategy for defending...If our robot is smart enough to hide
> > behind something, by all means, do not move.  Assuming that we will be

Okay, proposed defensive tactics and strategy,

1) Do not move for period of time.

2) In all cases, wait for enemy to enter sensor range.

3) When enemy appears in sensor range, determine what direction the
   enemy is travelling in:
   a) if the enemy has superior sensors, assume the enemy is heading
      directly towards us.
   b) if the enemy has inferior sensors, observe the enemy and try to
      intuit his direction.  Chances are we won't get it quite right,
      but a guess is better than an incorrect assumption...

4) Choose a direction to run away in.  We do not run in the opposite
   direction of the enemy.  We choose a direction ~20degrees from the
   opposite direction of the enemy and run that way.  This is because
   super-sensor 4-person robots will possibly take advantage of us if we
   go in a direction exactly opposite the direction they are approaching
   from.  They may try to maneuver us into a corner.

5) Run.

6) If we run into a barricade, we shall not use our standard algorithm
   of trying to get around the barricade (see message describing
   offensive tactics).  If we strike a barricade head-on in a direct
   collision, we shall turn 90degrees and continue travelling.  If
   we strike a barricade at 45degrees or less, we shall essentially
   bounce-off the barricade (where the computer determines what angle
   it needs to bounce at based on which side-sensors were triggered).
   If we strike at an angle between 45degrees and 90degrees, we
   shall become very confused and switch into attack mode.  This is
   undesirable and must not be allowed to happen.

   We do this both for the case where the enemy was still in
   beacon-sensor range at the time of our collision with the barricade
   and for the case where the enemy was no longer in beacon-sensor range
   at the time of our collision with the barricade.

   It will be necessary to back-up a short distance so that the robot
   can turn correctly.

   (rationale)
   Although in some instances, taking time to find a way past an
   opposing barricade would be worthwhile, I believe it is overall a
   bad idea.  If we always try to find our way past barricades, we
   shall ultimately end-up at the edge of the playing field.  This is
   disadvantageous since turning 90degrees in either direction will
   lead to a corner.  Although the suggested tactic still has the
   same potential problem (getting cornered), it will not occur as
   quickly and we will be left with a little more freedom when choosing
   directions to run in.  Not only that, but finding ways past opposing
   barricades would have cost us muchos time and the enemy would
   catch-up with us while we find our way past.  It could be useful
   to find our way past a barricade and then try to hide behind it
   or go around it in circles.  I've shied away from this due to the
   complexity (and since it's probably a bad tactic if we're fighting
   a super-sensor 4-person robot), but it's definately a wish-list
   feature...


I don't know if these strategies are sufficiently simple for Malone.
He will undoubtedly question us on how we intend to determine what
angle we struck a barricade at, or question us on how we will tell the
robot to drive at a certain angle.  For the former we have a pretty
good answer.  For the latter, we have a semi-decent answer, but some
of the interface details should maybe still be worked-out.

Some of the ideas I'm considering are a little tricky to get right when
programming in assembly.  As I mentioned before, it'll be important that
we meet before Christmas break to discuss all of the "wish-list" items.
Discussing "wish-list" items goes double for tag-playing strategies
(NOTE that, for example, the addition of sensors to detect barriers
would result in a large change of our tag-playing strategies).  If
considerations aren't made for changes in the initial code, they become
really really hard to change later (for anything other than a quick hack
change that doesn't really work very well).

Any comments or suggested changes on this strategy?  I think this is
more-or-less reasonable.


-- 
Signature withheld by request of author.