Running a race backwards

04 Sep 2013

How do you (reasonably fairly) handicap a race without information about the competitors' abilities?

The idea of handicaps is a pretty simple one: it’s used in golf, chess, tennis and horse racing. It relies on participants' performance data being available, and being trusted: if I’m expected to go round the course in three shots fewer than you, I’ll start with a three shot penalty, and then we’re equally likely to win.

I recently held a running race for a group of friends, ranging from experienced athletes to complete “noobies”. I’m no judge (my friends wouldn’t let me, anyway!), and given the company I keep, I couldn’t necessarily trust the competitors to be 100% honest if I simply asked them how fast they might expect to run. How to design something that would be competitive for everybody?

My solution, henceforth to be referred to as the “g10k system” has (arguably) the following properties:

  • No need for race organiser to have or to trust information about the participants.
  • Each runner starts with a pretty even chance that they might win.
  • Giving false information about your expected performance confers little or no advantage.
  • The fastest runner won’t automatically win. In other words, absolute speed is not enough (on its own) to win.
  • Participants are motivated to run as fast as they can.
  • There is the prospect of an exciting finish with a number of participants hitting the finish line close together.

Here are the rules:

The g10k system

  1. Each runner nominates a time they would personally be pleased to achieve.
  2. Runners leave the start line handicapped so that if they all ran their nominated time, they’d all finish simultaneously.
  3. Winner is the first person to cross the finish line who doesn’t beat their nominated time.
  4. No “goalhanging”. Timing your own run or using GPS or something is not allowed.

The inaugural g10k event was held this weekend; it was a great success. Including a bit of “fudging” to correct a couple of complexities:

  • 4 out of 7 participants ran faster than their nominated pace, 3 ran slower.
  • The mean difference between expected runtime and actual runtime was only 7 seconds (root mean square was 2 min 28 sec or about 6%)
  • Absolute average speeds varied by a factor of 2.27 across the field.
  • The absolute fastest runner won - but he might not have done if his nearest challenger hadn’t got lost a bit en route.

I would’ve loved to have joined in, but injury prevented me, so I had fun building a one-page webapp to run the race.

Lessons learned for next time:

  • No reason it has to be a running race. Maybe g10kb will feature bike racing…
  • Add an “ETA” column to the race app for added spectator excitement
  • Signposting is hard, and runners can go wrong even if you think you’ve covered every base
  • Balloons burst on contact with barbed wire, and garden canes are pretty nasty when they snap in your hand.
  • Always arrange a bouncy castle. Thanks Rona and Jimmy!

Tags: game theory, girton, running, g10k

|