Today I’m going to talk a little bit about the format I use to store my room data. In Explorer, the player views rooms from the top. The background doesn’t scroll at all when the player moves. Everything stays put until the player hits the edge of the screen. When that happens, a new room is loaded and drawn to the screen.
A consequence of this style of gameplay is that rooms will have many things in common. For example, they will all be the same size. They will all be enclosed by walls. They will all have gaps somewhere in the walls to allow passage between rooms. They will all have floor space.
To avoid having redundant data for every room in the game, I have a blank room stored uncompressed in ROM. It looks like this:
This is the default blank room. It has 4 solid walls enclosing a field of floor tiles.
When I load a new room, the first thing I do is copy this blank room into RAM. Then I read the data for the new room and write the new data over the copy of the blank room in RAM. This saves me a lot of bytes in ROM, as I don’t have to store all of those wall and floor tiles in the data for each individual room. I assume four walls and a floor and draw the extras on top.
Gaps in the Walls
The default room is nice, but it traps the player inside. There are no gaps in the walls. So my map data needs a way to tell me where to stick gaps so that player can navigate to other rooms.
Explorer is a puzzle game. It’s a maze. I can’t just have one exit per direction ala Zelda. I need each wall to potentially have several exits. Some will lead to dead ends, some will allow access to areas that others won’t. I want a lot of flexibility but at the same time I don’t want the wall-gap data to take up too much ROM space. There are going to be hundreds of rooms, so I want to keep them as compact as possible.
My current solution is to use 4 bytes, one per wall. Each bit represents a gap. Look at this picture:
Each wall has a byte telling where the gaps are. The numbers in the picture show which bit represents which gap.
The numbers in the above picture show which bit controls which section of wall. For example, if my byte for the north wall of a room were #%10000001, the gaps marked 7 and 0 would be open, while 1-6 would be blocked, like this:
The north wall is represented by the value #%10000001
The first four bytes in a room’s data are the wall/gap data, in order of North, South, West, East. North and south have the same bit mapping scheme, as do west and east.
Let’s take a look at the room I posted up in my post about attributes:
A nice room
The first four bytes in the room data are: %00100100, %00011000, %00011000, %00011000. Notice how the set bits correspond to the gaps in the room.
Code Sample
The code to generate these walls is pretty straightforward. First I read the byte from the map data, then I call a subroutine which will translate that byte into a buffer of wall/floor tiles. This subroutine just shifts out the bits one at a time and plugs the appropriate value into the buffer. Here’s the version for making north-south walls:
lda (temp_ptr1), y ;read the top wall byte
iny
jsr room_build_ns_wall ;this fills a buffer which we can
;copy to the tile map in RAM
room_build_ns_wall:
sta map_temp1
ldx #$0B
@loop:
cpx #$01 ;these four positions are always walls.
beq @wall ;they are not controlled by the wall byte.
cpx #$03
beq @wall
cpx #$08
beq @wall
cpx #$0A
beq @wall
lsr map_temp1 ;shift a bit out
bcc @wall ;if it's zero, wall
lda #floor ;else it's a floor
beq @write
@wall:
lda #wall
@write:
sta room_wall_buffer, x
dex
bpl @loop ;end the loop at x==$FF
rts
Once I have my buffer filled, I copy it onto the blank room in RAM.
The west-east wall version is almost identical, it just has different “always-wall” values.
If you are wondering what #floor and #wall are, they are just constants. I try to avoid hard-coding values whenever possible. My tile ids are declared using ca65’s .ENUM directive:
.enum
floor
wall
block
water
block_breakable
stairs_up
stairs_down
.endenum
#floor will evaluate to #$00, and #wall will evaluate to #$01.
Conclusion
I think I can improve even further on this wall/gap format. There is a lot of redundant data still. For example, adjacent rooms will have the same byte values for their shared wall. If I can come up with a scheme to eliminate this redundancy, I can save even more bytes. That’s a battle for another day though. This format works for now and I’m going to move forward. But if you have any suggestions, please let me know!
Next time I’ll talk about the rest of my room format: ie, how I store tiles in the room interior.
