Ikosa Framework Tuning
I am making these pages to publicize insights about performance optimizations I used in tuning parts of my CRPG gaming framework. While thinking about what that would take, I realized I’d need to provide a bit of context. That context is provided in the following set of pages; but I hope to eventually get back around to the technical nitty-gritty of optimizations and tuning.
I’ve been an “outliner” for awhile; capturing major bullet points and making sure things “look right” from an abstract perspective. I like to think this has helped me structure my thoughts, and maintain a certain consistency of experience and intention when engaged in long-running and often asynchronous projects like this gaming system.
Originally, the technical optimization, threading and object-oriented programming and design sections were first to be identified (again, that was the purpose of this). When my outlines got to where they seemed to memorialize and structuralize the interesting bits, I started working out how to provide background. I’ve settled on having a section for roughly each .NET assembly, as the assemblies capture the dependencies between the operating concerns that each assembly deals with.
More recently, I have been inspired by one of my rare and spontaneous posts (on MSDCPVMUI) to abstract out one more level and provide a little detail on the design pattern hinted at in my brief abstract.
Classic Pencil & Paper RPG
I was introduced to classic pencil & paper role-playing games (CPnPRPG) in the late 1970s, being barely tolerated in my older brother’s gaming group for a few sessions. I was inspired enough to buy a copy of the AD&D Player’s Handbook, and eventually a copy of the Dungeon Master’s Guide. I had a failed attempt to run a gaming group at my elementary school (didn’t last very long), as running as a DM was never as much fun as being a player.
Also around this time, exposure to my friend’s Atari 2600 gave me the idea of an expandable automated D&D like system; which would have involved some core cartridge and plug-in chips as modules for adventures (there were many children of Burroughs engineers in our neighborhood, so I saw some interesting adaptions of Atari cartridge technology). The whole thing wasn’t well imagined, as I was but a wee lad still a few years from really digging into computer programming; but it was the kernel of an idea I would eventually resurrect later.
My D&D books languished in a box (eventually in a basement) for decades, until my son’s interest in a certain literary wizard (cough…Harry Potter) made me dig up the Player’s Handbook to show him spells. He soon realized that this was a playable game, and since I couldn’t find the DM’s guide, I got updated versions (version 3 at this time) so we could give it a shot.
My brother-in-law had played 2nd edition back in the day, so he joined us, and we also wrangled in either or both of my daughters on occasion to play about 6 characters as they wound their way from 1st through about 13th level (lost a few along the way, but the core character group survived). Eventually, the shear time commitment from me made me want to build tools and data management utilities for helping track and build characters, maps, etc.
The Developer Me
I had been working in a variety of business fields since graduating Penn State; sometimes as a consultant and sometimes as a full-time employee. I have worked in map automation (back in the early 90s), econometric modeling software, insurance imaging, insurance management, financial portfolio management, various management consultant practices making tools and products to support organizational analysis and planning, pharmaceuticals, pharmacy management, learning management and warehouse management. I basically worked on anything with large systems moving large data for large numbers of things (mostly transactional processing, but also reports and management control); often with users as operators, managers or customers.
I imagined the Open Gaming License Systems Reference Document (OGL SRD) as requirement documentation and set to work at first automating character management, and ultimately adventure setting, action and turn tracking. The idea was to have a software system that could help “run” the record-keeping of a gaming group, all the way down to the tactical action and turn-tracking level, complete with effects and modifiers.
Basically I wanted computer RPG to be a reality beyond dice roller and semi-automated character sheets.
Technically I decided to specialize in Microsoft technologies about 20+ years ago. I had gotten MCSD certified at one point, but the idea of continuously tracking and training for the constantly updating MCSD technical requirements (with it’s often flavor of the year taste) wasn’t as appealing as actually understanding business and systems.
Back in 2005/2006 when I started I also wanted to learn a few new technologies (such as WPF, WCF and the OPC), so I started infusing them into the technical side of what I was doing. I also added newer .NET technologies and techniques as they became available (PLINQ/TPL), but I haven’t tried to push my professional expertise into my endeavors (yet). Ergo, I have shied from SQL Server for persistence (even though I have operated as a DBA and SQL performance engineer at times, working with SQL Server since 6.5), and from IIS for hosting (even though I have professional used IIS since NT4 Option Pack 1). Also, while DirectX would provide a better rendering experience than WPF for the 3D world aspect of the system, starting with WPF allowed me to get up to speed faster.
I don’t game much anymore (not really at all), as programming the automation to save me time is taking up all my “free” time, and also because most of my familial gaming group has grown up and gone off to college or the world.
The Ikosa Framework
The Ikosa Framework is the gaming system (engine?) at the core of my endeavors. While it may be one big final usable system, there is still a hierarchy of dependencies and concerns that are encoded in the assemblies (code projects); developed over time and in layers of concerns.
The first concern is packaging (or persistence) by which game world, game state, display assets, and user information are stored and restored between runtime sessions. Anything worth playing over time is worth saving, backing up, restoring, borrowing, and building upon later. The packaging assembly handles this and defines the way that higher level assemblies can participate in packaging.
The next main concern is visualization, which contains definitions and support functions to geometric calculations, and rendering the world and its contents via the Windows Presentation Framework. The same assembly used for workshop tools is used by the client application. There is very little WPF-specific code that has leaked out of this assembly (even though some of the more cell-based geometric processing and Cartesian calculation concerns for managing state and enforcing rules have), so an eventual switch to another (or several other) frameworks should not be a Herculean task.
After that, I had the idea of a reusable generic gaming framework, and thus the “Core” assembly exists. This has very low level code definitions and functional facilities that are not specific to a particular set of RPG rules (though they are strongly designed to support OGL). Lots of mechanics here, not much on specifics. Objects, items, actors, turn-tracking, modifier support, dice, activities, turn-based user-response driven processes and the like live down here.
The Ikosa assembly contains the content-based rules that enable OGL gameplay. Things like items, weapons, spells, character classes, creature types, feats, etc. are defined in this layer, as well as many of the specific interactions and actions needed to enable gameplay.
Beyond that are a series of applications (workshop, host, and client) and utilities.
But first, a little more on the client/server/processing design pattern I jocularly dubbed MSDCPVMUI.
- M is for Model
- S if for Service
- DC is for Data-Contract