Chapter 8: The Clone, The Flan, and The Forest

Nodes of Yesod was flying off the shelves. Crash had given us a Smash in Issue 19, 93%, with the animation called “superb.” The atmosphere at Odin shifted from survival to expansion overnight. We had a hit engine. We had a talented team. And we had Paul McKenna at the helm, an entrepreneur who had seen exactly this moment coming.

“What if we changed the graphics,” Paul said, “changed the music, and came up with new room layouts?”

Arc of Yesod.

In modern terms, it was a “reskin.” We took the Nodes engine, kept Astro Charlie, and replaced everything else. We redid the map, tweaked the premise, and released it as a budget title on the “Thor” label. It was a purely opportunistic move to leverage the investment we had made in the code.

But there was a catch.

Although we were now safe in the arms of our BBC Micro disk system, the editor we used to build the game rooms was a relic from the dark ages. The source code for the room editor had been on one of those cursed Microdrives that crashed early in development. The source was gone. All we had left was a single binary executable of the tool.

We were building a commercial sequel using a “black box” editor that we could not fix, could not modify, and could not recompile. If that binary stopped working, the game was dead. Every time we loaded it up, we held our breath. It held together, just.

Andy Walker did the sound on Arc. It was his first music for Odin. He’d inherited the C64 music tools Fred Gray had used for Nodes, and I remember him toiling away to get the SID-chip version of the Arc music to play (he composed the music on the Spectrum and then ported it to the C64 and Fred’s player). Arc was also the first game to ship with the new two-voice player we’d been building for Robin (more on that shortly).

Despite its derivative nature, the game performed well. The press recognized it for what it was. Crash magazine noted it was “more of the same,” but still quality. It sold solidly as a budget release. It kept the lights on and the cash flow moving. No Crash Smash this time, though, understandably given the budget release.

Next came the hardware distractions.

The manufacturers of the Elan Enterprise computer approached us with a proposition. They wanted a version of Nodes of Yesod for their new machine. The Enterprise was being touted as the “next big thing,” a machine that would crush the Spectrum and the Commodore 64. It had been delayed so many times and undergone so many name changes (at one point it was called the “Flan”) that it was already becoming a myth.

But they had money (or so it seemed), and they had hardware. They boasted about a 256-color mode that would blow the competition away.

I took the job. I’d actually seen the Enterprise once before, on Software Projects time, though nothing had come of it. This time, I sat down with the documentation and one of the loaner systems. It did not take long to find the cracks in the facade. Yes, it had a 256-color mode, but the resolution was so low you only got about 80 pixels across the screen. It was useless for a detailed platformer.

However, the video hardware was flexible. Very flexible. I realized that by manipulating the start memory addresses of the scanlines and tweaking the color attributes, I could force the Enterprise to mimic the layout of a Sinclair Spectrum screen almost perfectly. On paper.

In practice, the screen stayed dark. The code looked right, the documentation said it should work, and nothing was happening. I took it to George Barnes. We sat with my code and the Enterprise manuals; everything still checked out. Then George had one of his hunches. The documentation didn’t say this, he said, but maybe we needed to write to that port during the vertical blanking interval. I tried it, and it worked! The Nodes of Yesod menu screen appeared, in all its glory. George also worked out how to load our code straight from the BBC into the Enterprise over a serial cable using only system commands (no custom downloader); that part was just plumbing, but it saved us hours.

So much for the next generation. I spent two weeks turning their “beast” of a machine into a Spectrum emulator.

It was a clean clone. I ported the code, the graphics, and the gameplay directly. I suspect the Enterprise executives were disappointed that I hadn’t utilized their fancy hardware to its full potential, but I am fairly certain they never sold enough units for it to matter. I distinctly remember them asking for the development kits back the moment the port was finished. By 1986, the Enterprise was history.

While the Arc and Enterprise side-quests played out, our real project had been in preproduction since Nodes shipped: Robin of the Wood.

This was our sophomore album. The pressure was on to prove that Nodes wasn’t a fluke. I was the lead programmer on the Spectrum version, while Marc Wilding (then Marc Dawson) took the lead on the Commodore 64. Paul Salmon was the lead artist and main designer.

Rest in peace, Paul.

Paul had a vision that was wildly ambitious. “I want a location-based 3D view,” he said: each location rendered in 3D from whichever direction you entered it.

Paul was completely fascinated by Robin Hood lore and other parallel British mythology. You can see it in the characters you meet in the game. I remember one Friday, Paul gave me a lift to Manchester in his car, and he listened keenly as I talked about growing up near the River Loxley, walking through Loxley Woods, and crossing Little John’s Bridge as a kid. There is some debate about whether the Loxley area in Sheffield is the Loxley (or Locksley as it is rendered) of the myth, but if you are from Sheffield, like me, then you just know it is. My stories paled against the mountain of research Paul had already done, but perhaps they added something to the lore. They gave me a connection to the game.

