Uploaded April 2021 | Updated September 2026, 2 weeks ago
This is a demonstration of a "level editor" created for the Destiny Hunter game. Like the game itself, the editor can run on the Commodore PET.
A demo of the game itself is here: youtube.com/channel/UCClmJOq3rLUTtTNYJU9lBFA
The editor runs in a "text mode" whereas the game runs in a "graphics mode." Essentially this means a slightly different set of characters is available between the modes. Also in the "graphics mode," the font spacing is tighter which allows for adjacent text to appear as a solid shape.
The editor allows "drawing" a map in an easy manner, using letters to denote terrain types (e.g. W for WATER tiles) and also visually showing the "blocker" status of any individual tile. "blockers" is just the term used here to indicate that the player and challenges in the game cannot move into that cell (its "blocked", like a barrier). When saving the map information to disk, there are two files:
#) the map is compressed using a simple "RLE" algorithm: each alternating sequence of tiles becomes a [style][count] abbreviated form. For example, a sequence of five waters is stored as "W5".
The information is packed onto the actual disk slightly differently. The "W5" for example is packed into a [3bit][5bit] (1 byte) "encoding" since that is how the information is parsed by the game, and so this saves some memory there. The 3-bit means we can only have 8 different tile types (0-7), and the 5-bits means each sequence length can only be up to 32 characters (if you pay attention, 5-bits can only represent up to 31 -- as a little trick, when reading the data was take N and implicitly add 1, since the existence of single pair of RLE encoding implies at least 1 character in the sequence, so we save a slightly bit of space by this implicit assumption).
Here is an example of how the first map gets encoded:
3 -- symbol 0 (water), 4 copies (3+1) [_ _ _] [_ _ _ 1 1]
42 -- symbol 1 (beach), 11 copies (10+1) [001] [01010]
128 -- symbol 4 (land), 1 copy (0+1)
97 -- symbol 3 (rocks), 2 copies (1+1)
128 -- symbol 4 (land), 1 copy (0+1)
38 -- symbol 1 (beach), 7 copies (0+1)
76 -- symbol 2 (grass), 13 copies (12+1)
...and so on... NOTE: the above values are in decimal - it would be more convenient for them to be in hex, but to help transfer the data from the PET to the Windows machines I use to compile the software (where these encodings get directly embedded into the code), I had to use a common set of characters (which the numbers 0-9 happened to be, but not the hex values A-F).
#2) The blockers get saved in a separate file. It could have been the same file, but just to keep things easier and more obvious, it was divided into two separate files (for example, we can alter and muck with the RLE encoding format, without impacting the blocker data format, and vice versa). Blockers become a bit mask along each entire row of the game map.
Stage 1 doesn't have a lot of blockers, so here is an example from Stage 6:
0 [0,0,0,0,0],
1 [0,0,0,0,0],
2 [0,2,0,24,0],
3 [128,3,0,240,31],
4 [255,0,0,128,113],
5 [0,0,0,0,0],
...
Rows 0 and 1 aren't currently part of the map, so their codes are always 0's. This just keeps the indexing consistent between the data file and the screen, so we don't have to add or subtract by 2 all the time (small detail, but a minor example of "wasting" a bit of space to reduce computation needs). Row 3 and 4 in this example have a lot of blockers, and the full set of 40 rows is expressed in a 40-bit sequence (5 bytes). For each bit, it means its corresponding column (for that row) is "blocked" for movement by the players and challenges. There are a couple exception: it's not blocked by the bow weapon, and certain creatures may be exempt from being blocked (such as flying or ghost type creatures). So that's the thing about data: it's all interpretation and depends on the context. Without that context, a data stream becomes almost useless.
One extra little detail here: the bits in the blocker code sequence are written "backwards". Initially I didn't do that, I kept each bit in the same order as the columns. This meant in the code, I constantly had to do "8-ColumnOffset", wasting a bit of computation time- but it made it easier to debug, since I could look at a hex sequence and verify if the expected blocker bit was set. Later I reversed this, to save the computation (but also had to resave all my blocker files). So for example, in the first blocker byte, the first column 0 is "bit 0", which is on the right side of the byte, not the left.
In old days, we would draw this as such:
_ _ _ _ _ _ _ _
| ^-column 1
^-- column 2
So that's what I mean by "backwards", you'd normally think of columns going left to right, but that's not how bits are ordered within bytes :)
This is a demonstration of a "level editor" created for the Destiny Hunter game. Like the game itself, the editor can run on the Commodore PET.
A demo of the game itself is here: youtube.com/channel/UCClmJOq3rLUTtTNYJU9lBFA
The editor runs in a "text mode" whereas the game runs in a "graphics mode." Essentially this means a slightly different set of characters is available between the modes. Also in the "graphics mode," the font spacing is tighter which allows for adjacent text to appear as a solid shape.
The editor allows "drawing" a map in an easy manner, using letters to denote terrain types (e.g. W for WATER tiles) and also visually showing the "blocker" status of any individual tile. "blockers" is just the term used here to indicate that the player and challenges in the game cannot move into that cell (its "blocked", like a barrier). When saving the map information to disk, there are two files:
#) the map is compressed using a simple "RLE" algorithm: each alternating sequence of tiles becomes a [style][count] abbreviated form. For example, a sequence of five waters is stored as "W5".
The information is packed onto the actual disk slightly differently. The "W5" for example is packed into a [3bit][5bit] (1 byte) "encoding" since that is how the information is parsed by the game, and so this saves some memory there. The 3-bit means we can only have 8 different tile types (0-7), and the 5-bits means each sequence length can only be up to 32 characters (if you pay attention, 5-bits can only represent up to 31 -- as a little trick, when reading the data was take N and implicitly add 1, since the existence of single pair of RLE encoding implies at least 1 character in the sequence, so we save a slightly bit of space by this implicit assumption).
Here is an example of how the first map gets encoded:
3 -- symbol 0 (water), 4 copies (3+1) [_ _ _] [_ _ _ 1 1]
42 -- symbol 1 (beach), 11 copies (10+1) [001] [01010]
128 -- symbol 4 (land), 1 copy (0+1)
97 -- symbol 3 (rocks), 2 copies (1+1)
128 -- symbol 4 (land), 1 copy (0+1)
38 -- symbol 1 (beach), 7 copies (0+1)
76 -- symbol 2 (grass), 13 copies (12+1)
...and so on... NOTE: the above values are in decimal - it would be more convenient for them to be in hex, but to help transfer the data from the PET to the Windows machines I use to compile the software (where these encodings get directly embedded into the code), I had to use a common set of characters (which the numbers 0-9 happened to be, but not the hex values A-F).
#2) The blockers get saved in a separate file. It could have been the same file, but just to keep things easier and more obvious, it was divided into two separate files (for example, we can alter and muck with the RLE encoding format, without impacting the blocker data format, and vice versa). Blockers become a bit mask along each entire row of the game map.
Stage 1 doesn't have a lot of blockers, so here is an example from Stage 6:
0 [0,0,0,0,0],
1 [0,0,0,0,0],
2 [0,2,0,24,0],
3 [128,3,0,240,31],
4 [255,0,0,128,113],
5 [0,0,0,0,0],
...
Rows 0 and 1 aren't currently part of the map, so their codes are always 0's. This just keeps the indexing consistent between the data file and the screen, so we don't have to add or subtract by 2 all the time (small detail, but a minor example of "wasting" a bit of space to reduce computation needs). Row 3 and 4 in this example have a lot of blockers, and the full set of 40 rows is expressed in a 40-bit sequence (5 bytes). For each bit, it means its corresponding column (for that row) is "blocked" for movement by the players and challenges. There are a couple exception: it's not blocked by the bow weapon, and certain creatures may be exempt from being blocked (such as flying or ghost type creatures). So that's the thing about data: it's all interpretation and depends on the context. Without that context, a data stream becomes almost useless.
One extra little detail here: the bits in the blocker code sequence are written "backwards". Initially I didn't do that, I kept each bit in the same order as the columns. This meant in the code, I constantly had to do "8-ColumnOffset", wasting a bit of computation time- but it made it easier to debug, since I could look at a hex sequence and verify if the expected blocker bit was set. Later I reversed this, to save the computation (but also had to resave all my blocker files). So for example, in the first blocker byte, the first column 0 is "bit 0", which is on the right side of the byte, not the left.
In old days, we would draw this as such:
_ _ _ _ _ _ _ _
| ^-column 1
^-- column 2
So that's what I mean by "backwards", you'd normally think of columns going left to right, but that's not how bits are ordered within bytes :)
