Chapter 10 - November 1st, 2013

The Map Editor

Quite often in the development of a game, there is a need for a customised tool to help one create a component of the game. This was especially the case back in the early years of computers when there wasn't many suitable commercial tools available that would do the job.

Even nowadays, sometimes one needs a custom solution and the game developer has to create these tools himself. With PopStar Pilot, I have a specific need to create the encoded map data which the game will use to reconstruct the scrolling landscape. No such tool exists that will do what I need, the way I need it. I  therefore must create my own and for this I utilise the CoCo's built-in BASIC to create the necessary program.

Defining the map encoding

But before delving into any code, I had to define a mapping system for the terrain itself. For this, I allocated an 8K memory block and set about to define a mapping scheme that was simple yet yielded a large number of screens. The number of screens is how I measure the length of each level. My plan was to have 5 levels in the game and I wanted each level to be a substantial size so I set about trying to define a method of encoding the information to achieve this goal. I went through many schemes and eventually settled on the mapping outlined below.

I devised a 2 byte encoding of a vertical slice of terrain. The first byte encodes the upper ceiling when flying within a cave environment as well as any objects attached while the second byte encodes the ground terrain and any objects here. Objects take the form of ground and ceiling mounted cannons that fire upon you as you approach, fuel stores that you must destroy to replenish your fuel reserves and others I have yet to define.

Bits 0-1 in each byte define an object ID with zero being no object. This allows up to 3 unique objects.

Bits 2-6 (with bits 0-1 masked out) are an offset value from 0 to 124 in increments of 4. These signify the offset from the top of the scrolling area (ceiling byte) and the offset from the bottom of the scrolling area (ground byte). 

Two bytes for every vertical 1 byte wide (2 pixel) slice means that each screen occupies 320 bytes and this amounts to a total of 25 screens in an 8K memory block allocation.

25 screens for 5 levels is way too small. I needed at least 25 screens for each level and I didn't want to allocate any more memory for this.

I came up with the idea that these 2 bytes will not represent each strip of the terrain but instead, spaced out to map every 8th strip. The 2 strips would act as key points and the decoding routines would fill the gap in between. This drops the screen requirement to 40 bytes per screen and a total of 204 screens in an 8K block. With 5 levels, that makes for at least 40 screens per level... much better!

I had two options I could utilize to fill the gap in between the two key slices. The first was to merely fill the strips in by repeating the first key strip. This would create a heavily stepped terrain and could be used as an effect to show an artificially created terrain. This would be a challenging terrain to navigate as I could create very tight caverns for the player to navigate.

The second option was to render a slope to connect the two key strips in order to create a more natural mountainous slope as shown in the screenshots below. The left image is my BASIC program rendering the terrain in a vector view while the image on the right is the same map rendered in the solid view. The vector view updates quicker while the solid view more closely visualizes what the final result would be. My BASIC program is slow to render this solid view so I mainly do my editing in the vector view and view the results when I'm finished in the solid view.

 

Download and try it for yourself:  SAMPLE.DSK

 

The cursor position flashes black/red or black/green depending on whether you are in ceiling or ground editing mode. It may be a bit hard to see but as a game development tool, it suits my purpose. As I progress, I may still add functions to it to make the job of creating terrain easier.

When you first start the program, it will ask for a start page. You can start on any page from 0 to 200. The program will decode whatever data is in memory and will initially be junk data when first run. Press L to load the MAPDATA file of which I have created only one page (page 0).

The solid color nature of the terrain is a bit bland but my aim is not to tax the CPU too much with added detail. My goal is to achieve a 30 frame per second frame rate and I will need to save as many cycles as possible if I am to achieve this. If towards the end of the game devolpment I find I have cycles left over, I will look into providing more detail to spice it up a bit but I think that once the other graphic elements are added and the terrain is scrolling smoothly, the overall appearance will be fine. It may not be the most elegant program but it was built to serve a specific purpose.

 

KEYBOARD CONTROLS FOR THE MAP EDITOR

LEFT AND RIGHT ARROWSMOVE CURSOR TO THE NEXT KEY STRIP
UP AND DOWN ARROWSRAISE AND LOWER THE TERRAIN
SHIFT + LEFT AND RIGHT ARROWSMOVE TO NEXT SCREEN OF MAPDATA
ENTERREFRESH THE DISPLAY
F1SWITCH BETWEEN CEILING AND GROUND EDITING
F2SWITCH BETWEEN VECTOR AND FILLED RENDERING
LLOAD MAPDATA
SSAVE MAPDATA
RRESET CURRENT PAGE DATA TO ZERO

 

With the editor up and running, it?s now a matter of spending many hours creating terrain designs. Even with this tool, it?s a time consuming exercise. Initially I will create only a few screens so that I have map data to feed into my decoding routine as I develop it.

In the next instalment I hope to have the decoding routines completed and we can finally see a one byte smooth scrolling split screen image.

Level design

I have also been doing some planning on the structure of the levels. The norm is a linear scroll through each level, progressing from start to end. But I see this as an opportunity to differentiate and start steering the program into something original.

I am toying with the idea of a 3D structure to the levels. Not visually 3D but from a level mapping angle. I thought that I could link each level with portals that jump you to another section of the level or another level altogether. This adds a bit of an adventure element to the game as you try and navigate your way through all the levels, collecting star keys to unlock portals and ultimately reach the end. This seems like a unique twist for a horizontally scrolling shoot-em-up and I will develop the idea further as I progress.

 

                                 

Copyright 2013 by Nickolas Marentes