What a 1979 camel game taught us about building Preracer

In 1979, a text game called Camel gave players a simple job: cross a desert without running out of water, exhausting your camel or getting caught by your pursuers.

There were no animations and barely any interface. You made a choice, the game changed a few numbers, and the next problem appeared.

A few years earlier, The Oregon Trail had done something similar with food, health, supplies and the many ways a journey west could go wrong.

When we started building Preracer, those old games suddenly felt relevant. A Garmin watch has far more computing power than the machines they ran on, but as a place to build a game it brings back some of the same constraints: a tiny screen, limited memory, simple controls and very little room for visual spectacle.

If you can't fill the screen with graphics and animation, the game has to become interesting somewhere else.

Make the numbers depend on each other

The interesting thing about Camel wasn't that it tracked thirst. It was that thirst competed with everything else.

Push harder and you make progress, but tire your camel. Stop to recover and your pursuers get closer. Drink now and you have less water for later.

That same tension sits underneath Preracer.

You manage four resources: sugar, water, legs and morale. They represent different parts of a race, but they aren't four separate health bars. Decisions that protect one resource can hurt another.

Morale is where we deliberately went a step further.

When morale gets low, the other resources start draining faster. And as things deteriorate, morale itself becomes harder to hold onto. A bad race can therefore become a downward spiral rather than four independent numbers slowly reaching zero.

That felt much closer to racing.

Uncertainty makes the same race different

Knowing the system shouldn't mean knowing exactly what will happen.

The Oregon Trail became memorable partly because a sensible plan could still be interrupted by illness, weather or a broken wagon. The route stayed broadly the same; the story of getting through it didn't.

Preracer uses the same principle.

During a race, events are drawn from different pools. Events can also vary in severity, so the same type of setback might be a minor nuisance in one run and a serious problem in another. The game also avoids serving the same event over and over again.

So you can replay the same course with the same basic strategy and still have to adapt.

That's important because Preracer isn't trying to create hundreds of different races through content alone. Much of the replayability comes from the interaction between your decisions and what happens along the way.

Losing should tell you what happened

Old resource-management games also understood something useful about failure.

Running out of food feels different from drowning while crossing a river. A broken axle tells a different story from disease.

Preracer follows the same idea.

You can bonk. You can run out of water. Your legs can give up. Your morale can collapse. Or you can simply fail to make the cutoff.

During balancing, we explicitly look for situations where one of those becomes the dominant way to lose. If nearly every failed run ends for the same reason, the other resources aren't really doing their job.

A DNF should feel like the consequence of your race, not just a generic game-over screen.

The text is part of the game

This may be the part where Camel feels most familiar.

Its output wasn't written like a spreadsheet reporting changing variables. It had a voice.

Push the camel hard and the game announces: “YOUR CAMEL IS BURNING ACROSS THE DESERT SANDS.”

Give it a night's rest and: “YOUR CAMEL THANKS YOU!”

Even the instructions send you off with: “GOOD LUCK AND GOOD CAMELING!”

None of those lines are necessary to make the underlying system work. But they're a large part of why a handful of variables starts to feel like a journey through a desert rather than arithmetic.

That's something we want in Preracer too.

The scenarios aren't only there to change your stats. They give the race its character. And the short lines that accompany them — “Over the top on willpower alone,” “Your legs are having second thoughts” — are meant to sound like racing rather than software.

Some of them only really work if you've been there.

Old problem, new course

A Garmin watch obviously isn't a 1970s computer. But building a game for one brings back a surprisingly familiar design problem: there isn't much space, input is limited, and you can't rely on spectacle to carry the experience.

We didn't expect a game from 1979 to be much use when designing for a Garmin watch, but strip away decades of hardware and the same problem is still there.

You have a small screen, a handful of resources and a player repeatedly asking: what do I do next?

The rest has to come from what happens around that choice — the trade-offs, the bad luck, the unexpected scenarios and the few lines of text that make a bunch of numbers feel like a race.