Expedition Next
Posted: 2012-03-12 Filed under: Debugging, General Leave a commentOpportunistic inquiry is on target now. I also found that I was sending the inquiry to the original actor, instead of the one that could opportunistically attack.
As far as the missing initiative roll goes, I haven’t been able to duplicate it. Perhaps I noticed it incorrectly…I’ll keep an eye on it.
Next big test: Ending a turn without using a turn (that is, delaying).
Expedition #4
Posted: 2012-03-12 Filed under: Coding, Debugging, General Leave a commentExpedition #3 taught me that in LINQ, you don’t get IEnumerable<???> sequences that evaluate to null. They will always have a value, even if they are empty due to where clauses. Seems pretty obvious, but apparently not to me when I originally wrote the code for opportunistic strike zone geometry culling. Should be fixed now. So expedition #4 will both confirm this, and try to isolate the problems with the missing iniative roll.
Expedition #3
Posted: 2012-03-12 Filed under: Debugging, General Leave a commentFired up the host and enabled both red and blue dudes. (Literally “Red Dude” and “Blue Dude“).
Fired up a client, logged in as Red user playing as Red Dude. I immediately rolled initiative and sent the prerequisites to the host so I could move the window to get back to the client icon on the desktop.
Then I fired up another client and logged in as Blue user. For some reason, I didn’t get prompted for an initiative roll on blue. Just another thing to hunt down. Initiative startup step is probably reporting CanDoStep as true on any prerequisite being ready instead of all prerequisites being ready.
Anyway, expedition #3 is about exploring the phantom opportunistic attack inquiry. Breakpoint is in place.
Opportunity Knocks You Down
Posted: 2012-03-11 Filed under: Coding, General Leave a commentFinally got the basics of turn-tracking running much more smoothly (could still use some better visual cues in the client). After establishing initiative, I moved the creature with the highest initiative.
Immediately, a prerequisite dialog box pops on the client (the server wants me to provide some feedback). No useful data on the screen (a prerequisite for which I haven’t provided a DataTemplate), and no title (I hadn’t put a key or name on it either!).
The host tells the story…I am being asked if I want to make an opportunistic attack. I realize I have provoked an opportunity against myself!
Apparently I hadn’t excluded the actor from the weapon strike zones capturing the location I am moving from. I imagine attacking myself as I leave my own threatened cube.
OK. So I add a filtering expression to the “where” clause of the LINQ. Now I can walk (both actors in alternating turns) until they get to the middle room (within line of sight of each other). About 4 rounds of game-turn time. Then I get another opportunistic inquiry (even though they are a good 40+ feet from each other. I’ll check the LINQ tomorrow in debug mode to see what’s going on.
Delays
Posted: 2012-03-07 Filed under: General, Guildsmanship Leave a commentA 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…)
BattleScape
Posted: 2012-02-29 Filed under: BattleScape, General Leave a commentA few weeks go by…
…not documenting; I’ve been working on code (and being sick one day, and building a trebuchet on the weekends). This weekend: martial arts tournament…spare time is rare time.
Anyway, rather than trying to create a demonstration video of some of the visible moving parts; I decided a playable demonstration of the technology in the Ikosa Framework would be a better use of time. So, I dusted off the BattleScape ideas (player versus player); as it demonstrates some of the nitty-grittiness of the framework. I had always wanted to avoid doing it, as I see BattleScape as a derivative game-product that doesn’t fully use the coolness of the complete automated RPG experience.
However, not fully using the framework has its benefits. I can slough-off the actions for moving furniture around, searching, most skill actions, preparing spells, etc.
While I have biggish open-ended plans for BattleScape, all I really need to kick-off is show at least two game-mechanically modeled actors (controlled by two network connected players) battling each other (turn-based) in a tactically interesting environment. I wanted to build two meaty teams (2 fighters, 2 warriors, 2 clerics and 2 sorcerers apiece), but scaled myself back for the time being to just getting 1 on 1.
Chugging Away at Documentation
Posted: 2012-02-17 Filed under: General Leave a commentThe main reason I haven’t spent much time advertising or publicly documenting the Ikosa Framework was that I’d rather be programming, instead. I have so little time at the moment to code as is.
Anyway http://ikosa.pursuit-of-value.com/ is the “official” Ikosa Framework website. Currently “Technical Bits” has enough so that I can move on from it. I’ve got an image or two floating around somewhere I need to start using.
Ikosa Framework Intro
Posted: 2012-02-15 Filed under: General Leave a commentSince I decided I needed to blog a bit more, I figured I needed a slightly more user-friendly blogging tool than I had been using about a year ago. My last experiment with a blog utility didn’t really end well or poorly; it just started gathering dust.
sageikosa 