Theme Music and Sprites

I got to hear the first few measures of the Ikosa Theme that my daughter has been working on. Sounds pretty cool, with a low bass line that rolls along (kind of like Interplay’s Descent). It makes me want to cobble together a “arcade-cabinet-mode” version of the host and client.

Haven’t seen the images my pixel master has been (sort-of) working on. He’s a busy teen boy; mostly busy with playing online games. Hopefully I can get him to produce some images for the toolbars (and ribbon) to replace the rotated text I have in the toolbars currently.

Delays

A few days back I ran an initial test with the LocalTurnTracker. Even though the Ikosa Framework is turn-based, I hadn’t really used turn-based tracking yet. Instead I had been doing all my action testing (movement, item slot, and door manipulation) using an alternate mode of operation that I call time-tracking. In this mode, multiple clients can act more-or-less simultaneuously (a read-writer lock is employed to block true simultaneous updates to the game state). The idea is to have this time-tracker auto-pump a single turn-tick on a regular basis (about 6 seconds) if there is no activity, and slow it down if there is pending activity or an “intention” to act. Currently, I don’t have the auto-pump setup, so at least one of the clients has to end the turn, while no one else is using their turn.

Anyway, I fired up a LocalTurnTracker initialized to track initiative. It queues up one roll-check prerequisite for each actor added to the tracker. My first explosion was when I had two clients attempting to send back their results. The service call to set a prerequisite value only uses the BindKey to find the first matching prerequisite, and unfortunately all the roll-check prerequisites had the same key. And then the security kicked in, because the client had to be in the role of the actor associated with the prerequisite, and one of the actors was always finding the other’s roll-check.

That was easy enough to fix, simply make the BindKey based on the actor-id.

Once past that, I ran into another crash on one of the clients (wasn’t running the clients in debug mode). The host was locked with an unfulfilled ActionInquiryPrerequisite, which is a holding prerequisite intended to be cleared after the actor associated with it has acted (or deferred action). Looking at this, I realized I had a bunch of things I needed to re-work in this area; and edge and core cases to ensure I had covered.

So I absorbed what I had coded before (somewhat), overcame the pit in my stomach on hacking through this at this point, and got down to hacking through it…inch by inch. Which is where I am now.

The main complexity is in dealing with delays, and by that, I mean an actor delaying his turn until a future point in time. (And how I get caught up in things that delay me…)