Turning a game into a strategy

The only unit that matters is points per second

A match is a fixed amount of time. Every scoring action costs some of it. So the question is never "how many points is this worth?", it is "how many points per second of match time does this earn, including the travel to and from it?".

Take your scoring table and add one column: estimated seconds for one complete cycle, from picking up to scored and back in position. Divide. The ranking that falls out is usually not the ranking your team assumed, and it is usually not the ranking of raw point values.

Density beats totals

Two robots can score the same total in wildly different ways: one does a single high-value action four times, the other does six different things once each. The first is almost always the better robot.

A robot that does one thing on a tight cycle is simpler to build, faster to fix, easier to drive and dramatically easier to practise with. A robot that does everything spends the match transitioning between mechanisms and the season debugging them. Pick the shortest, most repeatable loop the game offers and get very good at it.

Deciding what not to build

The most valuable output of strategy week is the list of things you are deliberately conceding. Write it down and put it on the wall, because in week five somebody will propose building one of them.

Three filters kill most candidate mechanisms:

• It scores badly per second. Concede it and let a partner do it.
• It only pays off in the last twenty seconds. Endgame actions are worth a lot precisely because they only happen once. Check the per-match value, not the per-action value.
• It cannot be finished two weeks before your first event. An unfinished mechanism is worth zero points and costs the time of a finished one.

Model a match before you design a robot

Write down what a strong alliance score looks like this season, then write down where your half of it comes from. This is arithmetic, not aspiration: cycles per match times points per cycle, plus autonomous, plus endgame.

The model does two things. It tells you whether the mechanism you are excited about actually moves the number, and it gives you a target to test against in week seven: "we planned twelve cycles and we are getting seven" is a much better problem statement than "the intake feels slow".

You are half of an alliance

Every match is two robots on your side. That changes the calculation: a robot that is excellent at one thing and useless at another is a good alliance member, as long as the thing it is excellent at is not the thing every other robot is also excellent at.

Look at what the rest of the field will build (it is usually the obvious high-value action) and ask whether being the third-best at that is worth more than being the best at something less crowded. This is also what makes you a desirable pick. Alliance selection rewards robots that complete somebody else, and OPR is how the teams doing the picking will see you.

Revisit it after the first event, not before

A strategy is a hypothesis. Your first competition tests it against robots you did not design against, and the results are the best information you will get all season: what the top teams actually did, what your cycle time really is under pressure, and which of your concessions turned out to be expensive.

Change the strategy then, with data, rather than in week three because a video from another region looked impressive.

Write the reasoning down, not just the decision

"We chose to concede the high goal" is a decision. "We chose to concede the high goal because our cycle estimate was 18 seconds against 6 for the low goal, and a 22-point difference does not cover it" is evidence, which is exactly what judges are reading for in the engineering portfolio, and what the Think and Design awards are decided on.

It costs nothing extra to record the reasoning at the moment you have it. It is nearly impossible to reconstruct in February.