Robolyst Robolyst
← All guides

How to read a new game manual

The game manual is not a book you read once. It is a reference you extract from, argue with, and re-read in February when a referee makes a call you did not expect. The teams that get the most out of kickoff weekend are not the ones who read fastest. They are the ones who know which parts to pull out first.

8 min read

Read it in the order that decides things

The manual is organised for completeness, not for a team trying to decide what to build. Read it in the order that produces decisions.

  1. The scoring section. Every scoring action and what it is worth. Nothing else matters until this is on paper.
  2. The match structure: how long each period lasts, what is legal when, and what carries over between periods.
  3. Penalties. Both what earns them and how much they cost. A game with expensive penalties is a different game.
  4. Robot rules: size, weight, legal parts, legal motors. These constrain everything you are about to sketch.
  5. The field drawings, with a tape measure in hand. Numbers on a page do not tell you how tight a gap is.
  6. Everything else, once, so you know what is in there and where to look for it later.

Build a scoring table before you build anything

The single most useful artefact of kickoff weekend is a table with one row per scoring action and four columns: what it is worth, roughly how long one takes, whether it can be repeated, and how hard it looks to build. Everything after that is arithmetic.

The point of the table is not precision. Your time estimates on day one will be wrong. The point is that it makes the comparison explicit. An action worth twelve points that takes twenty seconds loses to one worth five points that takes four seconds, and no amount of enthusiasm for the twelve-point mechanism changes that. Turning the game into a strategy is the next step, and it starts from this table.

The sections rookies skip and regret

  • Inspection rules. Read them in week one, not the night before your first event. Teams get told at inspection that a part is illegal and lose a match rebuilding.
  • The penalty list, in full. Most teams read the scoring section carefully and skim the penalties, then design a robot whose main strategy is a foul.
  • Game-specific definitions. The capitalised terms are defined precisely and the definitions are load-bearing. Arguments about "is this scored?" are almost always resolved in the definitions.
  • The autonomous rules. What sensing is allowed, what the starting configuration must be, and what happens if you break the line.
  • Field element tolerances. Elements are built to a tolerance, and a mechanism designed to the exact drawing sometimes does not fit the real field.

The Q&A is part of the manual

The official Q&A system publishes rulings that carry the same weight as the printed rule, and the manual gets versioned during the season. A team reading version one in March is playing a slightly different game from everyone else.

Give one person the job of checking the Q&A and the team updates weekly and reporting anything that changes what you are building. It takes ten minutes and it occasionally saves a subsystem.

Read it as a team, not as a captain

A manual read by one person and summarised to everyone else produces a team that cannot argue about strategy, because only one person has the evidence. Split the sections, have each group present what they found, and write the answers down where everyone can see them.

Disagreements at this stage are cheap and useful. The same disagreement in week six costs a subsystem.

What to leave kickoff weekend with

  • The scoring table, on paper or in a shared doc.
  • A realistic estimate of what a good match score looks like this season.
  • A list of what your robot will do, and the longer list of what it will not.
  • The constraints you have to design inside: size, weight, motor count.
  • A named person responsible for tracking manual updates and Q&A rulings.
  • The whole thing written down somewhere durable. Judges ask how you read the game, and the honest answer is much better told from notes than from memory. The documentation workspace exists for exactly this.

Related