We spent weeks trying to bridge the gap between Paul’s 3D vision and the limitations of the hardware. We prototyped frantically to try and nail the direction. Paul churned out endless digital mockups using Melbourne Draw. We even sat around tables with paper and card cutouts, moving physical assets around like generals planning a war.

But I just couldn’t get my head around it. The pragmatic engineer in me couldn’t see how to make it actually work as a game. In the end, reality won out. We retreated to the familiar 2D “room” approach that had worked for Nodes, but we scaled it up significantly. Where Nodes had been 256 rooms, we pushed Robin to 320. That number was deliberate: a room count of 256 fit in a single byte, but 320 did not, which made the addressing meaningfully harder. We did it anyway.

To manage this sprawling forest, I had to build a custom tool for Paul. The obvious shortcut would have been to extend the Nodes room editor, but with the source code long gone to the previously mentioned Microdrive incident, that wasn’t an option. I wrote a new “room” editor that ran directly on the Spectrum, allowing Paul to place trees, hedges, and enemies visually. Unlike the perilous tape loops of the past, this editor saved the level data reliably to a disk drive attached to the machine. Memory is hazy on which one, but probably a Beta Disk or an Opus Discovery. It gave Paul the freedom to iterate, tweaking the flow of the forest without fear of losing his work. If I recall correctly, the editor shell ran in BASIC (menu and file system access), with the heavy lifting done in Z80 assembly.

The Commodore 64 version benefited from this, too. Marc took the Spectrum level data and translated it across for the C64, where the different screen resolution and “fat pixels” meant the map wasn’t a 1:1 fit. He remixed the forest to fit the Commodore screen while keeping Paul’s design intact.

But under the hood, I decided to change everything.

For Nodes, we used the XOR method for sprites. Drawing a sprite XORed it onto the background, and drawing it again in the same place erased it. Self-cleaning and clever, but overlapping sprites produced “holes” where set bits canceled out.

For Robin, I wanted something solid. I switched to OR: sprites drawn additively, no transparency holes. The catch was that OR doesn’t self-erase like XOR. As sprites moved, something else had to clean up the background behind them.

The simplest cleanup is what Manic Miner and Jet Set Willy did on the Spectrum: keep three physical copies of the screen. One with the clean background, one working buffer into which the sprites are drawn over the background, and the visible screen itself. Each frame, the clean copy is blitted into the working buffer (a single Z80 LDIR instruction does it), sprites are drawn on top, and the result is copied to the visible screen. Elegant and robust. Also painfully slow: LDIR is one of the most compact ways to copy memory in the Z80 instruction set, and one of the slowest.

I wanted speed. The alternative was dirty rectangles: track exactly which parts of the screen had changed (where a character had moved, where an arrow had flown), and only redraw those specific (dirty) areas. Much higher frame rate, but a high-wire act: too many things moving at once, and the number of rectangles would spike, and the frame rate would collapse.

Debugging this system was a dark art. We didn’t have the luxury of single-stepping through source code on the screen. We used Derrick Rowson’s disassembler (my ex-colleague at Software Projects), the HiSoft monitor for the really down-and-dirty stuff, and a lot of crossed fingers. My primary debugging tool was often just changing the screen border color to indicate which part of the code the processor had reached before it crashed. If the screen froze and the border was red, I knew the bug was in the render loop. If it was blue, it was the logic. It was primitive, but effective.

The development process sparked a friendly rivalry with Marc on the C64. Despite being developed in parallel, there was very little data shared between the two games beyond the map data we copied over periodically.

Marc was a machine. He was a faster coder than I, cranking out routines while I sat there agonizing over the little details. I would spend hours trying to make a loop more elegant or “clever,” not necessarily making the code better, just satisfying my own obsession with structure. In the end, despite the different hardware and our different psychological approaches, the two versions played almost identically.

To round it off, Andy Walker performed miracles with the sound. The Spectrum beeper was only designed to make one noise at a time. On or off. For Nodes, Andy and I had built a 1.5-bit player that drove the speaker with three voltage levels, but it could only fake two voices by doubling a single melody with a detuned copy. For Robin, we extended it: two fully independent voices through the same trick. Andy took it further still, fitting a percussion track in between the notes, perfectly suiting the medieval, Celtic melodies he had composed. In my head, I pictured a little folklore figure frantically shaking a shillelagh to the beat. Andy created a sound driver that gave the title page and Game Over screens a rich, harmonic depth that shouldn’t have been possible on a 48K rubber-keyed wedge. Andy also voiced the introductory spoken audio, “Can you help Robin in his quest for the silver arrow?”

The descending pitch cackle as the screen ‘curtain’ effect plays was all my doing, though. :)

Visually, the game was pure Paul Salmon. His art style was distinctively different from Colin Grunes’, more organic and more textured. Games like Firelord and Curse of Sherwood appeared soon after, sporting trees and foliage that looked suspiciously familiar. Imitation, they say, is the sincerest form of flattery.

