This write up is intended to give a general overview of both the strategy I had in developing my bot, and also the strategy (or lack of one) my bot uses.

I’ve put the source code up on DropBox. It’s become a mess over its short lifetime. =) If you do anything cool with it, be sure to let me know.

Strategy

Coercion is one of those domains where I find that trying to find a strategy is somewhat difficult. Instead of building a strategy for it, I wanted the bot’s behavior to be as emergent as possible. Each turn my bot generates a list of tasks that it might want to consider. Each pusher then selects from that list, attempting to maximize an estimated value with respect to the cost of that action (measured in relative time to task completion.)

scoreOfAction = optionValue/optionCost;

The greatest of these scores is the action which the bot performs. This is done in a greedy manner, and I’ve structured my code as follows:

1. Read in pre-game input
2. Calculate static game attributes
3. For each turn:
   1. Read in input
   2. Calculate dynamic game attributes
   3. Consider all possible “candidate moves” for each pusher.
      • Select the one with the best estimated value.
   4. Actuate each pusher’s selected move

The specific calculations are probably the strangest, and I don’t talk about them in detail, but here’s the list of what is being calculated:

Static Calculations

• Region Sizes
• Region Centers
• Edge Centers
• Region Slopes
• Postability of Vertices (We can’t place a marker on a vertex that only touches very steep regions [Unless we get very very lucky!])

Dynamic Calculations

• Marker Locations (What regions are they touching?)
• Marker/Region Pressure
• Marker Post Values (For “posted” markers, how helpful or hurtful is it for us to leave the marker there.)
• Estimated Placement Values
  • Each Target (see Candidate Moves) has a value associated with having a particularly colored marker touching it.
  • This value is negative for blue markers, positive for red markers, and can be positive or negative for grays, depending on the target’s regions’ colors.
  • The magnitude of the value is exponentially greatest when the region is most easily captured.

Candidate Moves

Every turn we need to make a decision as to what to do. As my code ended up, every turn each pusher redecided from scratch. In reality, this is the area that could be most easily expanded upon, but I only ended up having 3 different types of actions. In my code (and in this write up) I refer to a list of “Targets.” The set of Targets are:

• Every Region
• Every Vertex that is postable, and is not on one of the four map boundaries
• Every Edge that is not on one of the four map boundaries

Each target represents a possible location that a marker can be moved to.

Option 1: Place a Marker

Every turn my bot considers every possible pairing of Markers and Targets that satisfy the following:

• The Marker isn’t Blue (My opponent’s)
• The Target contains at least one region (or is a region) of the color of the marker

If the pairing satisfies the above, then the value and cost is calculated simply as:

optionValue = Target.placementValue[Marker.Color]-Marker.postScore;
if(Target.postedMarker != Marker) { optionValue -= Target.placementValue[Target.postedMarker.Color]; }

optionCost = euclideanDistance(Marker,Target)+euclideanDistance (Pusher,Marker)/2;

Notice that this allows for gray markers to be placed on a region. In this manner, my bot will actively and aggressively place gray markers to “capture” blue territory in the name of gray.

Option 2: Capture a Marker

Every turn I consider every Gray and  Blue Marker that is touching at least one region that satisfies either:

• The region is not red; or
• The region might soon stop being red

The value and cost associated with capturing that marker is:

optionValue = MarkerValue(ourCount) – Marker.postScore;
if(Marker.Color == Blue){ optionValue += MarkerValue(theirCount); }

optionCost = euclideanDistance(Marker, Home)+euclideanDistance (Pusher,Marker)/2;

The function “MarkerValue(x) ” calculates the the value of having a marker, provided we already have “x” markers. The more markers we have, the less helpful it is to have more. I use an exponential function for this. The function also gives a bonus value if it’s earlier in the game. This bonus additive and linear, equaling “900-turnNum” (Turns range from 1 to 900).

Option 3: Displace a Marker

This was an amusing addition to watch. Consider every marker that is presently posted:

optionValue = -1*Marker.postScore;

optionCost = euclideanDistance(Pusher,Marker)/2;

Actuating a Move

Great, now what? For most of the  actuation I used a modified version of what was included in the Migrate example, I just made the nudges a little more violent, depending on distances to the target, and what was being done. For those readers not familiar with the sample code, it works as follows:

MoveTo(Pusher, Destination)

