THE Braybrook BIT
In my C64 days we would mostly build our backgrounds out of 8x8 pixel characters. This was because the VIC-II graphics chip built its screen that way, notwithstanding that it did also have an option to display a complete bit-map screen, which I used in 3D Lunattack.
This character mode though gave us a number of advantages, including that we would make our backgrounds out of, usually, one set of
256 user-defined graphics. The Dragon 32 had a character mode too, but the character set was preset to the ASCII characters and a few additional, shall we call them, icons? The C64 had its default character set of ASCII characters, but they could all be changed to any arbitrary graphics, in either 2-colour 8x8 pixels or 4-colour 4X8 pixels.
To build a background then we would try to draw graphics that might fit together in different ways. In Gribbly`s Day Out on the C64 I had drawn various rock and ground formations. The good thing about rocks is that they are fairly random anyway, so they fit together pretty well and I could concentrate on the larger structures I wanted to draw.
For a nice big scrolling background environment you are then faced with a few questions: how big do you want to make the different areas? How are you going to create those areas? How are you going to get between the areas? And finally, how are you going to store those areas?
Firstly, with an 8-bit processor, it would be wise to stick to no more than 256 characters wide, that way you can use 8-bit offsets to calculate start positions to copy the relevant characters from the map to the display screen. 256 characters divided by a screen width of 39 gives us a width of six and a half screens. Your map depth will then depend upon how much RAM you want to spend on it. A depth of 256 characters would use the whole machine`s
RAM, so we will have to reduce that. 64 characters deep by 256 wide uses 16K, a quarter of the machine. 64 characters with a screen depth of 20 gives just over 3 screens high.
I chose to use patterns to populate the maps. Indirection saves so much time and is very flexible. By allowing up to 256 arbitrary-sized blocks I can refer to them through a list of block start positions. I devised a routine to plot rectangular areas of arbitrary sizes onto the map. Firstly The map consisted of a lot of triangular power lines in the sky. These were applied all over the screen to start with. These blocks were quite large. The bottom of the map was then populated from left to right with a list of blocks, so for that list I didn`t need any positions. After that was a list of blocks to plot into the map, giving an X and Y start position and a block number. I could then list all of the structures I wanted to build around the map. I also had blocks that could remove a power line, or a button, so I could remove things as well as ad them. I may then, I can`t remember exactly, have had a final list of individual characters so I could just slightly alter individual characters.
Each map represented a level of the game, there was no need in this game to move between the levels arbitrarily. That didn`t happen until Paradroid, and comes with its own issues. I did implement a system of choosing the next level you get to based on how well you do in the level, i.e. how many Gribblets you rescue. After level 1 you will get level 2 if you rescue 6 Gribblets, you might get level 2, 3 or 4 if you rescue all 8 Gribblets. It saves level 16 for the end! This at least makes the sequence a little less predicatable unless you keep rescuing exactly 6 Gribblets on every level, in which case you progress through all 16 levels in their original sequence.
So the backgrounds are stored as lists of blocks, and the blocks are shared across all of the maps. As the levels were being developed I added a few more blocks, but of course when you`re designing levels you don`t know necessarily what sequence they will end up in, that`s down to how they play. You just have to remember not to change blocks that you`ve already used in other maps.
I was developing these levels by drawing out the various blocks so I had a few pages of them on graph paper. Each level was a list of blocks and positions defined in an assembler file as a list of numbers. The block definitions were also numbers typed into the assembler. Naturally when you`re trying to position blocks on a map, you don`t get them right every time. If I spotted a mistake I would try to locate the bad data and correct it in memory and then restart the first level to see if it was better. With a 30-minute assembly time it was important to correct as much as possible so I would try to add more data onto the end of lists and then copy the data accurately back into the assembler.