Visualizing the Future

The last month hasn’t been idle time. I’ve been working towards TransientVisualizers (think animation sequences for certain splashy actions) being associated with certain server-side model activities and being transmitted to the client where they can rendered. I’ve added support for “literal” brush keys, in which the key name represents a solid color or a linear gradient (horizontal or vertical) so that I can encode fail-safe animation colors without having to have mapped brushes defined (in Ikosa packages) for the models.

I’ve also added a storage area in the map for holding transient visualizations for the current tick. When the map time changes the transient visualizations are cleared (hence: transient). This storage area is accessed by an operation contract in the visualization service contract. Well enough to have a place to store and retrieve visualizations, but I also added bits to the power definitions and (by extension) the spell definitions for supporting animation types based on targets and animation style. Turns out that not too many spells (in the 0th to 2nd level range) require flashy animations, as some of them are buffs, divinations, “invisible” effects, or create persistent (not transient) objects such as dancing lights.

I did add one new type of animation over my previous set: namely a flying orb that moves a sphere from point to point. I already had a flying “bolt” (ray bolt), but there are some low level orb-spells that are necessary. I bound animations to the spells that needed it, and fixed a few power and spell issues I noticed along the way.

Finally, the past week or so has been fixing some client-side items (and server-issues that led to them) related to icon imagery, which I never implemented in the client (despite being the reason for doing all my flat XAML icons), but now have.

My next bits of effort are in surfacing wand and spell action selection and targeting in the client (they are defined and should be “working” server-side) so that I can test and fix the animations that should be bound to them.

Evolution of the Greatsword Wielder

Original GSW:
Early Meta-Model GSW (fragments and textures):
Current GSW (tweaked-up conic sections from HelixToolkit):

One MeshGeometry3D to Rule them All

I finished off the PanelCellSpace a few weeks ago, and got it pushed through to the service host, proxy client and client UI. One thing I noticed (since I was testing in a large outdoor space) was that the performance was absolutely crappy (client-side…the workshop rendering was mostly OK). I wanted to fix this right away; but knew it would take profiling, though spending $500 around tax time wasn’t a viable alternative. Thus I had to improvise.

Enter good old Debug.WriteLine() statements with timings. I soon narrowed down a major performance problem to calling the full map rendering method 3 times. Basically when anything changed I was redrawing the entire map, locators (game tokens) and overlay graphics (aiming cells and lines). By separating those functions and only calling them when needed, I reduced re-draw time from 4.5 seconds (after making a single 5 foot move) to 1.5 seconds. Pretty good, but I was certain it could go faster.

I toyed with several ideas including caching full frozen Geometry3D models (per thread), and having other mesh collapsing optimizations. I finally settled on an approach of rather than drawing each cell face into a cell Model3DGroup with copious amounts of (frozen) transforms, I’d build aggregate meshes for cell faces using the same material rather than separate models. I had to replace a parameter in my call chains (and retain the old group for those cells I didn’t want to “upgrade” to the new style just yet), and futz around with collecting cell Model3DGroups and the shared MeshGeometry3D, but the end result is about 0.3 seconds from action start on client, through to server processing and updating, back to notification, collection of new map display data (based on senses) and rendering.


Cell Types

When last I posted, I assumed I was going to work on pillar-type cell spaces next, instead I went for the more ambitious “panel cell space”. In this, the 32-bits of state are used to indicate the presence of panels along each of the major faces, and also the type of face, and also whether there is any internal structure (such as a slope, diagonal or “bend”).

This took a considerable amount of time, since I was basically re-inventing stuff for several types of cell-spaces (corner and lframe), while also making a system that could handle all sorts of variations. I should be done with the server-side representation now, and hopefully will go into testing soon (and some workshop tooling). Finally I’ll need to be able to get the structures available in the service-code and over into the client proxy so client-side rendering can happen also.

Probably be a lot of bug fixes over the next few weeks 😦 But it’s progress.

November Plus

After I shut down the fantasy Kickstarter pipe-dream. I went back to development again. Among last month’s achievements:

  • solid and linear gradient brush definitions (for mapping and models)
  • composite models from model fragments and brushes
  • limited addition of some Helix Toolkit features
  • single axis sloping cell space (and other changes to support sloped surfaces in land movement)

