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).


Model View View-Model

Finally got (most) of the client-side features back together under a more MVVM-like pattern (still haven’t adopted the RelayCommand style yet…). Now, I can more easily get additional data into the Opportunistic Inquiry Prerequisite dialog, since I won’t have to climb through data contexts and control-bound properties to find the data from the framework. I can just bind it in…

I also inched the “bio” part of my Kickstarter project a little bit farther. Every day I see more and more games on Kickstarter, quite a few of which are sandbox and adventure games. There’s an upside and a downside to that, the downside is in launching my project too late (which is comical to me as I “launched” about 7 years ago with the code, or 30+ years ago with the concept), and getting lost in the sea of games. The upside is that the project funds sought looks like they are realistic to keep the developers eating (which is a requirement of mine as well), without having to work in a factory.


Trade Names

For me, “Ikosa” was always the name of my underlying game-modeling framework. Almost always…in the early stages it was “Icosa”. However, I never intended it to be the name of any game product. Ikosa just doesn’t roll off the tongue. Nor does it imply much about the nature of any game product built on it.

Since I have multiple ideas on how to use the framework, I had multiple ideas of trade names. And these have been through some churn also.

My main motivation (fully automating turn-based pen-and-paper game mechanics for multiple players) is the one I have cared most about. I call that “Guildsmanship”. Of all the non-conflicting names I could think up (with the help of a thesaurus) it is the one that has seemed to resonate the best.

My motivation for Battlescape has been varied. I have gone back and forth several times on whether to push a turn-based team-battle (TB2) system (which doesn’t showcase all the framework features such as searching, disabling, opening doors and chests; versus being able to push out a playable demonstration (with things like various vision modes, lighting, and flight).

Anyway, I settled on Battlescape to get a playable demonstration; versus video captures of the tools. But then I went back and checked the name.

The name “Battlescape” is too loaded with prior products. Hence back to the thesaurus. And the internet. Nothing I found seems to come close to the simplicity of the term (except the very generic TB2: Turn-Based Team-Battles). So I decided to stick with it, and add the unique monicker “Guildsmanship” in front of it to get “Guildsmanship: Battle-Scapes”.

OK. So now I get “Guildsmanship” as a brand-name rather than a product name. What to do about Castle Hackenslash? Punt…worry about it later.


Resizing a C# UNION

I have been testing out the *basic* BattleScape scenario (two creatures in a map with an initiative-based turn-tracker), and noticed a problem with rendering one of the cell-types in the client. At each I was expecting a step, I was getting a block.  Fortunately I knew from the workshop and host that the map cell-data was correct as it rendered correctly.  Also, since the Uzi.Visualize assembly is shared (currently the only bit of code so shared) between the Client and Core assemblies, it wasn’t a rendering glitch.  The problem had to be in marshaling the data between application domains.

For background, I have divided cell structural types into “Template” and “Parameter” parts.  I build cell-structure templates (indexed) that can be used for multiple cells, and keep a list with the local tactical map.  This is the equivalent of deciding what types of bricks I want to use.  Physical characteristics (materials and relative dimensions from cell edges) are stored in the template.  If I want a 1 foot sliver of rock (the rest being air) bound to a face, and a 2 foot sliver of rock bound to a face, I need 2 templates.  The “Parameter” data contains useful situational data, that varies based on the Template base-class needs.  A solid CellSpace doesn’t rely on parameter data for anything, but a SliverCellSpace needs binding face information to know how to orient itself.  Other cell types (such as CornerCellSpace, WedgeCellSpace, LFrameCellSpace and Stairs) need even more data to orient themselves correctly.

To keep room data fairly compact, the room holds information about the room dimensions, and a three dimensional array of structures that holds both the references to the templates, and the parameters, for each cell in the room.  When I serialize the cell data into a data contract for the room, I yield an array of unsigned values, where each value combines one cell’s template index and its parameter data.  Rather than doing this programmatically, I simply used a structure with explicit layout and jammed the fields next to each other so I could read them with an overlapping larger field (similar to a UNION in C).

Herein lay my problem.  When I created this scheme, I was using unsigned short (ushort) values for the index and parameter values, and the complete value was an unsigned integer (uint):

namespace Uzi.Visualize
{
  [StructLayout(LayoutKind.Explicit, Pack=2)]
  public struct IndexStruct
  {
    [FieldOffset(0)]
    public ushort Index;
    [FieldOffset(2)]
    public ushort StateInfo;
    [FieldOffset(0)]
    public uint ID;
  }
}

At some point I found/felt the need to make the parameter an unsigned integer (uint), so naturally I bumped the index as well.  Keep in mind that this re-sizing happened in many more places than this data contract.  And it all worked well in the Host and Workshop (Core assemblies). What I missed was when I refactored the ushorts to uints was the full impact on this structure. What I was left with is:

namespace Uzi.Visualize
{
  [StructLayout(LayoutKind.Explicit, Pack=4)]
  public struct IndexStruct
  {
    [FieldOffset(0)]
    public uint Index;
    [FieldOffset(2)]
    public uint StateInfo;
    [FieldOffset(0)]
    public uint ID;
  }
}

The correct form is:

namespace Uzi.Visualize
{
  [StructLayout(LayoutKind.Explicit, Pack=4)]
  public struct IndexStruct
  {
    [FieldOffset(0)]
    public uint Index;
    [FieldOffset(4)]
    public uint StateInfo;
    [FieldOffset(0)]
    public ulong ID;
  }
}


BattleScape

A 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.