Week 01 · lesson

Map a Fair Competition

You do not need a commercial game to test whether a competition system works. In fact, a paper map, card challenge, or logic task is better for this lesson. It removes the excuse that the game itself is doing all the work. The system is still there: objective, entry conditions, time, result record, and a route for disagreements.

If those pieces are unclear, a more expensive game client will not rescue the event. It will just make the argument look more technical.

Receive: The Minimum Working Event

Every credible event needs five plain answers. Not a fifty-page rulebook. Not a logo. Five answers that participants can find before the first round begins.

QuestionWhy it existsWeak answerUsable answer
What is the objective?Participants need a shared win condition“Do your best”“Earn the most points in three rounds”
Who may participate?Entry needs consistent boundaries“People who show up”“Registered class teams of three or four”
How is time handled?Equal conditions need a clock“We will know”“Ten minutes; timer starts after instructions”
Who records the result?Memory is not a record“The winners tell us”“One scorekeeper uses the result sheet”
What happens in a dispute?Arguments need an owner“The teacher decides”“Teams show the score sheet to the named official”

Notice that none of these answers asks which game is most popular. That is intentional. A competition system has to work before a particular game becomes relevant. The activity may be a map objective, a card sort, a strategy puzzle, or a physical challenge. The organizer still has to explain what counts, who enters, and what evidence settles a close result.

A Short Flow Model

Use this model to check whether your event has a traceable path from published rules to a recorded decision:

Concept flow

Minimum event system flow

A classroom challenge still needs the same backbone as a larger event: rules, play, record, review, and communication.

  1. Read rulesParticipants see the objective, entry rule, timing, and dispute path before play starts.
    then
  2. Complete challengeTeams act under the same conditions and clock.
    document
  3. Record resultA scorekeeper captures outcome evidence instead of relying on memory.
    if needed
  4. Review evidenceThe official checks the record against the published rule.
    resolve
  5. Communicate rulingThe event owner shares the result and keeps the record consistent.

The model is deliberately simple. A system should be simple enough to trace. The details belong in the rules and result record, not in a maze of arrows that nobody can explain after the event begins.

Process: Predict the Failure Before It Happens

Your class plans a ten-minute challenge in which teams move markers across a printed map. The draft rules say only this:

“First team to finish wins. Work with your group. Mr. N will handle issues.”

Predict two disagreements that could happen. Here are common ones:

  • Two teams interpret “finish” differently.
  • A player arrives late and wants to join a full group.
  • Two groups both claim they completed the objective first.
  • A team says the timer started before it heard the instructions.
  • A scorekeeper misreads a point value.

The goal is not to be suspicious of students. The goal is to stop relying on mind-reading. A clear system helps honest participants as much as it helps an organizer.

For each disagreement you predict, write the missing rule or missing record. For example:

Possible failureMissing system pieceRepair
Two teams claim first completionNo recorded finishing orderScorekeeper writes the time beside each team name
A late student wants to joinNo entry deadlineTeams are final at the two-minute check-in
“Finish” is unclearNo measurable objectiveA team finishes when all four markers reach labeled zones

This is the same logic used in larger events. The scale changes. The need for a clear process does not.

Practice: Repair an Incomplete Event Draft

Use the draft below.

Teams will compete in a fast strategy challenge. Winners get a point. Mr. N will handle issues.

Repair it without turning it into legal language. Add these four lines:

  1. A measurable win condition.
  2. A time limit and start procedure.
  3. A result-recording method.
  4. An escalation sentence that names the evidence and first owner.

Here is a model for the last line:

If teams disagree about a score, they show the marked result sheet to the event official before leaving the table.

That sentence is useful because it says what happens, what evidence matters, and who acts. “Tell someone” is not a process. It is a vague hope that a person appears with the right authority.

Apply: Create an Event System Card

In a group, create a one-page event system card for a ten-minute classroom challenge. Your challenge can use a printed map, cards, a logic puzzle, or another accessible activity. No account or game client is required.

Your card must include:

Required itemWhat a strong version does
ObjectiveStates the precise condition that earns a win or point
EligibilityStates team size, registration, or a clear participation rule
TimingStates when the activity starts and ends
Result recordNames the sheet, form, or scorekeeper that documents the outcome
Integrity ruleStates one behavior that would make the comparison unfair
Dispute pathNames the evidence, official, and response route

Assign group roles before you write. One person is a participant, one is a scorekeeper, one is an official, and one is an observer. If your group has fewer people, combine roles but name the combination. Read the event card from each role’s point of view.

The participant should know how to enter and win. The scorekeeper should know what to write down. The official should know what evidence to inspect. The observer should be able to tell whether the rules are actually being followed. If one role cannot answer its question, revise the card before you run anything.

Correct: Stress-Test the System

Trade event cards with another group. Their job is not to praise the design. Their job is to create realistic pressure.

They must ask these questions:

  1. What would count as a win in a close result?
  2. What evidence settles that result?
  3. Who has authority if the teams disagree?
  4. What happens if a participant does not meet the entry condition?
  5. Can the event actually run in the time the card promises?

Write one revision note using this sentence frame:

We changed ___ because the stress test showed ___.

Do not defend a weak line because your group knows what it meant. The system has to work for people who do not have access to your brain. This is the part people skip and then debug for an hour.

Prove: Submit the Design Evidence

Submit three items to your instructor:

  1. The completed event system card.
  2. The stress-test questions or notes from the reviewing group.
  3. One revision note explaining what changed and why.

Your evidence does not need to show a perfect event. It needs to show that your group could identify a weak point, inspect feedback, and improve one controlled part of the system.

Misconception Check

Rules do not make an event unfriendly. Hidden or inconsistent rules do. A clear system gives everyone the same starting point, protects students from avoidable arguments, and lets the actual strategy challenge matter. That is not bureaucracy for its own sake. It is how you build something people can trust.