Transcript
Six tracks, no map
Six bobsleigh tracks are hiding in 2,907 bytes.
Winterberg. St Moritz. Konigssee. Innsbruck. Calgary. Breuil Cervinia.
Six start ramps. Six finishes. Every bend between them. Less data than many modern image thumbnails.
But open those bytes and there is no map.
No latitude. No longitude. Not even a list of points.
Instead, each tiny instruction says something like this:
Turn a little.
Drop a little.
Put something beside the ice.
Then it says it again. And again. Nine hundred and sixty-three times.
From those instructions, using a small table of sines and cosines, a complete track plan appears.
So what, exactly, did this game save?
This is Slidensa — stories of ice, gravity and speed.
Before the bytes
In 1987, Digital Integration published Bobsleigh for the ZX Spectrum, Commodore 64 and Amstrad CPC.
This was an oddly ambitious choice.
Bobsleigh is easy to recognise on television and difficult to understand from outside the sled. The machine vanishes into an ice channel. The camera cuts to another bend. Four helmets pass in less than a second. A clock supplies the drama, but most of the driving is almost invisible.
That is not an obvious foundation for a home-computer game.
A football game can show a ball, a pitch and two goals. A driving game can put a road in front of a car. Bobsleigh has a crew who push for a few seconds, then disappear into a machine whose most important movements are small adjustments inside a white trough.
Digital Integration was unusually well placed to attempt it.
The company had been established in 1982 by David Marshall and Rod Swift. Marshall had studied systems engineering and worked on flight-control systems for the Ministry of Defence. The company’s early identity grew around simulation: aircraft, helicopters and motorcycles translated into the limits of British home computers.
Its slogan was “advancing the art of simulation.”
By the time Bobsleigh appeared, Digital Integration had already published Fighter Pilot, Tomahawk and TT Racer. These games did not merely borrow a machine as scenery. They tried to model enough of its behaviour to make the player operate it.
A bobsleigh was a natural continuation of that idea and a sharp turn away from the company’s usual machines. No wings. No engine. No throttle. Gravity did most of the obvious work.
The player still needed decisions.
The answer was to model the whole team rather than only the minute spent on the ice.
Before a race, the game asks the player to choose between two-man and four-man bobs, buy equipment, fit one of four runner sets, read the weather, train the crew and manage a bank balance. Better machines cost more. Crashes create repair bills. Results bring sponsorship money. Spend too freely or damage too much equipment and the season can end in bankruptcy.
At the start, the player pumps the controls to push the bob. Then comes the moment of boarding. Left and right guide the machine. The brake must wait until after the finish. Use it on the course and the run is disqualified.
The game can be a single event, a season or, if the team becomes good enough, an Olympic campaign at Calgary.
That last venue was not accidental.
The Calgary Winter Olympics were approaching in February 1988. A British game released late in 1987 could put its player on the Olympic track before the opening ceremony.
But Digital Integration first had to answer a more awkward question.
How do you simulate a sport nobody in the development room has actually done?
The programmer and the pilot
The authorship of Bobsleigh is less tidy than the data inside it.
The modern World of Spectrum archive names Richard Hughes as the author of the Spectrum game. That attribution is supported by the strongest contemporary evidence: Hughes wrote a first-person account of the development for Your Sinclair, explaining the problem, the tools and several of the solutions.
But CRASH magazine’s review in December 1987 printed a different credit. It named Digital Integration’s founders, David Marshall and Rod Swift, as the authors.
The shipped Spectrum tape does not settle the argument. It identifies Digital Integration, but it does not contain a staff roll. The original source labels and development files have not survived in the recovered material.
The responsible version is therefore slightly untidy: Richard Hughes is the best-supported named programmer and the person who described making the game, while Marshall, Swift and the wider Digital Integration team may also have had design, production or technical roles that the surviving credits do not separate cleanly.
Hughes began his account with the problem of speed.
The game had to look realistic enough to deserve the word simulation, but it also had to move fast enough to suggest a sled travelling down hard ice at more than ninety miles an hour.
Digital Integration’s team had no first-hand experience to rely on. Hughes wrote plainly that none of them had been down a bobsleigh run.
So they asked people who had.
The British Bobsleigh Association assisted the project. The team met Britain’s leading driver, Nick Phipps, on a cold January morning in London and questioned him about driving technique.
Phipps had already represented Great Britain at the 1980 Winter Olympics. In December 1985, he and brakeman Alan Cearns won at Cortina d’Ampezzo and set a track record.
Phipps reduced driving to a sentence: “Hold the sled down, check the height, and let it run out in the middle.”
It sounds simple in the way expert advice often sounds simple. Every phrase assumes a body of knowledge.
Holding the sled down means controlling how high it climbs on the wall. Checking the height means reading the machine’s position in the curve. Letting it run out means knowing when correction costs more speed than it saves.
Those ideas became game rules: speed pushes the bob across the trough; steering changes its lateral motion; wall contact costs speed; leaving a bend too high can cause a bounce or a crash.
The surviving instructions also thank Alan Cearns. Promotional text attributes comments to both athletes: Phipps praised the steering and concentration the simulation demanded; Cearns singled out the start and the events surrounding the race. Digital Integration thanked the British Bobsleigh Association, and both men, for assistance and advice.
That appears to be another first worth preserving carefully. Among the earlier bobsleigh games found in this research, none documents development review by a real driver. Digital Integration’s is the earliest documented example we have of a bobsleigh videogame being reviewed and advised by elite competitors—one of them the pilot, the other his brakeman.
We cannot prove that no forgotten programmer asked an athlete before 1987. But here the consultation is not speculation or an advertising resemblance. Hughes described the meeting, the instructions thanked the participants, and the athletes commented on the finished simulation.
This does not make the game a scientific training simulator. It makes its design process legible. The programmers began with expert descriptions of what a driver notices and turned those descriptions into variables a small computer could update.
Phipps’s connection supplied something else as well: a human line from the game to Calgary.
He went to the 1988 Winter Olympics as Britain’s flag bearer. He did not race there, but his presence made the game’s Olympic ending feel less like generic marketing. The consultant whose advice shaped the simulation was part of the actual British team walking into the Games.
Building the simulation
Hughes described simulation software as three problems: the visual display, the instrument panel and the mathematical model.
Bobsleigh had a fourth. The planning and strategy around the race took, he said, as much design and coding time as the simulator itself.
That claim is easy to believe after opening the game.
Almost everything outside a run happens on one blue page. Magenta windows open over it for events, venues, weather, runners, equipment, fitness, team colours, controls, saving and loading. A second window can open over the first.
Redrawing the whole page every time would have been slow. Instead, the game copies away the part of the screen beneath a new window. When the window closes, it restores the saved rectangle. The parameters sit on the computer’s stack, so the last window opened is the first one removed.
It is the familiar logic of overlapping desktop windows, compressed into a Spectrum game menu.
The race view needed a different compromise. Hughes wrote that the display combined simple line drawing with solid fills. The track edges could be drawn quickly; the sky could be filled; the bob could remain large and readable at the bottom of the screen. The most time-critical code was not the physics. It was filling the solid-colour sky quickly enough.
The model beneath that view accounted for the fitted runner blades and changed the sled’s grip according to the weather. This is why the apparently fussy equipment menu matters. Choose runners badly suited to the day’s air and ice, and the game’s steering strength falls.
Development did not happen by typing assembly directly into the Spectrum. Hughes described an IBM AT fitted with a Z80 coprocessor card, a relocating macro assembler and linker, a full-screen editor, and an in-house monitor-disassembler. New builds travelled to the target computer through a serial connection running at 38 kilobaud, or through a parallel loader.
The target was still the Spectrum. The larger development machine simply made the cycle of writing, transferring and debugging less punishing.
Sound revealed another split between machines.
Digital Integration licensed “Pop Looks Bach,” Sam Fonteyn’s theme associated with the BBC programme Ski Sunday. It was skiing rather than bobsleigh, but the tune immediately placed a British listener in televised winter sport.
On a 48K Spectrum, the game plays the melody through the one-bit beeper. On a 128K Spectrum, the AY sound chip turns it into a multi-channel arrangement. The game itself otherwise remains a 48K program. The extra memory is not used; only the sound path changes.
That is a telling allocation of effort. The cassette, code sheet, menus and mathematics had to establish credibility. A familiar television tune supplied the season before the first sled moved.
From cassette to Calgary
For the person who bought Bobsleigh, the simulation began before the menus.
The Spectrum edition arrived on cassette with a printed sheet of five hundred security answers. After the tape loaded, the game displayed a number between zero and five hundred. The player found that number on the sheet and typed the corresponding three-digit code. Three wrong answers ended the attempt.
The answer was not stored as a simple table inside the game. The program used the displayed number to seed its random-number routine, advanced it by a number-dependent amount, and calculated the answer. Running that original routine for every possible prompt confirms what the program expects.
It also discovered a wonderfully human defect in the paper system. The typed surviving code sheet agrees with the program on 499 of its 500 entries. At number 209, the sheet says 532. The game expects 542.
Once admitted, the player chose keyboard or joystick controls, then 48K or 128K sound. The Ski Sunday theme played over an empty results table until Enter was pressed.
Then the season began with twelve thousand pounds, no bob, one set of runners and a crew whose fitness was described as poor.
That is an unusually unheroic opening for an Olympic game. There is no champion waiting for the player. There is a small organisation that has to buy its first machine.
Four levels of bob are available: amateur, national, European and Olympic. Each can be configured for two or four people. Better equipment raises the speed ceiling, but the purchase price rises too. Runner sets wear out. Training costs money. Team kit costs money. Wall contacts produce repair charges. Prize and sponsorship income have to keep the project alive.
Weather is not flavour text. Air temperature and ice condition determine which runner set the game recommends. The ideal choice gives full steering strength. Every step away from it removes a quarter of that authority. A player who ignores the weather can begin the run with only one quarter of the best steering response.
A season moves through the venues in a fixed order: Breuil, Calgary, Innsbruck, Konigssee, St Moritz and Winterberg. Each event has two runs. The game generates seven rival nations, sorts their results with the player’s, and updates prize money, records, fitness, equipment wear and championship points.
The Olympics are not simply another item on the first menu. The event remains unavailable until the game selects the player. When it finally opens, Calgary becomes mandatory.
This structure explains why contemporary reviewers kept talking about the management game. The race may last a little over a minute. The consequences follow the player back to the bank, the workshop and the next venue.
The 2,907 track bytes sit inside that larger loop. They are not six isolated levels. They are the roads along which a team tries to become solvent, improve and qualify for the Games.
Three computers and a difficult scorecard
The original release reached the three major British eight-bit formats: Sinclair’s ZX Spectrum, the Commodore 64 and the Amstrad CPC.
Contemporary advertising named all three. The Spectrum edition sold for £9.95 on cassette. The Commodore 64 release was offered on cassette at the same price and on disk for £14.95. The Amstrad version also circulated on cassette and disk.
These were conversions of the same design, not one proven-identical program. They share the management structure, venues and behind-the-bob presentation, but their processors, graphics layouts and sound hardware differ. The 2,907-byte track figure comes specifically from the Spectrum version. It must not silently be assigned to the Commodore or Amstrad code without examining those versions separately.
The game also travelled through publishers. Byte Back later reissued it in Britain. Zafiro Software Division released Spanish material, including Amstrad cassette and disk editions recorded in 1988. Decades later, the Commodore 64 version appeared in the Antstream retro-game catalogue.
That is a respectable afterlife for a specialised sports simulation. It is not, however, a sales total.
No reliable figure for copies sold has surfaced in this research. Nor has an audited chart run that would let us turn availability into commercial rank. Three platforms, foreign distribution, budget reissues and modern streaming show that the game circulated. They do not prove that it was a major hit.
What survives much more clearly is the response from reviewers—and that response depends heavily on which machine they played.
The Spectrum version was received warmly.
CRASH awarded it 88 percent overall in December 1987. Its two reviewers gave individual judgements of 81 and 94 percent. One thought the racing itself was not frighteningly fast, but admired the difficulty of running a team without going bankrupt. The other argued that the shaky line graphics made the run feel more like televised bobsleigh and praised the mixture of skill and strategy.
The following February, Your Sinclair gave the game nine out of ten. Its component marks were eight for graphics and nine for playability, value and addictiveness.
Those reviews understood Digital Integration’s larger bet. The game was not only snow coming towards the player. It was the equipment choice before the run, the push at the start, the restraint needed in a bend, and the bank statement afterwards.
On the Commodore 64, the verdict was far less settled.
The contemporary-review index at Lemon64 records nine out of ten from Computer and Video Games, six from Commodore User and seven from Your Commodore. Zzap!64 gave it 58 percent and called it a missed opportunity for a spectacular sports simulation. The same index records two sharply different ACE assessments: 567 out of a thousand, followed later by 863.
The disagreement is more useful than an average. It tells us the idea was not automatically successful merely because the menus were deep or the subject was unusual. The race view had to create speed. The controls had to make small corrections meaningful. If a version missed that balance, the surrounding simulation could not rescue it for every reviewer.
Commercially, then, the honest conclusion is bounded.
Bobsleigh was a full-price, multi-platform release with international and budget editions. The Spectrum version won strong contemporary reviews. The Commodore version divided critics. Exact sales remain unknown.
Its most measurable success came later, in a form no 1987 review could score. The game survived: archived, replayable, and complete enough that its own code can still explain how it works.
Not the first bobsleigh game
Was this the first bobsleigh videogame?
No.
It was not even the first game devoted entirely to bobsleigh.
The earliest dedicated example found in this research appeared six years earlier. The December 1981 issue of the American computer magazine SoftSide published an Apple II game called Bobsledding.
The magazine called it a simulation. Its course was two miles long and randomly generated for every run. One paddle steered; another operated the brake. The screen reported speed, distance and elapsed time. There were nine difficulty levels, and the smallest deviation from the course destroyed the sled and ended the run.
That sounds simple beside Digital Integration’s game, but it is unmistakably a standalone computer simulation of bobsleigh. It was not one event in a general Olympic package. We can call it the earliest dedicated example this research located. We cannot safely call it the first ever; surviving software from this period is too unevenly documented for that absolute claim.
More examples followed. A 1983 book called 21 Games for the BBC Micro included Bobsleigh. It generated a winding course between fir trees and let the player choose five difficulty levels by changing the width of the track. The course moved toward a blue sled controlled with the arrow keys. Touch an edge and the run ended.
Also in 1983, archive records date a Commodore 64 game simply called Bobsled. They name K-Tek or K-Tel Software as its publisher and classify it as obstacle avoidance. Its programmer is unidentified, but packaging, a photographed manual and screenshots survive.
Those games settle the narrow historical question. Digital Integration did not make the first bobsleigh-only videogame.
Then came the game many players remember.
Epyx released Winter Games in 1985. Bobsled was one of seven events in the original Commodore 64 version, alongside ski jumping, biathlon, speed skating and three judged events. Up to eight people could choose nations and compete in a miniature international meeting. Its bobsled event put the player behind the sled on a twisting white course: steer left and right, touch the walls, lose speed, chase the clock.
It travelled much farther than one machine. Versions appeared across home computers and consoles, including the Apple II, Atari systems, Amiga, PC, NES, Master System and ZX Spectrum. Epyx’s present-day catalogue says the game sold more than 250,000 copies by 1989 and became its best-selling Commodore title. For many players, this—not Digital Integration’s later game—was their first electronic bobsleigh run.
Britain produced a direct competitor in the same year. Electric Dreams’ Winter Sports offered eight events on the Spectrum and Amstrad CPC. Its bobsled display split the screen: one view from above and behind the bob, and another showing the course. A contemporary review called bobsled the most interesting event in a package otherwise criticised for slow play.
By 1987, then, putting a bobsled on a screen was not new. Putting it inside a winter-sports compilation was not new. A rear view of an ice channel was not new. Epyx had already used what a contemporary review called a three-dimensional, Pole Position-style rear view. Electric Dreams had shown the bob from above and behind. Even a standalone bobsleigh title already existed.
Digital Integration did not invent the camera position. It developed the idea: a larger, more forceful racing view, a clearly readable bob in the foreground, and a projected channel that banks, rolls, undulates and shakes around it.
Digital Integration’s distinction was scope.
Its game did not treat bobsleigh as one short event between ski jumping and speed skating. It asked the player to run the team: buy the machine, choose runners for the weather, train the crew, absorb repair bills, survive a season, earn selection and then race. It connected one minute on the ice to everything required to reach the start line.
So was it the first true simulation?
The word true is too slippery, and the 1981 program already called itself a simulation. But this is the earliest game found in this research that tries to simulate bobsleigh as a complete organised sport and to represent a circuit of named real venues. Winterberg, St Moritz, Konigssee, Innsbruck, Calgary and Breuil Cervinia replace the random or generic runs of its predecessors. The driving is joined to equipment, money, training, a complete season and Olympic selection, with advice from leading British competitors.
That is the genuine first worth claiming: not the first electronic sled, but the earliest attempt we have found to turn the whole sport—and its real-world circuit—into a game.
And it had to fit that structure—code, pictures, sound, menus, championship, equipment, weather, competitors and six racing venues—inside a 48-kilobyte Spectrum.
That did not leave much room for geography. Yet Calgary had to feel different from St Moritz. Each course needed a beginning, a rhythm of bends, timing gates and a finish. The computer also had to draw the next piece quickly enough to race through it.
The six compact track streams reveal how Digital Integration did it.
Together, including the marker at the end of each stream, they occupy exactly 2,907 bytes.
Not approximately three kilobytes. Two thousand, nine hundred and seven.
The question is how those bytes become somewhere a sled can go.
Three bytes at a time
Each course is a chain of records. Every ordinary record is three bytes long.
The first byte changes the direction of the track.
The second changes its vertical coordinate.
The third is a group of switches. Those switches can mark a gate, capture a split time, draw a line across the ice or tell the renderer which wall should rise beside the sled.
That is the entire vocabulary.
There is no stored position. No x coordinate. No y coordinate. The next record does not say, “Go to this point.” It says, “From wherever you are now, turn by this much.”
The turns are small. The first byte is signed, so it can bend left or right. One step changes the heading by about seven-tenths of a degree. The largest change used by the six courses is four steps: about 2.8 degrees in one record.
A bend is therefore not stored as a named curve. It is a sequence. Ease into the turn. Hold it. Ease out again.
The height is relative too. Add this much to the vertical total, then add the next amount. The game keeps a running sum of what came before.
The beginning of Breuil Cervinia shows how much can hide inside that simple rule. Its first records contain no turn at all. The heading stays at zero while the vertical additions rise from zero through two, five, nine, fourteen, eighteen and twenty-one, then begin to fall again. The x position does not move. The forward position advances by the same amount each time.
In the data, it is a short column of small numbers.
In the race, it is the smooth drop from the start ramp.
The third byte adds events to the same sequence. One record draws a line across the track. Two records later, another marks the first timing gate. The first gate occurs at record seven on every one of the six courses. A shared piece of code recognises that event and starts the clock.
So even before the first bend, the three-byte language is doing several jobs at once. It defines the track’s direction and height, tells the renderer what belongs there, and gives the race logic somewhere to begin.
This is why 2,907 bytes can contain six courses. They do not describe the world. They describe how the world changes from one small slice to the next.
But relative instructions create a new problem.
If there are no map coordinates, how do you draw a map?
The trigonometric trick
Here is the trick.
Begin at zero, facing straight ahead.
Read the first byte and change the current heading. Take the sine of that heading to find how far to step sideways. Take its cosine to find how far to step forward. Add both steps to the point you already have.
Then read the next record and do it again.
One record gives one new point. A run of records becomes a line. And a line becomes a track plan—even though the stored data never contained an x or a y.
Written as an equation, this might look like a piece of school mathematics returning to ask whether you were paying attention. In motion, it is much more intuitive. Face north and walk forward. Turn slightly right and walk the same distance. Your eastward movement is the sine. Your northward movement is the cosine. Keep walking, and the route draws itself behind you.
The Spectrum does not do this with a modern floating-point maths library. The game stores one small table: 65 values covering a quarter of a sine wave. It folds every possible angle into that quarter and estimates the values between the entries. Cosine is the same table shifted by a quarter turn.
At a heading of zero, sine is zero, so the track does not move sideways. Cosine is almost one, so the next point goes straight ahead. Change the heading a little and a small sideways step appears. Keep changing it, record after record, and the straight becomes a curve.
The first bend at Breuil begins with the smallest possible heading change. In the game’s angle system, a full turn is 65,536 units. That first change adds 128: about seven-tenths of one degree.
The sine table has no entry for exactly 128, so the routine looks at the values on either side and takes the halfway point. After the game’s fixed-point division, the sideways step is only three units. The forward step remains 255.
The bend does not arrive as a corner. It begins as a sideways movement barely one percent as large as the forward movement. More records add more heading, and the curve slowly becomes visible.
That is a small technical detail with a large visual consequence. The stored numbers naturally produce an eased entrance instead of snapping the track from straight to turn.
This is our theory of how the stored bytes become a track plan—but it is not a guess imposed on the data. The original code reads each record, updates the heading, consults its sine table and accumulates the coordinates in exactly this sequence.
The theory was checked against all 963 ordinary track records. Each record was passed through the game’s own routines, and its heading, height, x and y were compared with the independently calculated result. All 963 matched.
The trick really does unfold those bytes into six drawable plans.
A map, but not the territory
The result needs the right name.
It is a faithful map of the geometry inside the game. It is not a survey of the real track.
The units are the game’s own, not metres. There is no recovered scale that turns one step into a measured distance in Austria or Canada. Several of the plans even cross the boundary of the Spectrum’s signed number range. Plot the stored numbers carelessly and the line appears to leap across the page. The decoder has to unwrap those values before drawing them.
More importantly, the courses are far gentler than the places named on the menu.
The old Innsbruck course and the current Igls track in Slidensa both contain fourteen bends. But the old data turns through 153 degrees in total. The current track model turns through 1,146 degrees—about seven and a half times as much.
Breuil Cervinia is even easier to picture. Across its whole stored course, its heading never moves more than 22 and a half degrees away from the direction it had at the start. On paper it is a long, gentle wave, not a sequence of Alpine hairpins.
Even the map shown inside the original game’s menus quietly admits the problem. It reads the same track records, but multiplies every heading change by eight. The outline wriggles dramatically across the screen. Its corner numbers are placed by hand. The stated length is text.
The menu map is not lying. It is doing the job of a map on an eight-bit racing game: giving the player a memorable preview.
The recovered plan does a different job. It shows the exact reference path the racing code produces from the stored bytes.
Neither one is the real track.
And yet, while playing, the course does not feel like a nearly straight line.
That is because most of the track is not in the map.
Storing the feeling
The geometry supplies the rhythm. The rest of the game supplies the sensation.
The view rolls hard in a bend. It does not simply follow the stored track. An accumulator makes the roll build as the curve continues and fade after the curve ends. Where the bob sits across the trough changes how strongly the whole picture leans.
The bob swings from side to side. Speed pushes it outward. Steering and the simulated bank pull it back. Touch a wall and the bob is thrown toward the middle at half its sideways speed.
The dangerous moment is the exit. Leave a bend while the view is still rolled too far and the bob can bounce or crash. So a curve has a readable shape: set it up, hold it, then bring the machine down before the straight.
The camera shows only a short distance ahead. Gates grow towards the player. Lines pass beneath the runners. The picture shakes more as the speed rises. The crew changes pose. Spray appears at a wall contact. A thump makes the collision physical.
Seven gate events are encoded in every course. The first starts the clock. The last stops it. Other feature bits capture split times and change the walls.
This is what the 2,907-byte figure leaves out. It counts the course streams, not the code that interprets them. The track is completed by rules shared between all six venues: trigonometry, projection, camera roll, lateral motion, sound and the player’s own anticipation.
The data does not need to contain the finished experience. It only needs to contain enough difference for the rest of the system to produce one.
That is the deeper economy of the design.
What Slidensa inherited
When Slidensa began looking back at this game, the obvious temptation was to recover everything and then build a larger version of it.
More memory. More geometry. More physics. A real track, at real scale, with a sled that responds to the shape of the ice.
All of that matters. But it does not automatically preserve what made the old game legible.
A geometrically accurate track can feel flatter on screen than a crude one. If the camera follows the bank perfectly, the player may barely see the bank. If the view extends too far, speed loses its force. If the sled sits calmly in the middle of a physically correct channel, a fourteen-bend run can feel less alive than a line assembled from three-byte records.
So the old game became more than a reference. It became an argument.
Slidensa kept a version of its classic composition: the track moves and rolls behind the bob while the vehicle remains clear in the foreground. The modern track uses its real bends, but the camera still has to communicate what those bends feel like. The view rolls with the sled’s position. It shakes with speed. Repeated structures and wall markings pass close enough to make motion visible.
The old model is not copied. Its priorities are.
That is the inspiring part of the design.
A limitation made the designers decide what a track actually was. They could not keep every measurement, so they kept change: left and right, rise and fall, gate and wall, entry and exit. Then they built sensation around those relationships.
There is something generous in that idea. The code does not merely expose an old compromise. It gives the compromise back as a usable thought: begin with what the player must understand, find the smallest language that can express it, and let the rest of the design amplify the result.
Decades later, with vastly more memory available, that decision is still useful. It asks a hard question of every new detail: does this help the player read the run, or is it merely accurate?
Old technology is often described as something modern work escapes. Here it does the opposite. A 48-kilobyte machine offers a design lesson to a game that could store millions of times more.
Not because small is automatically better.
Because constraint made the idea visible.
The line appears
Return to the 2,907 bytes.
Read one record. Change the heading. Use sine to step sideways and cosine to step forward. Add the height. Remember the flags.
Read the next one.
The numbers accumulate. A straight begins to bend. Gates appear along it. The line grows across the page until six tracks have emerged from data that never stored a map.
They are not miniature surveys of Winterberg or Calgary. They are smaller and stranger than that: six arguments about what must remain when a place becomes a game.
A good model does not store the world.
It stores the smallest set of relationships from which the world can be felt.
The track plans, sources and a transcript are at slidensa.com.
Slidensa is an independent game about bobsleigh, luge and skeleton.
