Jason Mitchell - 2003-11-06

If you look at the original schedule, I was supposed to be done with collision detection by this point, have the basic domain functionality up and running, and be working on lighting and texturing (Which, if I ever get to the lighting, will be a big pain also, I imagine).

Howver, I've been bogged down with making the collision detection work properly.

The original idea hovers around keeping track of position using floating point values, to allow for a bit finer gradition in movement over the pixels from the original game.

At the same time, the "pixel" position of the player is kept, updated by some rather gnarly math. Rather than use the float position of walls and such to do detection, the algorithm changes those values in to pixel positions, and looks at the obstacle data for that position.

Essentially, armed with knowledge of where in pixels the player currently is, the algorithm takes one step (but you'll see why I actually used two steps in a sec), and then sees what new (if any) pixel position it is in, and whether that position is one of many special cases:

1. An obstacle
2. In a new room/off the board for neighbor-less sides
3. If in a diagonal direction, next to obstacles that should not be traversed through.

In a perfect world, this should work. But it's not a perfect world. The first thing that became apparent is that with the right angle, you could step into walls. It kept you from walking in further, but you could see the inside. The simple solution to this was to make it look two steps ahead (but only actually take one step).

The next problem was that since neighborless rooms had a set of walls drawn just outside of the room, it was possible to walk into those walls. So code was added to stop that special case.

Long story short, the case is that the function, which started out simple, has expanded into a sprawling set of special cases that is both ugly AND buggy (That's probably a bit redundant to say).

There are two current bugs that would be haunting my dreams, if I had slept long enough to go into REM sleep recently. The first is that while the player is blocked from walking off a north or a west neighborless edge, it is not for south and east edges, and this leads to segmentation faults. At some point I have it semi-fixed, but then I magically weasled my way into being able to walk of the deep end again (What's worse, I wasn't even particularly trying to).

The other bug is that if you strafe in front of the corner of a wall, you can strafe just right so that you can walk forward, but be halfway in the wall.

I think these bugs were the last straw, because it is becoming increasingly familar to me that we are living in a floating point world, but I am a integer girl (Oh-Oh!). I think I need to sit down and rework the idea behind movement and collision detection. One thing that I also considered, is that as of now steps are taken on a frame-by-frame basis, rather than considering the real time situation. This is wrong. We may find ourselves a few years down the road in Aught-Nine desiring to run this game for old time's sake, and watch as our adventurer runs around like an  Ewok on speed.

This will take some thinking, and I think overall, I will buckle down over this weekend, and not only see about getting a windows version running, but also cleaning up code in general, and rethinking the collision detection algorithm.

But we'll go further and actually implement said code (Cthulu willing).

Over this past week, I did get a map display up, along with playing with how the walls, ceiling, and floor are textured. However, I don't feel like releasing a release until I have collision detection ironed out even if it DOES take until Aught-Nine to do so.