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.


Chugging Away at Documentation

The 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

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