This was included in the sample bot. Our goal here is pretty straightforward. We have a pusher (which is probably already moving) and a destination we would like it to reach. In an ideal world we’d be moving at maximum velocity directly toward the destination. However if we simply try to apply a maximal force vector to the bot in the direction of the destination, then we’ll merely end up homing in on the destination, slowly converging towards it. It would be nice if we could get there a little more precisely.

MoveTo first applies force to cancel out any of the component of the Pusher’s current velocity that is perpendicular to the “ideal” motion. If the force applied to the perpendicular component is less than the maximum force we’re allowed to apply, then it constructs another vector pointing in the “ideal” direction with magnitude equal to the remaining allowed force and vector sums the two together.

MoveAround(Pusher, Marker, Destination)

This code first calculates if we are already “behind” the Marker. It determines this by looking at the normalized vector from the Marker to the Pusher (The vector pointing from the marker to the pusher, but scaled down to have a length of one), and the normalized vector from the Marker to the Destination. The dot product of these two vectors will range from -1 to 1, where 1 means the pusher is on the same side of the Marker as the Destination is, and -1 means that the Marker is directly in between the Pusher and the Destination. The default is that the pusher is “behind” the marker if the dot product is less than -.8. I changed this to -.9 in my bot.

If the pusher is behind the marker, then MoveAround immediately returns true. Otherwise it returns false after selecting an alternate destination next to the marker that will help it get closer to the other side, and calling: MoveTo(Pusher, AlternateDestination);

Place a Marker

To place a marker we need to first get behind the marker, and then ram into the marker repeatedly in order to knock it to where we want it. We can now easily accomplish this using the above methods as follows:

if( MoveAround(Pusher, Marker, Target) ) { MoveTo(Pusher, Marker); }

Capture a Marker

This is exactly like placing a marker, except that we’re placing it on our home region. So it is as follows:

if( MoveAround(Pusher, Marker, Home) ){ MoveTo(Pusher, Marker) ; }

Displace a Marker

All we want to do is remove the marker from its lofty perch. So we want to hit it as hard as we can:

MoveTo(Pusher,Marker);

Pathing

As amusing as it is to watch the cute little pushers carefully place a marker, then plow right through it to get to their next destination, it’s not so helpful in a practical sense. My bot paths around markers that are in its way, in an “approximately correct” manner.

I modified the MoveTo code to first consider every marker that could be in a pusher’s way, choosing the closest of these. I consider that a marker could be in a pusher’s way if the Dot Product of the normal vectors MarkerToPusher and MarkerToDestination is less than .1 . If the closest such marker is less than 10 units away, then perform an analogous calculation to the MoveAround method, and move to a location nearby the offending marker first.

Now, this isn’t perfect, and often pushers will “nick” markers as they go around, however this is uncommon and even when it happens it’s rarely an issue. Also if you watch carefully, you’ll notice that the pushers will occasionally veer  slightly off-track to “graze” tangentially along a nearby marker. While this is definitely not optimal, the lost time here is very insignificant, and the overall behavior seems to be very good.

What I didn’t do, but would’ve if I had more time

Target pruning! This is a big one! In the specifications it mentions that the number of markers and regions could be as large as 200 each! My bot would almost certainly time out under such conditions. The change needed here is, during static calculation, only create a target list as large as some formula that takes into account the number of markers. I wouldn’t want to decrease the number of markers considered, however it’s really not necessary to consider every region as a target for placement.

Saving Markers. The code is in there to consider “Saving” a marker if it’s close to being captured as a possible action, but it caused some erroneous behavior when pushing a marker temporarily over neutral territory (the pusher would suddenly consider it at risk of being captured) So some added check would be necessary to make it work well.

Placing markers in areas not partially controlled by me. A couple of bots employed this behavior (notably Coke Chan did so aggressively) and it’s something I wanted to do myself. However I never got around to figuring out a good value/cost heuristic for these cases. (Obviously it’s less valuable than the apparent value, as you’re risking a marker.)

Pusher-Task selection priorities. Atm, if Pusher 1 is performing task A, and Pusher 2 is performing task B, and Pusher 1 completes task A, it will likely consider task B to be very necessary and kick Pusher 2 off of its task. This often causes my bot to have some weird behavior that may be hard to explain without this knowledge. Basically, Pusher 1 shouldn’t have unconditional preemptive power over the other Pushers as it presently stands.

Conclusions

That’s pretty much it. No doubt I’ve hand waved some details, but I think most of them could be worked out / reversed engineered from the source code (should one be so brave.)  Hopefully at least some people got something from reading this, and many thanks again to everyone in the competition! I know at least I learned a lot, and I hope to see some of you in future competitions. =)