In response to input by Servant of the Lord and Eck in my previous entry on bridges, I made a change to how the hexmap tracks object IDs. The result is a system that has not only allowed me to do bridges "properly" (ie, destroyable) but has also allowed me to create doors, something that I have been sorta wondering how I was going to pull off.

A closed door disallows movement:


With the door open, Crusoe is free to move on through:


The door is implemented as 2 objects: a door frame and a door. The frame is stored in the newly-added AuxID field of the hexmap. The door object is stored in the normal ObjectID field. Both objects subscribe to the Use event. The doorframe stores the ID of its associated door object, so that when it receives a Use event it sends off an Activate event to its door object. The door object listens for Use and sends itself a Deactivate event.

The door object is animated to slide up and down upon activation/deactivation. It also removes itself from the ObjectID slot on deactivation, and re-adds itself upon activation, alternately exposing itself and its doorframe to targeting. The door object is combat-enabled, so it can be destroyed. The frame can be combat-enabled, but there is no point; I simply stash a handle to the door frame in the door object, and upon receipt of a Die event, the door will send a Die event to the door frame as well, removing both objects when killed.

It all works great, just as the change to bridges does. I do get the feeling that I am storing up some technical debt to be handled later, though, in the form of revamping enemy AI in order to take into account doors and bridges and their ability to be destroyed. It has repercussions for targeting (be careful how you target AoE spells, or your defenses or escape routes can be caught up in it), for pathing (do I risk going on the bridge if it leaves me vulnerable to being stranded?), and so forth. Still, the changes are very welcome, and thanks to Servant and Eck for getting my thought processes moving.