The original Apple II version of Lode Runner comprised 150 levels, these were loaded from disk when required. The ZX81 doesn't afford us the luxury of being able to load from a disk or tape without clearing the running application and memory. So even if we assume our ZX81 has 32k of RAM (about the maximum for the time), squeezing all 150 levels into the diminutive black box is an insurmountable task.
There are modern storage solutions available such as the ZXpand, that could be used to negate the space restrictions, however there is no common file access method shared across these modern deceives. So regardless of current available solutions, the challenge here is to fit as many levels as possible into the resources we do have at our disposal.
To make the challenge slightly easier I'm going to base the level design on the Apple II version, not the (possibly expected) ZX Spectrum incarnation. The reason for this is a simple matter of level storage space. The Apple II maps are a convenient space saving 28 wide x 16 tiles high, where as the Spectrum versions comes in at 32 wide x 22 tiles high. Or to put it another way, 448 tiles on the Apple version versus 704 tiles on the Spectrum version per level to define.
If we look to any "type in" game from the period as a (bad) example, most defined entire screens in the program listings on a one to one tile basis. This method would uses 1 byte per tile, and clearly there is not enough space in a ZX81 for even 10 levels defined in this manner (and still have a game to play). It's imperative to compress each level down as far as possible.
The solution is to store the tile type and the number of tiles(of the same type) in succession into 1 byte. To achieve this, we can use two 4 bit numbers. This affords us up to 16 available tile types, and 16 successions of that tile. Wwe add the number of tile repeats, 0 to 15 to the tile type value. The tile type value is bit shifted before the addition, and this will produce an 8bit number we can store.
|Lode Runner Map Tiles: 4 bit Number Values Chart|
|Tile No||4 Bit Shited||Level Starting Position Tile Type|
|000||000||Empty: Clear Tile / Background|
|001||016||Block: Can't dig through tile|
|002||032||Bricks: Can be dug into to create traps|
|003||048||Bricks, Fake: Player falls through fake bricks|
|004||064||Rope: Player can move horizontally, or jump down|
|005||080||Ladder: Visible all game / level|
|006||096||Ladder, Escape: Visible only after all gold is collected on a level|
|007||112||Gold: Player to collect all gold|
|008||128||Guard: Starting position of Guards. After level begins guards fall from the top of screen (after being trapped).|
|009||144||Player: The Lode Runner|
For example, using the table above, if we require 4 Bircks in a row, we take the value of Bricks, 32 and add it to the number of required repeats 3, for a total of 35. In, in order to produce the entire starting positions of the first level of the Apple II version of Load Runner, each of the 16 rows would be defined as bellow.
07) 4,128,0,80,3,33,80,9,80,1, (missing right guard and gold)
|Lode Runner, Level 1, Apple II Version|
After reading the level data as outlined, the ZX81 level would look something like the bellow screen shot (if using standard character set, no hires graphics yet). Notice that the the escape ladder is drawn in with the "S" character.
|Lode Runner, Level 1, ZX81 level Map., Starting Position.|
Rather than guess the levels layout, I converted directly from the LodeRunner TotalRecall levels, as (re-)implented by Simon Hung. The TotalRecall levels are implemented in ASCII, which makes reading them easy. The ZX81 map is missing the 2nd guard and gold on line 7, I overlooked these items when writting up the test.
That's all for now, be assured I'm still wotking away on the project, it's just going a little slower than anticipated due to some time and life constraints.