The Making of Heartland for the Sinclair Spectrum
Note: this article expands upon material I provided for the RetroGamer #129 article on Heartland.
In 1986, Odin Computer Graphics Ltd published the game “Heartland” for 8-bit platforms such as the Sinclair Spectrum, Commodore 64, and Amstrad CPC. Colin Grunes was responsible for art, level design & background lore. I did the coding on the Spectrum and Amstrad CPC versions and contributed to gameplay design. Keith Robinson coded the Commodore 64 version.
Initial Development
Heartland development was commenced around the time of the Odin deal with TelecomSoft to create 10 new games, and Heartland was the first title released under that deal. As it happened, Odin moved office in the middle of the development of Heartland, though it was not a very big move (it was across the courtyard in Canning Place to another unit – the old Bug Byte office, as it happens). The new office was much bigger – we needed the space for the additional developers we would hire for the TelecomSoft deal. The move was not unduly difficult, we just carried our gear over one afternoon. That building was demolished in the ’90s to make way for downtown redevelopment in Liverpool.
The catalyst for Heartland’s development occurred during the development of Robin of the Wood (on which Paul Salmon was the main artist). In that period, Colin Grunes (lead artist on Nodes of Yesod) was creating the initial walk cycle for the main Heartland character, the Hero Wizard Eldritch (otherwise known as Bertie, whose full name may or may not have been Bertie Big Boy), in addition to other graphics ideas for backgrounds and some of the enemies. As soon as RotW was finished I began to experiment with dynamic mask generator code using the walk cycle. Before long, I had lots of Berties walking left and right on the screen using the masking technique, and this really gelled the visual direction for Heartland.
We tended not to do a lot of up-front design at Odin, not on details. So we would agree on the large stuff and then work out the details as we went along. Lots of things could drive the design, such as how many 16 pixel wide sprites would fit into a certain space (for the number of pages to collect), etc.
In terms of story development, Heartland was very much a collaborative effort. The graphics drove a lot of the back story, certainly, but ideas came from all around, as each idea came up, we’d discuss ways to integrate this or that idea into the game. I’m sure there were ideas from other developers, and from Paul McKenna (our Managing Director). It is likely that ideas came from Marc Wilding, Paul Salmon, Keith Robinson, Stuart Fotheringham, and other founding members of Odin.
There are clearly elements of Nodes of Yesod and Robin of the Wood in the game, in that the game is in side view and is room based. The map is a lot less linear than either of those games, the screens being linked by portals going into and out of the screen, in addition to the screen flipping, elevators, and staircases. A few of the ideas I’d included in the much-expanded Amstrad CPC version of Jet Set Willy made an appearance here too – the space section, for example, though that of course was also a nod to Nodes of Yesod.
Colin and I worked together very well. We had already collaborated on Nodes of Yesod, and after Heartland, we worked on Sidewize and Crosswize together at Odin. We also later worked on an (ultimately abortive) Atari ST/Amiga game @ Denton Designs called Gargantuan. Heartland was the first time we worked directly together as a duo (Nodes was always more of a team effort).
Graphics Development
On the art side, we had graphics for the first level very early on, along with the main Bertie sprites. The other graphics were developed in tandem with the game code and level editor that I created. Colin created all the pixel art in Melbourne Draw, painstakingly using the Spectrum’s rubber keys, though there may have been some sketches. It’s amazing what could be done without a drawing tablet, or even a mouse! There was definitely collaboration on ideas for art, but Colin did the vast majority of the pixel work. Stuart “Stoo” Fotheringham did a bunch of the in-game plants, and maybe one or two other things. Colin did the loading screen, I remember him slaving away trying to get the attributes to line up with the hand and the planet! That said, Stoo did create several of the loading screens for other games at Odin/Thor.
Gerry Fisher did a fantastic job on the box art (on which the game’s loading screen is based) as usual. He did the Nodes of Yesod, Arc of Yesod, and Robin of the Wood covers too.
Development Environment
Heartland was written from scratch (not based on Nodes of Yesod or Robin of the Wood) in Z80 assembly language. The code for the game was developed on a BBC Model B computer with the Z80 second processor running CPM. Under CPM we used the M80/L80 assembler/linker combination, and the Memo text editor. The Beebs had twin disk drives, so tools would run on one drive and game code would live on the other. In order to get code to the Spectrum, we’d use one of a variety of downloaders. At different times we used custom parallel and serial downloaders attached in various ways to the Spectrums (including Interface 1). Early on at Odin, some development had been attempted on Spectrums using MicroDrives, but this was quickly abandoned due to the unreliability of the Microdrive media.
The Beebs were really nice to use, though I seldom used the machine in actual BBC Micro mode. I think I might have spent a few hours playing Elite, having said that. 
I developed a visual tool for level creation. It allowed Colin to design room layouts, and then move between the rooms. It could save and load data (I think we had disk drives for the Spectrums at this stage).
Dynamic Masking
For Heartland I developed a graphical masking technique that was the cornerstone of the game – I wanted to be able to give a more solid feel to the sprites. In order to explain this, I’ll contrast how previous games drew their sprites. Bear in mind that the techniques here are pretty specific to what is essentially a 1-bit wide bitplane on the ZX Spectrum.
XOR Technique
In Nodes of Yesod, I used an “XOR” technique, which basically creates a “hole” where sprites or other graphical elements overlap. In a nutshell, the XOR (exclusive or) logical operation combines pixels as shown in the following image:
The XOR technique is efficient and easy to implement, and it has the benefit that in order to erase a sprite, you just draw it again in the same position! So, there’s no need to keep track of which parts of the screen have changed. You’ll notice that in Nodes of Yesod, things seldom overlap for very long. This is in part to avoid seeing holes where things overlap.
OR Technique
In Robin of the Wood, I used an “OR” technique, which results in a slightly more solid feel when sprites overlap each other. Combining pixels using OR looks like this:
This explains the lack of “holes” contained in the image when sprites overlap. The downside to this technique is that it is not in itself “self-erasing”, and it takes more programming effort, and more CPU cycles (in general) to keep the screen updated. It is also more difficult to discern foreground details from the background.
For Robin of the Wood, I kept a list of “dirty rectangles” so that instead of redrawing the entire screen I could just redraw those parts that changed. Again, more CPU cycles and additional complexity are introduced in this approach.
In RotW, things are allowed to overlap more than in Nodes of Yesod. This is because the OR technique is not as visually distracting as the XOR technique.
AND & OR Mask Technique
In Heartland, I used a “mask” approach, which essentially uses a “cookie-cutter” to remove all pixels behind each sprite. Usually, this cookie cutter has a larger area than the actual sprite, resulting in a (typically) black border around the sprites, and solid black areas in the inner part of the sprite. The cookie-cutter mask is applied before drawing the sprite, using an AND approach, the result looks like this:
You can clearly see that one of the elements is supposed to be in front of the other. By creating a cookie-cutter “AND” mask, you can clear space behind each sprite in which to draw it. Drawing of the actual sprite is then accomplished using the OR approach.
This technique is quite effective in producing more solid-looking graphics, but it has a couple of drawbacks. For one, more CPU cycles are needed to draw each sprite (since you have to “cookie cut” a hole for every sprite); additionally, storing this mask for every pixel doubles (on the ZX Spectrum) the amount of memory needed to store each sprite. The main problem in Heartland was fitting everything into memory (it was a single load game), and this is where the “dynamic mask” approach came in. To do this, every sprite and “prop” in the game was stored without a mask. In order to generate the mask dynamically, at level initialization time each graphic was shifted one pixel left, one pixel right, one pixel up and one pixel down. These resulting images were then combined together to create an image “fatter” than the original, and then this image was inverted to become the mask. The following images show this visually:
 |
