One MeshGeometry3D to Rule them All
Posted: 2013-04-15 Filed under: Coding, Debugging, Guildsmanship, WPF Leave a commentI 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.
Yay!
Cell Types
Posted: 2013-02-25 Filed under: Coding, General, Guildsmanship Leave a commentWhen 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
Posted: 2012-12-05 Filed under: Coding, General, Guildsmanship Leave a commentAfter 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”).
Side-Project Once Removed (or Why I Shuttered my Kickstarter)
Posted: 2012-10-23 Filed under: BattleScape, General, Turn-Based Realities | Tags: Kickstarter Leave a commentLike many developers, I have had a number of side-projects over the years. They usually stay lit through a combination of motivations:
- personal pain point to remove
- desire or need to learn something
- boredom with the daily professional grind
- interest in a particular field
- hope that it will take off like wildfire (and become a software rock-star)
…or any changing combination of these over time. My “current” project has had elements of all of these.
About 7 years ago (or more), I was managing a D&D family game group as the Dungeon Master. Most of the preparation time was spent in drawing maps, planning adventures, and building non-players characters. Most of the game time was spent in fumbling through a slew of paper record sheets, maps, and rule books; basically exactly what I was expected to be doing.
Pain Point
Forcing creativity through a set of rules is the art of any art, forcing creativity through a concrete set of rules is an engineering problem. To truly master being a Dungeon Master (or a player for that matter) one has to have command of a large number of rules, both in the preparation and in the playing of the game. In preparing for game sessions, I was spending tons of time selecting things, cross checking rules, writing stuff up so I wouldn’t forget, creating easy to access NPC and monster cards.
I looked at game management software, but found they required a whole new set of personal disciplines in setting things up, and in playing the game (since the software would become the reference source). Basically with most DM software tools, the DM was an impedance barrier between the players and the (automated) content.
The solution to me was simple: automate the presentation of content (output) and automated the selection of actions (input) for gaming groups. If the inputs and the outputs are being automated, its a fair bet that the processing is automatable as well. At this point, three models were colliding: the game-world, the game-playing world, and my world of software development.
Learning Opportunity
Around the 2005-2006 time-frame, Microsoft was launching .NET 2 and 3. For me, this was an opportunity to learn new things, both from desire and necessity; mostly from desire. In my pursuit of my ultimate system, I absorbed WPF/WPF3D, Open Packaging Conventions, WCF, and PLINQ; and honed many other development disciplines and styles (such as MVVM).
…Bored…
I occasionally got to use some of those technologies and patterns in my “daily-life” (except the WPF3D), but mostly my day job consisted of fixing other people’s over-designed systems, or trying to work through their analysis and design methodologies while still producing value; rather than solving interesting problems with automation. In other words, my side-project was exciting and under my control, other work was fairly rote, and boring; occasionally punctuated with the stress of working through other people’s design and planning shortcomings, without any real power to have executive control of the situation.
Interesting Stuff
My interest in the the field of D&D game automation goes back to my childhood, and also involves a (conceptual) merging of game-world, game-play and software. In some ways, I believe myself (like many others before and since) went into software for game development. I actively avoided computer science during my education, since I figured I’d end up working on business systems (insert irony here).
I went with geography since I could work within an applied computer field on geographic information systems (GIS), remote sensing and automated cartography. I had to deal with geographic data sets, visualization, user interfaces, and working other team members on certain projects.
My game automation system allowed me to use some of what I had learned from GIS and automated cartography, but also what I learned from building distributed systems. It provided me opportunities to work with parallelism, OPC, LINQ, 3D visualization, virtual remote sensing, a rudimentary model of character knowledge and awareness. It also allowed me to treat roughly 960 pages of “core rules” as a requirements document. In short, all interesting stuff, unifying almost everything I knew to make one really cool system so I could get back to running and playing games.
Dreams of Glory
Cue the applause: once I was *done*, everyone who ever played D&D would see what I had accomplished, what was possible with the game system, and would make cool content so I could actually play (not just be a game master). Best, I would be at the center of it all, selling the tickets, answering the questions, planning new and exciting future features, and possibly changing the way FRPG is played forever…
Reality Check
Designing and coding against 960 pages of requirements takes some time. Considering that the tactical rules are fairly detailed and the capabilities many of the subsystems (especially the magic and spell system) are quite diverse, there has been a lot of deep abstractions needed to be pulled from the rules before a system could be built (or while the system is built). Some things, such as light propagation and attenuation had to be constructed from whole cloth. Gravity could not be in a fixed direction. The ability of three dimensional terrain to block attack, sight and magic spell lines had to be calculated for varying topologies.
As an automation system, game assets had to be constructable, storable and transferrable; game-flow based upon who is acting, what they can do, what/who they can do it to, what may happen to interrupt (and by whom), what the target may have to do, and what things continue to occur automatically in subsequent turns, all had to be tracked and applied in the game-world, and transferrable through the network in the game-play world.
Time *is* the Boss of Me
All of this takes time, about 7 years at the rate I have been going; using some evenings, many mornings for an hour or two, some hours here and there on the weekend. Basically using as much time as I had the endurance and family bandwidth to squeeze out from that time where life is supposed to occur when not at work. Space is also a little tight, finding the necessary solitude to work uninterrupted enough is a challenge during the evening and weekend hours.
At about year 4 or 5, the ultimate *end* (rock-star!) looked like it might never be in sight, so I started thinking about how to get more time without being “done” done. I needed something demonstratable (for whom, I was not quite sure, possibly investors). Minimum demonstratable meant closing a loop between clients and server while simulating two or more characters moving and attacking each other; which I finally accomplished by February of 2012.
By then Minecraft had been out for awhile (my son had an interest in it, so I had been aware of it for quite some time), and some big Kickstarter projects had made headlines.
Investment, Bootstrap or Kickstart?
I had thought about the investment route the earliest, but my concern was that it meant giving up some control and that my ultimate vision might get diverted (and finding investors and convincing them).
Bootstrapping seemed more appealing once I saw Minecraft, but I did not have the concept of sandboxing as a fun precursor to full gameplay. RPG setup is distinct from RPG gameplay. I did work more “previewish” aspect into my workshop utilities due to Minecraft inspiration, and have some workable plans for more ad hoc map building (morphable terrain and underterrain being a necessity for certain higher level spells anyway).
Kickstarter seemed like my best option (at least back in March 2012) given that I saw what I was doing as an “artistic” endeavor, or at the very least a labor of love. My wife wanted me to isolate the family from the game via forming a company to limit the liability. Hence I formed Turn-Based Realities, LLC (which took a few months in Pennsylvania), then I had to get a Kickstarter, but that needed Amazon payments, then I needed a video, then I had to write text, then I had to … (I wrote another blog post on this).
I was also a bit diverted by life during that time with a black belt test to prepare for, and a lot of shuttling my daughter to and from her practices with the DCA World Champion Reading Buccanneers Drum and Bugle Corps (she plays the timpani), we live 45 miles from Reading, PA.
I finally hit the right tone in my text, had enough pictures, produced a video, got my son to help with the music and being an extra set of hands; submitted, edited and launched. I pushed a few short postings to various RPG forums (trying not to be too annoying), but I’m not a pushy guy. I got one pledge from a guy I personally know.
My side-project to get more time was becoming such a side-project in itself, and I have no reputation in the RPG world to bank off of. Rather than spend more time and watch absolutely nothing happen, I decided that ending the Kickstarter was my better option.
Where does that put me? 9 months behind, but a little bit wiser. Maybe I’ll work more towards that bootstrapping thing…;-)
There isn’t a manual for this…
Posted: 2012-10-16 Filed under: BattleScape | Tags: Kickstarter Leave a commentDay two: all quiet…too quiet. Sometimes I feel like I’m yelling into the wind, other times like my work is seen as just an idle curioisity.
Lift-off
Posted: 2012-10-15 Filed under: BattleScape, Guildsmanship, Turn-Based Realities | Tags: gaming, Kickstarter Leave a commentAfter some final polishing of the rewards (for clarity mostly) and verbage (to add some more of my personality), I have launched.
Now the real project begins, being discovered and funded without being flagged as a spamming troll.
Kicking it into Gear…Almost
Posted: 2012-10-10 Filed under: BattleScape, General | Tags: Kickstarter Leave a commentOK. Kickstarter has given me the go ahead to run my funding project. (Yay!) Nervousness abounds…I don’t want to SPAM RPG forums, but I need to SPAM RPG forums. Perhaps they will be kind. Is it really SPAM if I am not an automated SPAM-bot? INTJ personality types like myself often reflect, reflect, and reflect (or is that introspect?).
I’ll get another quick once over with a pair of critical eyes tonight, then light the fuse.
Factoring in the Factories
Posted: 2012-10-08 Filed under: Coding, General | Tags: model setup, refactor Leave a commentBeen a while since I’ve just worked on some coding. Kickstarter preparation has been absorbing my time.
Anyway, I want to build a model construction utility, and I want to be able to save the model setup state (not necessarily the final models, but them too) in a package file. However, I don’t want to (be required to) include the whole Uzi.Ikosa assembly where the packaging code currently resides.
Thusly, I begin a refactor process into a new assembly. Untangling the dependencies will be “fun”, since I’ve got a helper class to load related parts as their strongly typed object instance.
Problem is all those classes are defined in the assembly I’m abstracting the code away from. Hence, a factory pattern and a registration mechanism (complete with [static, for now] factory registry).
Openly Licensed to Game
Posted: 2012-09-27 Filed under: BattleScape, General, Guildsmanship | Tags: gaming Leave a commentFinally 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.
Video Killed the Programming Star
Posted: 2012-09-04 Filed under: BattleScape, General Leave a commentBesides preparing for my looming black-belt test later this month, I’ve been cobbling together a video for Kickstarter. It seems my wife was right when she predicted I’d get this off the ground after my black-belt test, mainly due to time constraints (the time constraints of having a full time job book-ended by train rides are what I am trying to overcome by going FT on Guildsmanship). Since I’ve been working on the script, taping, gathering additional overlay video and editing it down (in Adobe Premiere Elements 8), I haven’t had much time to program.
During the one time I fired up the test host and client for capturing head-to-head activity for the video, my son and I had some classic moments.
First, I had a dwarf and a human in an enclosed area. We started taking turns moving, and got to the point where I should have provoked and opportunistic attack. None was triggered. I realized the characters hadn’t been equipped (nor had any class levels added). Doh!
Second, starting again with weapons, armor and a level of fighter each. My son maneuvers into position (he’s got darkvision so can move at full speed through the areas poorly lit to my character’s human eyes), he asks “how do I charge?” Not implemented yet 😦 But nice that he immediately saw what the game should be able to do and grasped just how much like miniature combat I was going for.
Third, I edge past him while he’s wielding a great sword, provoking an attack of opportunity. He hits, I take damage. I try to turn and attack, the F9 attack key is not responding?!? Apparently he hit me hard enough to put me in negative health points. Hence why I need to complete the gamification of the system and provide that kind of subtle “you are dead!” feedback to the user.
