The Theory of Generators (Patreon)

Thought that I'd write up a post about the theory and talk a little about my design philosophy behind the Generator. This'll be the first in a couple that I'll write, with the next couple being available to patrons before everyone else. I'll then post them for all to see, or perhaps have Duncan over at www.randroll.com host them. Hopefully you guys find them interesting, and if there's anything that you'd like to hear me talk about, be it the design philosophy of the generator, my thought process behind parts, or just the way that I DM, please feel free to drop a comment below.

Eigengrau's Generator is not meant to replace a DM. It never has been, and never will. I intend for the generator to augment the capabilities of a DM, and offload the grunt work of randomizing data to a machine. Just like how nobody realistically needs to memorise dates, I don't believe that Dungeon Masters need to prepare street names for every building. It's pointless, dull drudgery that does nothing but bog down the DM with more work.

The Generator is meant to function as a time-saving tool. I spend roughly half an hour preparation per four hour game. This is because I can generate NPCs and buildings at a moment's notice, and know what combats or puzzles I want to use. I usually use premade campaigns, adding my own details wherever necessary. I'm incredibly lazy, but it means that the time that I would spend working on a campaign can be spent working on the Generator; sort of like an investment in future preparations- if I spend three hours working on castles, then I won't need to spend five hours working on castles over the next twenty years! 

The limitation of the Generator being a time saver, rather than the be-all-end-all means that it's never going to be perfect. I develop the generator with the understanding that a machine will never have the same creativity and understanding of the English language as the person behind the screen, and I shouldn't try and outdo that person. That also means that I shouldn't bother trying to bug-squash things that can be solved by the DM reading one sentence ahead, correcting whatever details they feel need fixing. The perfect example of this is my ongoing indefinite article abuse; I get a lot of bug reports that tell me that they came across a apple, or a elf. It's frustrating, I'm sure, but the English language is incredibly complex, and with 50,000 words in the generator, I am unable to account for every grammar scenario. If I happen to be dead wrong about its feasibility, and it happens to be dead easy to implement, I'll do so at the drop of a hat, but I currently subscribe to the Minimum Viable Product theory of technology.

Another aspect of the generator being unable to match human creativity is in the freedom to omit (or add) as much as necessary. My philosophy for the Generator is minimum harm. I don't want to lead the DM down a path which paints them into a corner. This is why I'll never have any outright hostile tavern-owners, or code game-wrecking things such as "a random stranger jumps out and gives you a +2 sword". I want the DM to be confident enough that even if they totally switch off their brain, the Generator isn't going to wreck their game. This is sort of a contingency policy for the above assumption that DMs will read ahead, correcting as they please. I know that some people really love reading out the boxes of text, and they'll just use the generator ad verbatim. This is poor use of the generator (because, as per point number one, it's a time saver, not a brain-turner-offer), but unavoidable, so I might as well code defensively.