A raw “Bertie” sprite from Heartland, as drawn by Colin Grunes and as stored in the game code. |
 |
In this image, we see the result of taking the raw sprite, and OR’ing it with versions shifted up, down, left, and right. This generates the “AND mask” – this is the shape of the hole to be cut in the background. |
 |
Final composited image, showing the raw sprite inverted (black for white) overlaid into the mask. |
The technique of generating the masks worked pretty well. Occasionally, there’d be a “hole” in the mask if more than a 3-pixel gap existed in the original art, but it was usually a quick job for Colin to fix up the error.
Music & Audio
Keith Tinman did the music, I did the sound effects, such as they were. The music player was an evolution of previous code that we’d used in Robin of the Woods, and that player was written by Andy Walker and I. It was a 2 channel player that made use of the fact that the Spectrum beeper could actually output three levels (essentially zero volume, ear bit, mic bit), so you could play two notes at once by careful bit toggling. We didn’t really have a good way of transcribing music from musical keyboard to the game, so there was lots of manual data entry involved.
TelecomSoft
As I mentioned earlier, Heartland was the first full game to be delivered under the agreement between Odin and Telecomsoft, in fact, it was probably one of the reasons the deal was signed in the first place. There was certainly pressure to complete games once the deal was signed, as we were supposed to complete 10 games inside of 1 year.
We actually hired a bunch of people to help develop those 10 titles (I did 2.5 of them, with Heartland Speccy, Heartland CPC, and Sidewize), but it was hard to maintain quality and pace of development with the new hires. Frankly, there wasn’t enough management experience at Odin, and what had worked for one or two concurrent titles just didn’t scale well to 10 titles in a year. Doing so many titles in a year definitely drove down the quality of the games.
As far as I remember TelecomSoft had very little input on the creative direction for Heartland, they had some approvals but generally left us to get on with it. They did start to take rather more of an interest in things as we approached the end of the 12 month period as it became clear that Odin was having difficulty delivering the agreed-upon number of games. There were several visits during that period.
C64 & Amstrad Versions
I did the Amstrad CPC ports (both the cassette version and the disk version), and I had a lot of fun with that. I used mode 0 on the Amstrad, which gave the game a chunky, but very colorful look. I worked from home for a few weeks during this work, and it was a very productive time. The Amstrad version came together very quickly.
Colin created the mode 0 art, and even though the screen aspect ratio was different on the CPC, I made all the existing room layouts work OK with minimal changes (much to Colin’s relief!)
The music on the CPC version is derived directly from the Spectrum version. The Spectrum beeper track has 2 channels, so to fill out the sound for the CPC on the 3-channel AY chip I simply doubled up the lead line, detuning one of the channels by a small amount to give a “chorus” or “phasing” effect.
I had very little involvement with the C64 version of the game, other than some input on the data structures and graphics organization, and then to answer any questions that came up with the code. The C64 version was coded by Keith Robinson, and work started on the game after the Spectrum game was underway.
Random Trivia
While the working title for the game was “Kimera”, it turned out that there was another game by a similar name (Chimera), so the name Heartland was selected for the final game. By the way, Heartland is the name of a Sisters of Mercy song, and the lead singer of the Sisters of Mercy is Andrew Eldritch.
Other random trivia. After Odin had closed, Colin and I pitched a game called Heart of Yesod around to a few publishers. This was to be an Amiga and Atari ST game that brought the worlds of Nodes of Yesod and Heartland together. It was something like Nodes of Yesod meets Heartland by way of Narnia (there was a wardrobe involved) and Mr. Ben. I have a copy of the typewritten backstory doc around here somewhere, but perhaps, needless to say, that game did not get funded.
Final Thoughts
There are a couple of things I would do differently if I could do it over again. First, the mechanic for going through doorways is really fiddly! Should have just used two keys, one for “into the screen” and one for “out”. More importantly, I wish there were platforms in the games. All action occurs at ground level, and you effectively play out a big maze. Platforms would have allowed us to create more puzzles and opened up the game world somewhat.
Thanks to Colin’s art, Heartland is a very pretty-looking game. As I mentioned above, certain aspects of the control scheme seem overly fiddly to my 2014 eyes, and I wish the game had more of a platform aspect to it, but overall I am reasonably happy with it. I especially like the Amstrad CPC versions of the game – the frame rate is higher and the game is more colorful there.
Comments