FIRST, Game Theory, and a few things to keep in mind this season

[Eric Finn]

A few days ago on our team's groups, a team member posted the following. I felt that it would be nice to post it for other teams to read and think about the suggestions.
I will add some footnotes for things specific to our team, or just something people might wonder about, so you can know what he's talking about.
The places in the message where a footnote should be referenced are denoted by a number in parenthesis.

It's very long, but it's worth it.

Happy New Year's from Rob Harris! As I mentioned before to
many of you, I had planned to write up some kind of relatively
lengthy post on general game theory/strategy over vacation, and this
is it. The team members that I have discussed the topic with on
occasion over the past few months have given me great feedback and
several real-life ideas/examples, so I really believe that I've got
something valuable to share.

Over the two years that I've been on the team, I've been
rather critical of specific elements of our designs and general team
mindset. I like many of the changes that the team has decided upon
for this season, as they follow several trends that I believe are
important. What I'd like to do here is explain the reasoning behind
these opinions in hopes that my unusual viewpoint can contribute to
the team's success this season. I have 3 points that I wish to touch
on, and to do them justice, this post will be a little long, but
worth the read.

Point 1: Cost Calculation

I'll start by presenting two simple, competing ideas in game
theory, commonly known in the poker world as "loose" and "tight"
play. In "loose" play, a player assumes the best possible scenario,
and builds their strategy upon that, whereas in "tight" play, a
player assumes the worst possible scenario, and builds upon that.
You'll often hear a close game referred to as a "tight" game because
both players play very, very cautiously, and take very few risks.
There is a positive stigma attached to "tight" play, while the
term "loose" play is associated with sloppy play. Why is this? It's
because "tight" play proves to be the better of the two options in
most game situations. If you go all in on a pair of 2s on the
assumption that your opponent must be bluffing, you win less often
than if you wait for a better hand to bet wildly on.

There are flaws in the above example. The big one is that I
have presented two extreme cases and compared just those. Playing a
game so "tight" that you take no risks will never win you anything.
The point that I'm trying to make is that there is ridiculous risk
in assuming that whatever we decide our robot needs to do, we'll
find a way to make it work.

When I discussed these ideas with Mrs. Finn, she gave me a
perfect, real world example. When a customer comes to BAE(1), asking
for just about any project, that customer will initially ask for
very optimistic specifications. Rather than just accept the project
as is and get to work, BAE will look at these specifications,
consider the budget, time, and other constraints, and go back to the
customer with a counter-proposal that, while less impressive, BAE is
sure to be able to meet.

There has consistently been a disconnect in the design
process. We make our decision on what the robot will do, then just
pass it off to Mechanical and Pro-E to make [it] happen. A huge step is
missing here. We never step back, and ask ourselves what it will
actually take for the idea we decide upon to be effective when we
actually compete. In other words, we skip any kind of organized cost-
benefit analysis; we don't heavily question what the cost of putting
a robot component is, before or after we place it on the field. By
cost, I don't mean so much the price in dollars because we're
generally very good about keeping within budget; rather, I mean the
restrictions that such a grabber puts on the rest of the design in
weight and spatial requirements, the restrictions it involves on the
play field, and, depending on the particular robot component, the
time it will take to make it work as well as it needs to.

BAE plays "tight" when they make their counter-proposal.
They are careful to make sure that they can achieve their goal
because future contracts depend on it. If they don't meet their
deadlines or submit a poor final product, it hurts their reputation
Our FIRST team often plays "loose" by not bothering with a true,
organized counter-proposal. Rather than future contracts, our
success in competition depends on meeting our goals. We're not
perfect, and this is the way to account for that. The two ideas that
I have been most critical of, the original OTIS grabberand the
decision to be a shooting robot lat year(2), both became less
attractive when the full costs were realized. Hindsight is always
20/20, but I feel as though the problems that arose may well have
been prevented had we truly calculated the costs, either by being
less ambitious (OTIS grabber) or better allocating our time
(shooting robot).

