STALAGTITES AND STALAGMITES
- stars fixed (stupid scoping mistake)
- doors are done (command-line switches for locked, unlocked or open)
- items can now be placed on item pads (fixed some bugs in branch B of the tile drawing routine; coded some hitherto unimplemented entrypoints which adjust the plot position based on the size of the item in order to align it to the pad)
- pillars done (had to fix another stupid bug in reading MODE 2 style pixels from the new chunky collision buffer)
Ropes, pillars and ladders are similar in certain ways, but ultimately different in others. All three are drawn procedurally to permit a variable length without bloating the room data.
Ropes and pillars don't have a length associated with them. They are placed at a coordinate and then just "grow" until they encounter some nonzero collision, whereupon they stop. A pillar's origin is at its top, and it grows downwards until it hits something. A rope's origin is at its base, and it grows upwards until it hits something. This behaviour makes sense, since you want ropes to be able to dangle in mid-air, but for them always to be attached to something at the top. So, you can't place a rope that isn't attached to anything!
Ladders are different; they seem to use an explicit length parameter. They grow upwards, like the ropes do. At first I wondered why they weren't made to grow downwards and stop on collision, since I believe all ladders in the game rest on a floor -- there aren't any "rope ladders" whose bottom rung is in mid-air. This would obviate the need for the length parameter. However, I'm guessing the idea is that you can use a ladder to automatically cut a hole through a wall you've already drawn, whereas a rope would just halt on the collision in this case. Hence, although a rope and a ladder work the same way from the player's point of view, they are not equivalent.
I've reached an interesting juncture with this code now. All of the static elements of the rooms are implemented and seem to draw correctly. This doesn't mean I have the room format completely implemented yet, because of course the room bytecode also defines all the various animations that are cycled during gameplay, which are dealt with by the subroutine I called animate
. Implementing these doesn't seem to make much sense yet, since the code just spits out a single image file; there is no way to output multiple frames. It could be modified to do this, but there's not a lot of sense in it, since certain animations (e.g. the creatures which chase the player) are modulated by the player's current position.
There is a lot of cleanup work to be done, and I want to try to "decouple" as much of the code as I can. Data flows are performed through simulated zero-page variables used by the game itself, which was a deliberate choice to guarantee that the thing would work. Many of these are "foo/bar"-style variables which are used for different purposes depending on which routine is currently executing. I want to get rid of those, to rename everything logically, and to try to rework everything in a more functional style in which routines have well-defined input and output parameters, which was really the whole point of doing this in the first place. Fortunately this should now be easy, because I have a reference implementation, and so any change which breaks something will be trivial to detect.
The question is where to go with it after that. Originally I was thinking about doing an enhanced reimplementation for modern OSes in C. Now I am wondering if making something that runs in a browser instead might be a more interesting route, when you consider possibilities like level editing, or animated, real-time, pictorial demonstrations of how things are drawn.