All this art was wrapped around a lot of game. Robin was bigger than Nodes had been: not just in rooms, but in the cast of characters the player encountered. The witch, the Ent, the Sheriff of Nottingham, the hermit, the bishop, and more. Each one needed its own code. And underneath all that, the foundation was new too: the room editor, the rendering system, and all the core gameplay elements had been built from scratch. Very little of Nodes came along for the ride.

As the deadline crept up, the scale started to bite. I’d thought I could solo the Spectrum development, but I needed help. Keith Robinson stepped in and implemented some of those denizens, including the bishop, and every interaction with him. Robin got over the finish line because Keith picked up the slack. Thanks, Keith.

The critical reception confirmed we had another winner on our hands. Robin of the Wood secured another “Crash Smash” for Odin, scoring 94% in the Christmas 1985 issue, one point higher than Nodes, with 95% for Paul’s graphics. The reviewers raved about the “bewilderingly large” map and the atmosphere. We had done it again.

For me, this one felt even more special than Nodes. I’d been involved from day one and seen it through to the end.

None of us received a named credit. Odin did not allow it then, in the games or in the press, partly to stop rival studios knowing who to poach, partly to keep an air of mystery about the place. So the reviews thanked “the Odin team,” and some of Paul’s best work went out into the world under a company name.

Just as we were finding our rhythm, the distributors who controlled the UK market handed down a mandate: “You must support the new 128K Spectrum.”

We were skeptical. We weren’t convinced the market penetration would be there for the new machine, and we had little desire to spend weeks optimizing our games for a minority audience. But the distributors held the keys to the kingdom, so we came up with a “support” plan that could be executed in a couple of evenings.

“What if,” someone (it may have been me) suggested, “we just fill the extra memory with sampled speech?”

And that is exactly what we did for the 128K versions of Nodes, Arc, and Robin. We took Andy Walker, our musician and impromptu voice actor, recorded him grunting things like “oof” and “ow,” and stuffed the RAM until it was full.

The playback was crude (the same 1.5-bit technique we used for the music) and the implementation was clumsy. Because the processor had to dedicate itself entirely to pushing out the audio, the gameplay would actually pause every time a sample was played. It was the definition of a bolted-on feature, but it allowed us to put a “128K” sticker on the box.

The music, however, got a genuine upgrade.

The 128K Spectrum used the AY sound chip, which had three channels of audio compared to the single channel of the 48K beeper. Thanks to my time wrangling the Amstrad CPC at Software Projects, I was already fluent in the AY chip, so porting the sound drivers was a breeze. If I am not mistaken, I actually just ported the music player I’d written for the Enterprise back to the Spectrum.

We even employed a little studio trickery. When moving 2-voice music (from our 48K player) to the 3-voice system, we didn’t just leave the third channel empty. We took the lead voice, doubled it onto the third channel, and then detuned it ever so slightly.

This created a phasing or “flanging” effect that thickened the sound, making it feel richer and wider. It was a trick we had actually prototyped on the original 48K Nodes of Yesod beeper routine. On that machine, we couldn’t handle two individual lines of note data yet, so we had simply taken a single voice, doubled it, and detuned one of the channels. That brute-force approach explains the distinctive, slightly dissonant “hammering” quality of the original Nodes theme. On the 128K, with proper hardware support, it just sounded lush.

We had released a hit, a reskin, a port, and our second album. We had even placated the distributors with our “speech” editions. We were on top of the world. The team was gelling. We felt like we could do anything.

Behind the scenes, though, there was financial pressure to grow the business, and Paul was hunting for ways to expand our market. One of those pursuits was Capcom. The plan was to take Robin of the Wood to them and develop it into a full arcade game. Phone calls and meetings happened, and though I wasn’t in those meetings myself, the sense I got was that there was real interest. Other Odin folks have written about this online over the years, and accounts vary; one version has it that a contract was prepared but arrived a day late. I can’t speak to the specifics, but I do know that the Capcom option was pursued vigorously.

One thing was certain: behind the closed doors of his office and on various mysterious business trips, especially to see a big company in London, Paul was working very hard indeed to put something together. He believed in the core team's strength, and he was pulling out all the stops to make something happen.

Paul had one of the very earliest mobile phones in those days, complete with a big carrying case, presumably containing batteries and the like. I remember him setting off for London in the Range Rover, phone-suitcase in hand.

Then came the meeting.

Paul gathered the whole company together. If memory serves, the meeting was in The Dolphin pub. The business was growing. The overheads were rising. We needed more product.

“As you guys know, we’ve been talking to Capcom, and I’ve been meeting with various other companies, including a large game publisher in London. I have to inform you all that, unfortunately, we are not moving forward with Capcom.”

There was a pregnant pause.

“I’ve signed a deal,” he said. “We make ten games. In twelve months.”

The room went silent. The Golden Age was over. The grind was about to begin.

Chapter 9: The Firebird Factory

·

Jun 21

The transition from a boutique studio to an industrial assembly line didn’t happen with a bang. It happened with a signature.

This chapter is the eighth part of an ongoing series. An evolving list of chapters is available on the contents page.