Basically, the latest development build of the workshop now has the ability to define solid and linear gradient brushes. These can be used in brush-sets for cell tiling, as named brush-keys for models, and as for mapping brush references to brushes in composite models.

In addition to changes to the base Model object (for characters and objects) to support brushes directly in the serialized package (as opposed to merely indirectly through images), a new derived MetaModel class has been defined that allows model fragments to be joined and spatially transformed in a conglomerating network of parts. In addition, brushes can be mapped to the parts through another layer of indirection and fallback name resolution.

I have also added some mesh generating MarkupExtensions for cylinders, cones, and trimmings of other meshes, based on Helix Toolkit code. Also, several of the previewer controls (most notably the model preview) use a Helix Viewport for fluid zooming, rotating and panning.

And most recently, I just finished the world-emulation, server-side bindings and workshop editing for single axis sloping cells (where the slope runs along a single axis). I also came up with a polygon generation strategy for linear-planar collisions to more uniformly determine when a line is blocked by a cell. There is still dual-axis slopes to (eventually) do, but I am more focused on tubular cells (such as pillars and “chutes”).


After some final polishing of the rewards (for clarity mostly) and verbage (to add some more of my personality), I have launched.

Kickstarter Campaign

Now the real project begins, being discovered and funded without being flagged as a spamming troll.

Openly Licensed to Game

Finally decided that rather than skirting the issue, the final published Guildsmanship: Battle-Scapes will be under the OGL. What this means for me is to make sure all the Open Game Content (from the SRD) is visibly cited and identified. Putting such a framework inside an existing system is something I excel at (especially since the original system is one of my own design).

There will be (probably) two distinct ways to see the Open Game Content, one will be in context: in which information flowing through the workshop or to the client will be able have citations. The second will be to have an OGL explorer which will catalog list all the OGL information within the loaded assemblies.

The best part will be that I can finally mention the fidelity of the Ikosa Framework in implementing the OGL SRD, without having to cryptically mention “Classic Pen-and-Paper” mechanics.

To be fair, I have slightly tweaked (or enhanced) some terminology and mechanics, mostly for clarity and implementation consistency. I’ll probably describe (as Open Content), some of the specific implementation details for lighting, room topology, package serialization, and perhaps the WSDL (since it’s pretty much out there anyway).

I don’t have an OGL statement visible anywhere yet, but I am not actually “published” yet, either.

KickStarter Image

Since I’ve finally got a semi-decent looking gargoyle, thought it was time to show the model off. The party in this picture looks just a little too happy to be engaged with gargoyles, especially when the guy in the back has no obvious weapons.

Gargoyles are Everywhere

Big Movement

First, my need to code led me to initial implementations of large creature (2x2x2 cell) movement for LandMovement, FlightMovement and FallingMovement. There is still plenty to refine and fix there, especially on LandMovement with rising and descending on variable elevation terrain, and squeezing into narrow spaces; but overall I am quite pleased most work I did on medium/small creature movement has proved useful. Creatures that are huge and beyond will definitely need some additional work to "get it right".

Secondly: I moved to a set of pages that hopefully look a little smoother (and less scrappy) than the Ikosa Framework web-pages I was using before. I still have to repackage the Ikosa test client and test host for the new site, because apparently trying to simply move the junk in Visual Studio isn’t getting me anywhere (which is probably OK, since the deployment URLs are embedded in the packages anyway and need to change). Also the whole thing is lacking in images, and either my pixel guy (my Minecraft addicted teenage son) will get me some soon, or I’ll have to throw some XAML line-work together and rasterize it through KAXAML.

Thirdly: In order to get Amazon Payments setup on a business account, I need to provide a fax of a bank statement. Since I had just opened the account in the past month, I had none. My online access only provided me on the bank’s schedule, so I had to wait. I had no indication on when the bank’s schedule was going to hit, but I guessed at the end of the month…and I was right! So now I need to print and fax (what? is this the 1990s?!?) a copy of my statement to Amazon, in order to keep the Kickstarter thing moving…

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