Real-World Turn-Based Reality

Getting started with Turn-Based Realities, LLC is sort of like trying to figure out the rules while “playing the game”. First some history:

I realized awhile back (and only decided to act upon it this year) that unless I invested much larger contiguous blocks of time to my Ikosa Framework, I would never get this vision of automating turn-based realities out of my head. I thought of several avenues (none of which would happen until I made my move) such as getting investor help, producing simple tools, or producing a cut-down game-experience to get going.

In all of those scenarios, my best option has been to continue pushing the coding along until I had a workable demo, or a cut-down game. I became aware of Kickstarter (like many people) earlier this year, and began to see this as a vehicle to “kick-end” my vision.

Deducing the rules (and making the moves):

  1. Kickstarter Account (to use Kickstarter)
    • guidelines suggest Facebook for identity
    • should probably do a video (*sigh*)
    • need an Amazon Payment’s account (alright, now household finance needs isolation from this)
  2. Facebook Account (to help prove I am who I am to potential backers)
    • Now all the women in my life know what I’m up to
    • All of my Mom’s friends think my picture is scary-looking (that’s just me)
    • Change picture (look better in profile anyway, thanks to my non-centering eyes)
  3. Acquiring (branding for Guildsmanship and Battle-Scapes)
    • Would’ve liked to do this via the company, but don’t have that yet
    • Also, setup a WordPress account to track my ramblings…
    • …make is a WordPress premium account
    • Moving ownership of hosted Source Control provider would be good as well
  4. Founding Turn-Based Realities, LLC (so help isolate work from home)
    • Use
    • Wait for State of Pennsylvania to wave magic bureaucracy wand
    • …wait…
    • Alright, done (about a month later)
  5. Business checking account for TBR-LLC (so I can set up Amazon Payments)
    • Find time to set up an account
    • Answer awkward questions about volume of transactions (um, none? maybe lots?)
    • Set up account (yay! TD Bank!)
    • Discover from Amazon Payments you need to instantly validate using online TD Bank service
  6. Creating online account access to bank account (so Amazon Payments can validate the account)
    • Possibly wait 2 business days for online account setup to be finalized
    • Yay! next day (go TD Bank! you are rocking it for me)
  7. Amazon Payments account (to use Kickstarter)
    • Fill in information
    • Validate bank account (business account requires manual validation! and a bank statement !!! ERK, brand new account, I have no statement…)
    • Tax interview not so bad, except the LLC with a single owner is taxed like an individual
  8. Polish up KickStarter Project (and Profile)
    • Video! Ug, but OK
    • Rewards! OK, gaming software is the reward…?
    • I’m a software guy, not a T-Shirt guy! (maybe a fulfillment shop?)
  9. So this is the big campaign before the “Campaign”.

Framing my Work

Just a quick posting that ties together all the various things I use to describe my obsessive development activity:

Turn-Based Realities, LLC (my limited-liability company) develops Guildsmanship and Guildsmanship: Battle-Scapes using the Ikosa Framework.

All pretty simple, actually. Except I don’t like to call Guildsmanship a game, its more of a “game” management system that is playable (semantics to some).


While attempting to sort out the Full Attack Budget issues (which I surfaced to priority while working on making UI for Choice Actions), I started refactoring IFullAttackBudget, which is implemented on action budget items that provide information during a full attack action. My refactoring led me to create IAttackPotential, and an emphasis on item slots (holding slots mostly, but also natural weapon slots) and weapon-heads rather than weapons as in the original implementation.

This seemed to work well for me through two-hand wielding, double-weapon wielding (with a few twists that I had to amend to my initial design), and natural weapon wielding (such as claws [potentially] in a holding slot).

Then I got to rapid shot. It is defined as providing an extra ranged attack, but for some reason I thought it only allowed an extra projectile weapon attack. The distinction is that a ranged attack can be a thrown weapon, and since I was focused on weapon-heads and item slots, holding a throwable dagger (or improvising a thrown anything else) would be blocked because the weapon head’s weapon wasn’t a projectile weapon.

And this will lead to a few further problems with my (new) current implementation…mainly I have to isolate any attack that uses rapid shot from sequence interference; that is, the extra attack should be at “full” attack bonus, not affected by iterative penalties, but affected by off-hand penalties. If the hand has run out of sequential attacks, the rapid-shot attack is still allowed.


I set myself on the task of implementing choice actions, and quickly came upon the “problem” of showing the choices when the action is no longer available. Solved with a LocalActionBudget “Choices” list that tracks the last choices for choice actions (for UI display and default when the choice action becomes available).

But this led me to full attack sequencing (especially with two-weapon and multi-weapon fighting), and all the problems with dropping, quick drawing, two-hand wielding, double weapon wielding, natural attacks, thrown, splatter and projectile weapons. Then trying to build a process to determine whether an attack is allowed, and what penalties apply.

I believe it will all come down to tracking “holding slots” rather than weapons or weapon heads.

Assume the first attack (as a regular action) is with a weapon wielded one handed, and the other hand is free (unarmed), wielding a shield, or wielding a weapon. Without two-weapon fighting turned on, only the one hand can attack, and possibly get multiple attacks if the base attack is high enough. If the weapon is dropped, a new one can be drawn (with quick draw) and continue attacking through the progression. This should be true whether the newly drawn weapon is one-handed, light, or two-handed.

Now assume two-weapon fighting is turned on when the first (regular) attack is made. The main hand attacks, the off-hand attacks, the combatant drops all weapons so that all hands are free, then draws a great-sword (two handed). If the base attack bonus is high enough for iterative attacks can the combatant make a second “main hand” attack even though the off-hand attack was used (assuming no improved or greater two-weapon fighting feats)? If the off-hand attack wasn’t used before drawing the great-sword, could the combatant then drop the great-sword, quick-draw a new weapon in the off-hand then continue with the off-hand attack?

So…not as easy as I first thought. Will take some noodling…