Like 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.
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.
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).
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.
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…
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…;-)
Day 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.
After 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.
OK. 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.
Been 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).