Point 2: Consistency

How do you win a tournament? Simple: you build for
consistency rather than raw "scoring power".

I have never worked pit crew, because I enjoy scouting in
the stands, and take it really seriously, to the point where I will
look at my notes and try to call the match one way or another before
it begins. I'm far from perfect, but I tend to have a good idea of
how the match will play out, because I know what each robot usually
does. That's the key: what a robot usually does doesn't change all
that much.

Yes, sometimes a robot will get lucky, or sometimes the one
that scores consistently will fall over halfway through the match,
but do you really want to count on getting lucky every match? Over 9
qualifying matches, good luck and bad luck often average out to
nothing. To be successful, you need to be consistent, even if you're
just consistently average.

Look at last year's Granite State Regional. The top seed,
Nashua High School, built a side-scoring robot that was impossible
to line up during manual control, yet, they would always be able to
score 2-4 balls during autonomous. Thus, they would usually win
autonomous and be worth 15 points to their alliance per match. 15
points isn't very much when you consider how many points a good
shooter could get if it did well, but the important thing is that
Nashua did it CONSISTENTLY.

They definitely got a little luck along the way – 3 points
alone wasn't always enough to win autonomous, so they probably
didn't get paired against many good shooters unless they had good
shooters on their side too. Yet, if you were to run 10 tournaments
with the same robots that came to GSR, Nashua would have probably
done well enough to at least be picked every single time if it
wasn't actually doing the picking, because they would still
consistently do well in most matchups.

This needs to be the key when we design our robot this year.
Whatever we need to do, we need to do it nearly every match. Whether
most of our scoring comes in autonomous or manual, it needs to be
foolproof enough under real circumstances that it will CONSISTENTLY
happen.

Point 3: What it Means to be a Veteran Team

This point is shorter than the other two, as I would just
like to point out a mindset that we get too wrapped up in.

Last year, part of our justification for being a shooting
robot was that we were a "veteran team". There were other reasons,
and I'm not trying to dispute whether being a shooting robot was
possible or not. I'm just trying to point out that this particular
justification does not make sense so that we won't use it at all
this year.

The fact that we are a veteran team does not obligate us to
try the hardest possible challenge that the game offers, nor does it
obligate us not to choose an easier challenge either. The fact that
we are a veteran team only means that we have more knowledge about
how to solve the various problems that FIRST presents us. It DOES
NOT obligate us to actually solve the hardest problems if it would
mean playing "loose".

What should actually determine the direction our robot takes
is the cost-benefit analysis we do on the different ways to solve
the problem. If the option that offers the most benefits has costs
that we may have difficulty meeting, it MIGHT NOT actually be the
best option. Whether we were a shooting robot or not should have
been decided purely on weighing the cost of being a shooting robot
versus the benefits. The fact that we were a veteran team should
never have been considered evidence for one side or another.

Being a veteran team has given us skills and experience that
some teams lack, but we need to remember that, rather than compare
ourselves to others, we should be focusing on our own strengths and
weaknesses. What is the best course of action for one veteran team
isn't necessarily the best course action for us, because we are
different than them. Analyzing the costs and benefits, and then
playing "tight" when we make our choice by making sure can the
design everything it will take to finish it, will give us the best
result.

If we follow through on the 3 points I have outlined above,
I have every confidence in our team. If [we] make our decisions by
accounting for all costs, keying in on the benefits of a consistent
design, and without allowing our veteran status to get to our heads,
we can do great things.

I look forward to this season.
Robert Harris

1: BAE (British Aerospace) Systems, our team's main sponsor. A large number of our mentors work at BAE Systems.

2: OTIS (Outside The Internal Structure), our team's robot for Triple Play. It had an elevator-like arm for lifting tetras.
Our robot for Aim High, Scorpio (named for its shooter, which looked similar to a scorpion's tail), was a shooting robot before we took the shooter off and decided to just gather and score in the side goals.


If anything needs more clarification, just PM me or post a reply here.