Brief Update

Today I added trade table recipes for:

• cured abomasum (I did the uncured one long ago)
• rennet
• cheese

It seems that different preparations of rennet or different amounts of labor in the cheesemaking process can produce different types of cheeses. Such factors would be easy to add in for a little variety.

Scratch Paper Ideas

I'm tidying up notes from around my desk. This turns out to be my 50th post!

1.

Costs associated with getting your way. Spend points from (a pool based on ability)?

No. Very story-gamey. But, losing points from a pool which is based on your ability scores *is* fine, so that idea could be used for something. Suppose that if you have a Int/Con/other ability core of 15 that you also have a pool of 15 points which can sustain damage, similarly to HP.

(well actually that's very finicky. Revisiting this one a day later: I don't think I like it, but it's fod for thought.)

Also, spending points from some pool to do something *can* be allowed in limited quantities as part of benefits earned from the skill system. But mostly I want skill system powers to be always-on.

2.

Dice roll probabilities are difficult to estimate, especially for a pool of multiple dice (possibly of different sizes). THe gam can have sophisticated use of random chance, and it may internally be represented by combinations of die rolls, but player- and DM-facing views/interfaces should also display percent chances for failure/success, or for the various outcomes on a more complex type of risk.

3.

Having one die roll determine whether or not you can do X in this situation doesn't work fo rhte fact that many ations are predictably either very hard or very easy.

Thus, most talents shall provide always-usable actions or knowledge (senses!)

4.

*Actions* and *senses*. One is for affecting the world, and one is for filtering the information coming in and determining which of that information reaches the entity.

That's a useful paradigm to think in whether one is making a computer game or running a traditional game. What can this entity perceive and how does that shape its capabiilities? what can't it perceive and how does that present weak points?

Senses are typically things like sight, smell, touch, taste. magic sense, blind sense, tremor sense, and so on. These could take parameters indicating how far out they extend, e.g. vision 30, magic sense 50. Senses will otherwise binary: you have them or you don't.

What about senses like proprioception, the awareness of one's own body and movements in space? Well, no need for anything fancy right away, so we say that normally people have it. for someone who lacks it, a lack of it would be modeled by penalizing a character's attacks, balance on two feet, coordinated actions, amount of action points available, and so on.

Magic sense, blind sense, and other unusual senses can probably just be effective no matter where [...]


It makes sense for the parameter giving the range of the sense to indicate the maximum range at which that sense can be deployed with no errors. Then, calculations be made to detemine how far away the sense can be deployed with misdetections (false positive, e.g. seeing something not there, or false negative.)

5.

Use plain probabilities. 0% to 100%. Store them as ratios of arbitrary-size integers internally, but round down (always!) to the nearest whole percent when *applying* or *displaying* them.

For ordinary tasks that we consider everyday but which could be difficult for others, don't merely assign a die roll chance to pass/fail. Set *ability score thresholds*, and from there set the degree of difficulty (it fmight be automatic or require a die roll.) Maybe two thieves can both pick the same types of locks, but one can go a little faster because of high Int. And so on.

e.g. Open Door [requires one hand, no Int requirement]
takes a certain amount of time based on Str AND may have chance to fail outright afte spending that amount of time
Strength 1-2: takes 10 AP
Strength 3: takes 8 AP
Strength 4: takes 6 AP
5: takes 5 AP
6: takes 4 AP
7+: takes 3 AP

We can also allow for thresholds which are higher than those an ordinary human would have. e.g. a large rock for which the minimum strength to move it at all is 25. IF there is room for a few people to stand near it, they can move it a little. IF ther es only room for one person he'll need super-human capabilities.

Or maybe he just needs to be non-human.

6.

A fact is a binding of a name to a list of tuples List (Predicate, List Components). A predicate takes an entity and calculates True or False based on the entity's qualities (usually his senses, but not always.) If True is calculated, then the Components listed in the Predicate's tail are perceived by the entity which was passed to the predicate. These components are the salient perceptual details of a fact.

One easy way to model "components anyone can perceive" is for the predicate to be a function which always returns true no matter which entity can see it, e.g. the Clojure function (constantly true), which takes any arg(s) and always returns true.

The presence of an entity in a scene is a fact, and it would be detectable by the other entities which had the appropriate senses. But what senses are appropriate? Hm. Perhaps each entity needs to list which senss it's visible by. Obviously defaults could be given.

Thus the relationship of predicates to component lists is like the relation of predicates in a cond expression to their corresponding result expressions, except that

An example fact, in pseudo-Clojure.

(Fact "presence of mushrooms"
     {(#(> (mycology %) 10) "There are GREEN MUSHROOMS here. With your skills you could gather 4 lbs in 8 hours.")
     (#(> (mycology %) 20) "The mushrooms are healthy to eat. You could gather 6 lbs in 8 hours.")
     (#(> (mycology %) 40) "You know how to prepare these mushrooms into a healing stew. 12 lbs mushrooms and 1 hour time to prepare quart stew; one quart heals 1d3 HP. You could gather 8 lbs in 8 hrs.")})

Fact is a crappy name, but all of this is mostly crappy. I'm just trying to put ideas out on the page.

Also, the "presence of mushrooms" fact should be conditional on the entity having the sight sense. Otherwise they can't see the mushrooms. But if one with sufficient mycology were TOLD about the shrooms, they would recognize them for what they were. It's a tricky thing to adjudicate. This stuff is where computer modeling "knowledge of facts" is super hard and maybe not worth digging into. It's a rabbit hole. Fuck.

Recipe - Faering Hull

The recipe presented in the last post is of a small size. Many recipes require much more calculation than soap does (though recall that the definitions for the other recipes that go into it also required their own calculations.)

In this post I'll included screenshots of all of the calculations for the "hull, faering" recipe. I believe this is the largest recipe so far, both in terms of calculation and in number of sub-components.

A faering is a type of rowboat. Since this recipe only calculates the hull, the boat is not complete: there are no seats, no oarlocks, and no oars. Still, there's quite a lot to see, and I'm restricting myself to only those items which are directly being used in the faering hull. I'll show rivets, for example, which are made of copper, but I won't then go and show the copper recipe.

OK. Here is the faering hull itself.



You can see that the faering is composed of many shaped wooden pieces, some of them steamed, and that it is held together with lots of caulk and rivets.

The quantities of these components are calculated in the lengthy sequence starting at the top of the screenshot. It should be pretty readable. I would go into it here but I've been chipping away at this post for a week or two and I just want to get it out there.

Having seen what pieces the hull is made of, and how many of each piece we need, we can look at how each of those pieces are defined. First come the recipes for rivets and caulk, which are used to join the wooden pieces together.



Second and last, we have the wooden pieces themselves. You can see how some of them are immediately used as components in "steamed" versions, which (as seen above) are the ones which actually show up in the hull recipe proper. These steamed variants represent the woodworking technique of clamping a piece in place and then steaming it so that it will hold the shape it currently holds. This is used to achieve the curved sides of the strakes which make up the bulk of the hull.

One minor note: "semiGoods" is the name of the list of trade goods which are not considered finished products. Thus, although their prices get evaluated, they are not ordinarily displayed for sale on the trade table.

The Recipe System

Previous posts have addressed the establishment of references to raw materials ("mats") and to various types of artisan, craftsman, and laborer ("services") in the game world; the manner by which importing is done from city to city so that each one ends up with at least a little bit of everything, both mats and services; and how an increased distance from a source for a mat or service X lowers its availability and thus increases its price directly (mat) or increases the price of all goods which are created by a given type of worker (service.)

What we are still missing, however, are the components of the economy system which take us from the finished import step (where the relative availability of mats and services is known for each city) to the price tables which I have posted here (for the most recent version, see this page.)

Those components are the recipes themselves and the algorithm by which a recipe's price is determined. This algorithm takes into accounts the mats and other recipes that go into the recipe, and the service that creates it.

Let's start by examining the structure of a recipe: that of a bar of hard soap.



The name of the recipe is self-explanatory: this is hard soap.

The first item after the parenthesis following Recipe is the type of service which produces this recipe. This is the chandler, who makes items from fats. (Come to think of it, I don't have candles in the system yet. One more thing to add.)

Next, we have a tuple consisting of the variable weightOneBarSoap and the unit, "lbs", by which its weight is measured. "weightOneBarSoap" is calculated by multiplying the desired volume of the bar of soap times the density of tallow. I use the density of tallow for that calculation because it's the principal ingredient in this soap recipe and thus it's OK if I use it as a proxy for finding the actual density of the soap mixture. This stuff doesn't have to be perfect.

Next we see two lists, denoted by square brackets. Each list is made up of 2-tuples, with the first element being a name, and the second being a quantity of the material named.

The first list is of the raw materials ("mats") which go into the recipe. In this case we only have salt. You can see that the amount of salt is calculated on the basis of how much tallow is used and how large the finished bar of soap is. If the bar were 1 pound exactly, we could eliminate the latter factor.

The second list is that of the other recipes which go into the soap recipe. Most manufactured products are not made solely from raw materials. Instead, they are composed of other, less-complex manufactured products. Therefore, recipes can be recursive: they contain other recipes inside themselves. (Eventually all things lead back to raw materials, or else there would be no end to the chain of recursive calculations.)

Finally, we have a description which gives additional details. Other recipes also include units in addition to their weight (for example, lengths of yarn give the number of feet per one-pound bundle.), and difficulty (something I'm still working on fine-tuning). The default difficulty is 1.

In the above image I've left out some of the calculations which go into the soap. Below I show all of them. You can imagine how lengthy a more involved recipe gets. Let me know if you'd like to see anything else from the trade page.



I'll stop here for now: if I kept writing today, I wouldn't end up posting at all. I'll discuss the algorithm which interprets a recipe in a followup, but the basic details are simple: find the price of all the raw materials and all the sub-recipes. Sum them together. Multiply by a factor which gets larger for recipes with a higher difficulty and if the service which produces the recipe is scarce in the town for which the price is being evaluated. Done!

Time Spent DMing

As part of his latest post, Alexis challenges DMs to estimate how long they have spent working to become a DM. Below I do the calculations to estimate for myself how long I've spent actively DMing and working on the game.

I ran a bit on and off from 13 to 15 but none of it really stuck, so I won't count all that.

I'll start from 16 and my first group of serious players. At first I was running a group of 8 to 12, often one session Saturday and one Sunday with some players attending both games. I'll say each running was 5 hours, that's 10 hours per weekend for ... about 4 months, so 160 hours. Let's say prep work took half that amount of time spread out of the rest of the week, so multiply by 1.5 and we get 240 hours.

The group thinned out to about 6 people and we started a new campaign, that was probably another 6 months, and I did a more meticulous job of prepping I would say, so let's say 5 hours per weekend plus 7 hours prepping = 12 * 4 weeks = 48 * 6 months = 288 hours. That campaign might have been longer, maybe 8 months? 10? but it definitely didn't reach a whole year, and I know it had a definite conclusion since that's how I did things back then.

I ran another campaign, timing probably similar to the previous one, let's say another 288. Running total is now (+ 288 288 240) 816 hours.

Let's increase that by ... 10%. Call it a round 900. That's to account for the fact that so much of my time even when not specificaly prepping for campaigns, was also taken up by D&D books and forums and blogs.

OK, then college. Fair bit of gaming but not much DMing first year. Second year, 2013, we gamed the whole first semester, let's say a total of 10 hours a week between the long sprawling game sessions and writing and rewriting tons of rules, and fourish months in the semester, so 16*10=160 hours, which sounds way too low but is probably right. Running total 1060.

[War story aside: I was dating my first girlfriend and running her and her crop of friends plus my buddy Jonas and it was a huge blast. I look fondly back on those days. The game was kooky: characters included a bio-syntha-cyborg and a lady minotaur alongside thieves and wizards, and each class rolled random upgrades at each level up (kind of like sage skills in a way.) On the design side I was working with a concept of giving EVERYTHING levels, so cities would have levels based on their size which would determine the availablility of items and the possibility of placing bulk orders; artisans and craftsmen would have levels indicating how good their product was; whole areas had regimented arrays of themed random tables plus bleedover into other areas. It wasn't at all what I would run today, but the guiding principle worked.]

After that I didn't run for about three years.

I picked up again in the fall of 2016 and ran weekly sessions of about three hours each for about 7 months all told. Let's say prep specifically for the game as opposed to more generally working on D&D was the same amount (was almost certainly more but I want to be conservative.) That's 6 * 4 * 7 = 24 * 7 = 168 hours. Running total (+ 1060 168) 1228 hours.

OK. That's all the game sessions and prep specifically for them. But what about all the additional time, especially since Fall 2015, which I have spent working on my computer programs, writing my blog, and researching?

I do track on a daily basis whether or not I worked on D&D that day, and I have compiled some statistics and graphs to show how the habit evolves, but I haven't plugged data into those calculations recently and it would take a while to do so. Furthermore, they don't track the exact amount of time spent. I can, however, confidently hypothesize that since November 2015, I've spent a minimum of an hour a day on average working on D&D. It's an educated guess so let's use it. The duration since Nov 2015 to today, 2017-09-25, is 5 days short of 1 month shy of two years. The exact number of days is (+ 365 (- 365 (+ 5 31))) = 694 days. Thus, 694 add'l hours.

The final total is 1228 + 694 = 1922 hours.

Good exercise. It reminded me how far I've come.

Chugging

Forgive me for the lack of updates in the last two months. I've been preoccupied with finding work, my game has been on hiatus since June or so, and furthermore, because I was feeling a lack of direction in my projects, I gave myself permission to stop thinking about D&D entirely for as long as I needed to get my groove back.

A week or so ago, after a break of about forty days, I started working on D&D projects again. As my game will be starting up again soon, with a party partially or entirely composed of all-new players, I decided it was finally time to set my game in the real world.

I've decided to start the players off in Moravia, a land which is now part of the Czech Republic, and I've chosen 1650 as the starting year (because it will allow me to make use of resources Alexis at Tao of D&D has created, especially his detailed maps.) And even though I've only been researching for a short while now, to my delight I've found no end of details on tnis area which are immediately gameable.

For example, look at the Wikipedia page for Castle Bludov. It was destroyed about 200 years before my game takes place, leaving only cellars and moats.

What do you suppose might have moved in during the intervening two centuries?

This example may seem a little pat, since "abandoned structure which has been recolonized by monsters, bandits, etc" is a trope. But to me, this feels different because I am not making the castle up out of thin air. Because the ruined castle is real, the rest of it will seem more real as well -- or so I hope.

Finally, let me update you on my other projects.

I've begun rebuilding the economy program, not only because the data will have to be changed from that of my made-up world to that which I am scouring from my 1921 Colliers Almanac and from material Alexis has provided on the matter, but also because the current program has many dead parts baked into it which are leftovers from previous iterations (such as, for example, placing cities randomly on the map and assigning them goods and services based on their hex's climate, then connecting them by semi-random networks of roads. None of this panned out in practice.)

The "character GUI" program has been placed on hold. I've made no headway there. I am, however, planning to dabble in computer graphics, to see if I can make an interactive version of the kind of world maps I've posted here before.

Finally, I've been working with a game designer friend on some prototypes for different kinds of game logic. Nothing has borne fruit so far, but some of our material has gone along directions related to the "spellpower points" magic categorization system I talked about here, so I thought I'd at least mention it.

Graphics Upgrade

Today I upgraded the graphics of the GIMP image which I use as a combat map for D&D. Instead of the previous colored dots, I made blobby little avatars to represent the characters, and I drew depictions of all the weapons used by the current party and their hirelings, including dagger, shortsword, longsword, greatsword, bow, mace, and quarterstaff. I gave weapons to the characters whose weapon choices I know off the top of my head.

I also drew a hex-border with a blue and orange gradient. This is the casting indicator, to show that a character is casting a spell. That way, when someone announces they are casting, I can just flip the indicator's GIMP layer from hidden to shown. When they're done I hide it again.

Finally, I used a clock emoji to design myself a large, colorful, in-your-face "stunned" indicator. The drop shadow and flat color help it stand out.

Here's an example picture. Note that I haven't completed the hex numbering just yet, as it gets a bit tedious. I'll have it done in time for Saturday's game session.

Hireling mercenaries Oswald and Aymar; illusionist Arvak (shown stunned) and mage Valyria; and avatars for characters who will be made by new players in Saturday's game.

Big Now or Bigger Later

I'm noting that a mage could want to recreate all their X-level spells at their max possible spell power. For example, a 1st level mage would create a 1000 SP Magic Missile spell, with 3 Missiles from the beginning. Even if the wizard is higher level, it can be a boon for one's apprentice, and would very soon replace the Magic Missile spell.

The above is excerpted from Vlad Malkav's comment on my post about spellpower.

As usual, Vlad, you're asking good questions. You've raised an excellent criticism here.

Let's get one thing clear above all else: once spellpower and spell-creation rules are firmly in place, spell creation would absolutely not be available to first-level mages, as you indicate. Think of spell modification and creation as authority- or expert-tier abilities in Alexis's sage system. Maybe even sage-tier for spell creation: it's a big damn deal.

That being said, the core of your point -- that a more powerful mage would create a spell which has its powers maxed out already, and pass it on to others -- is completely valid. Off the top of my head, the solution I would use is that damage (or other effect) dealt by the spell when first acquired, without any scaling, would cost X, and damage dealt by the spell as a result of level scaling would cost less than X.

For example, let's take Magic Missile again. Setting aside all other factors to focus on damage, let's suppose that the 1d4 component of the base damage costs 250 (100 * 2.5, average result of 1d4), and the +1 costs 200 (100 * 1 * 2). Because the fixed bonus is more reliable, its price is doubled. This gives us a final result of 450 SP for Magic Missile's damage component.

Then, let's say that for scaling, each d4 and each +1 costs 1/2 of normal. Thus for each additional 1d4+1 missile, the increase in cost would be (2.5 * 50) plus (50 * 1 * 2) = 125 plus 100 = 225. Thus, with two missiles the total damage SP would be 450 + 225 = 675.

You can see where I'm going with this, no? Let's create a spell called Arcane Blast which is still within the (totally hypothetical) 1000 SP minimum for 1st level, but which starts out with two missiles, no scaling needed. Then its base cost is double that of Magic Missile as written above: 450 * 2 = 900 SP.

Now here's the trick. If we continue to assume the 1000 SP ceiling for level 1 spells, then Arcane Blast could not gain another missile through scaling, since that additional 1d4+1 missile would cost 225 points, and 900 + 225 = 1125, which is greater than 1000. (Note that it could gain another +1 damage through scaling, since that would cost 100, putting it exactly at 1000 SP.)

On the other hand, by the above pricing scheme, Magic Missile could gain a third missile. Two missiles was 675 SP. Add another, at 225 SP, and we end up with 900 SP total. Hell, there's still room for another +1 damage, too, just as above with Arcane Blast.

What this all is going to boil down to is a bunch of adjusting variables and price-per-each-variable-from-base and price-per-each-variable-from-scaling. But the above tradeoff (two missiles now vs. three later) is a prime example of the kind of discussion this deepening and codifying of spell logic can produce.

Imagine: the PC mage who invents Arcane Blast has to decide whether to teach that or regular Magic Missile to his henchman-apprentice. Arcane Blast will keep him safer up front and it's only a first-level spell, but with no way to retrain them, isn't it limiting his potential later? And what about feuds between mages who prefer the newfangled Blast, with its more-up-front reward, and the traditionalists who preach the virtues of delayed gratification?

Naturally the above scenarios don't require a spellpower system. The character with the appropriate skills could just come to me and say "hey I want Magic Missile but you get two shots up front instead of three (or four, or five) later." And I could say sure, ad-hoc, and allow it, or say no, ad-hoc, and disallow it. But I think you understand my objection to that kind of thing.

Finally, apart from the above, I want very much to have a deeper logic behind the level a spell is, both simply for the sake of having that logic exist, and for the ever-gratifying feeling that there is more to my world than the players perceive. This is just like how I want there to be a deeper logic behind how items are priced. That's why I follow in Alexis's footsteps and make my own trade system, right? Same idea.

Tattoo Recipes

Today I spent several happy hours working away on adding tattoos to my economic system. Last session my players, having arrived in a port city, were excited (among many other things) about the possibility of finding a sailor who could give them some. Since I recently programmed the recipes needed to produce paper, I was already mentally ready to spend time work researching ink, so a lot of the time today was spent looking into pigments, binders, dyes, and mordants, and looking for historical information on the production of same. A good chunk of that time was spent looking in vain for some example ratios of pigment, binder, and water for pigment-based inks; in the end, for the red/yellow (both ochre) and blue inks, I had to guess.

Afterward, having added black, red, yellow, and blue inks, I was ready to figure out how to price a tattoo. It was natural to decide to price by the square inch, and almost as easy to conclude on three difficulty categories for pricing: geometric (lines, shapes, and tribal patterns); lettering; and figure.

What was tricky was figuring out the volume of ink actually used up in the tattooing process. I looked far and wide, but the techniques of tattooing are too complex for there to be a simple "this many milliliters per square inch of skin" guideline. What I ended up doing was treating the "depth" of the square-inch unit tattoo as being one one-hundredth of an inch deep. This gave me a volume of ink used, which I could then convert to pints of ink. Shazam: my game has prices for three styles of tattoo in four colors (though I've just now realized that so far they are all single-color tattoos, and I should decide how I'm going to treat tattoos with multiple colors in them. Do I price them as multiple separate small ones? As one big one, and as if it used all four colors equally? Should multi-color tats have a higher difficulty? And so on. In practice, these questions are simple enough to answer logically at the table as necessary.)

Now, my players can design an image to their heart's content (or scare up something cool from the web), measure out its area, and be rewarded by having it added to their characters' bodies. The more exacting they are as a real-life designer, and the more spendy they get in-game, the fancier the tattoo they can have.

Or to put it another way ... tattoos are a new kind of goal that players can aim for in my world.

Spellpower

One of the projects I plan to undertake -- though not at this time -- is to establish a method for quantifying spell effects (by number of targets affected, duration, magnitude of damage or other effect, range at which spell can be cast, and so on) and apply this method to the existing spells. I want to do this so I can compare the relative strength of spells currently considered to be the same spell level. Let's call this quantified spell strength "spellpower."

Once I can perform such a comparison, I can set quantities of spellpower which mark the border between first- and second-level spells, second- and third-level spells, and so on.

The reason I want to do so stems from the fact that some spells, as they are written now, provide a measure of scaling based on the caster's level. To take a well-known and classic example, the traditional Magic Missile spell produces 1 missile of 1d4+1 damage at 1st level, two missiles at 3rd level, three missiles at 5th level, another at 7th and finally another at 9th. Thus, Magic Missile remains a useful first-level spell even when the character has gained a lot of experience.

But why does this scaling of the effect this go as far as 9th level, and no further? That's the question I want to address: once I've quantified how much spellpower each additional missile is worth, then once the point threshold for a 1st level spell would be exceeded by adding an additional missile, the spell has reached its maximum capacity for scaling. To wit: suppose that my calculations determine that the cap for 1st level spells is 1000 spellpower, that the single-missile version of the spell costs 400 points all together, and that each additional missile costs 300 spellpower. Then, the spell would scale to 3rd level (one additional missile: 400 + 300 = 700) and to 5th level (two add'l missiles: 400 + 300 + 300 = 1000) but no further, as additional missiles would exceed the first-level cap.

In addition to the above usage, quantifying spellpower will also lay the grounds for player mages to construct their own spells, first by modifying existing ones, and then by creating wholly new spell recipes ... all at some cost, of course.

Obviously some experimentation will be needed to determine appropriate spellpower thresholds, and once that is done, there will naturally remain the large task of modifying spells which ought to be of a certain spell level so that they are reasonably close to their brethren.

Beer and Ale Revisited

The question of digital character sheets is kicking my ass. Modeling a character as a chunk of data: sure, no problem, I can do that in any language I care to use. The GUI part is all-new to me, but I have at least a stopgap solution for use with Python, the language I am currently coding in.

But the live-update part? That's trickier. I have an idea formulated which I'll code up soon, maybe later today, but for now it remains larval.

In the mean time, I can talk about what I did work on today. I fixed some issues with the pricing of alcoholic goods (so far: beer, ale, and rum) in my recipe system.

Previously, the recipes by which the prices for these goods were evaluated were written such that they were priced on the basis of the unit by which drinks are sold, such as the pint. However, this is not how production of such beverages actually works. They are turned out, not by the pint or by the gallon, but by the barrel. Since this is a game, I can stipulate that all barrels are alike, and that a barrel contains 30 gallons.

What I did today was rewrite the recipes as follows:

1. The basic beer/ale/rum recipes were rewritten to price each drink as brewed in a 30-gallon barrel (including the price of the barrel, of course.) The rum recipe was predicated on being priced by the half-pint, so I had to rewrite it completely for 30-gallon production; the others required only minor tweaks. Now, the reality of alcohol being brewed in large batches, instead of gallon by gallon, is made concrete in the recipe system.
2. The recipes which build on the one-barrel recipes, such as "by the tankard" (beer/ale sold to be drunk on the spot, without including the price of a vessel) and "by the bottle" (sold to-go, including the price of a glass bottle), were reconfigured to make use of the new by-the-barrel recipe. This means that now, the realities of a tavern proprietor purchasing a barrel and tapping it for his patrons, or of a brewer buying bottles and bottling his product, are made concrete in the specification of how by-the-tankard and by-the-bottle purchases are priced. These elements were not present before; they were papered over by simplification.

Aside from the fact that real manufacturing processes are more closely represented in the new calculations, the new recipes also lead to slightly more expensive drinks. Conceptually speaking, this is because the cost of the barrel of drink (and the labor needed to operate on it) is now factored into the cost of buying it in smaller units. Let's look at the old and new prices for ale side by side, for the city I had plugged in when making these edits.

Old prices:



New prices:



Not much an increase, granted. But that doesn't matter one bit. Getting it right -- or at least, getting it more right -- is what matters.

Planning for Computerized Characters

The project I am currently planning can be broken down into several iterations on the same theme. I'll try and break it down here, noting that this is not a finalized roadmap, just my current headspace. There's bound to be some overlap and messiness as I sort these concepts out.

Digital Representation

Player characters are represented in a digital format. I do generate character background with a program which takes the six ability scores, sex, and character class as input; however, the generated info is then printed onto paper and used as a supplement to the character sheet, so it doesn't remain digital. Note that for this stage I am only talking about a computational object which represents the character.

The tough parts here include inventory and currently-equipped items. I'll circle back to these.

All-Digital Generation

All of character generation save for the initial 6 dice rolls, rolling for HP (class and mass), and probably something else I'm forgetting, are handled digitally. While, again, the combination of character background traits is already generated digitally, this stage would at minimum require me to program the computer-logic versions of ability score lookup tables  like these. At the most basic, these computerized versions would allow for the generator to automatically include ability bonuses (e.g. +1 melee attack for a high Str) for easy reference.

Live Updating

So I upgrade the character generator to create a complete character, not just their background, and that includes looking up ability-score bonuses, as above. So what? Here's what: suppose a character gets hit by a spell which lowers their Strength. Using a "communication mechanism", I will discuss shortly, the character record is updated to move their Strength from 15 to 11.

Now what we want is for the bonus on the character sheet to change to reflect that drop (using my tables, that would mean going from a +2/+1 melee attack/melee damage to +0 on both.) That means writing code to monitor the ability score, and when it changes (through said mechanism), making the appropriate values drop. This in turn would require dropping the character's current total attack bonus, no? There's a cascade of effects.

And of course we'd have to be careful not to write the code such lowering one's Constitution into a different bonus-HP bracket wiped out the bonus HP earned for HD from previous levels! Oh no!

"Communication Mechanism"

When I say "communication mechanism" above, I am referring to some way of reading and writing  the data in the character record.

The end goal looks a little like this: I send the message "Arvak, thirty foot fall, soft ground, 45 degree angle, jump was not intentional" to a controller program which can read in data for my players' characters. The controller fetches Arvak's data, and then fetches the computer-logic form of the falling algorithm. It tests the appropriate conditions, it rolls the appropriate dice, it accesses Arvak's Dexterity if necessary. It outputs the damage to Arvak and writes the change in his HP to his record, and therefore to his computer screen.

All of the above is possible to construct. I am describing here a domain-specific language (DSL) in which game actions can be expressed and their results applied to the computer records which represent game entities.

Suppose I code the message "decrease HP." This message (function) requires someone who will have their HP decreased and an amount to decrease it by. It returns the modified record. No checking is done to see if this kills them. That is the province of  part of the update system, which sends the "die" message to entities whose HP drops below -10 (or -4 if they're unleveled -- see, we have to track these things.)

Consider where we can go from here. We can write a more advanced message, "decrease HP with respect to damage reduction", which internally uses "decrease HP", but checks to see if the person who is to lose HP has any DR, and if so what type it protects against -- and then all of a sudden we need to know what type of damage is being dealt ...

You see that there is a shitload of complexity here, no? That's why I have to start very very simple and build big stuff out of small stuff. Start with a "decrease HP" primitive message that doesn't give a flying fuck about the rules for death, or DR, or temporary health, or whatever. Now, we DON'T want to use the basic "decrease HP" message for real: we'll build more sophisticated structures on top of it, like "decrease HP as a result of some-damage-type with respect to DR" and then we can build "deal fire damage" as a specialized version of that, and then we can build "deal variable fire damage" as a specialized version of that ...

And then things start getting really interesting, because we want to start thinking about locations. Areas. Zones. That's going to require the next huge shift, the one I've been trying to get started for years but haven't found an entry point: representing THE GAME WORLD digitally, the places and locations and the positions of the characters too. (That's beyond the scope of this post, though.)

Once locations exist -- and we're talking maybe 5 years from now -- then we can express the message "deal variable fire damage as a function of the mage level of Entity A to all entities in the area encompassed by the circle starting at the given point and having a 40 foot diameter."

Perhaps you know that one as "Fireball."

A Note on Intentionality

My philosophical goal while considering and while building these systems is as follows:

I decide whether a rule applies, and if it does, the computer calculates its effect.

Consider the example above, with dealing damage to Arvak because of a fall. Don't you, reader, think that whether or not Feather Fall has been cast on Arvak, should affect the algorithm's decision?

Well, yes, that's the ideal, but the concept of reifying spell effects as messages is, as I've alluded to above, many years off.

Luckily I'm a DM and I can just say, "You've got Feather Fall so you can fall that distance no problem, it'll take this long to drift down gently, no damage is suffered."

No need to run the falling damage algorithm and see if anything happens, because as a DM I know when certain rules override each other.

At the end of the day, all I am really trying to do here is codify, in a programmatic way, the rules that run my game, so that I can give myself the option of shifting the execution of rules to the computer when convenient. As the system grows more sophisticated, I allow it to do more of the "decisions" (i.e. checking rules interactions) so that I am not above the law.

Wrapup

Well, that all turned into a bit of a whirlwind tour of where my head is at, no? Vlad, you left the comment last time that sparked this post. What do you think?

All of this starts with digitalized characters. Once characters are digital, once entities are digital, then I can write a system that manipulates them, that codifies game actions into algorithmic form, along the lines of the "message" metaphor I've been using here.

And one day, one day, one day, I will have a spell list that works on the message system, too. And I have BIG PLANS for that.

But those are beyond the scope of this post.

Whew

After a year of work, I am happy to say that this week I successfully defended my thesis. In my research I was primarily concerned with gathering empirical data regarding a particular question construction in Mandarin Chinese, and the results of my collections show the necessity of expanding current syntactic theories regarding this type of question.

My big thoughts about human-computer hybrid D&D have not left my head, but I've done plenty of talking the talk, so it's time to start walking the walk. I don't want to promise anything, but I know that if I don't work on this stuff it's going to drive me nuts. It's just a huge problem, you know? Figuring out where to start has been tricky, but I think the way in which I can improve my current game (has been on hiatus more or less since April, but starting up again after graduation) is to begin with data models of the player character, and with the "21st century character sheet", i.e. a webpage user interface which (a) displays character information in real time [although without any concept of rounds or turns yet], and (b) can be sent commands by me (and later by the server) in order to add stuff to inventory, represent spell effects, etc. This allows me to concentrate only on stuff will immediately provide value to my players while still working on a fundamental piece of the world-model, and while still getting me to dip my toes in such topics as dynamic website design, databases, user authorization ... though of course the bulk of the work will be encoding many of the game rules regarding player characters into code constructs.

Plenty to do just on this topic.

A Note for My Players

My friend Alexis has convinced me to use his system of sage skills while running my game.

In light of that, and in preparation for Sunday's session, I am posting the sage skills appropriate for each character in the campaign.

Obediah: http://tao-of-dnd.wikispaces.com/Assassin+Sage+Abilities
Volker: http://tao-of-dnd.wikispaces.com/Druid+Sage+Abilities
Lloyd: http://tao-of-dnd.wikispaces.com/Cleric+Sage+Abilities
Arvak: http://tao-of-dnd.wikispaces.com/Illusionist+Sage+Abilities

Please find a little time before Sunday night to look at the page appropriate to your character class, browse the fields and studies there, and think about what sounds good.

A "field" is a grouping of studies: for example, the druid has the fields of Animal Life, Earth & Sky, and Plant Life. A "study" is an area of knowledge containing multiple different skills, which can be gained one by one as the character gains knowledge points. For example, the druid field of Animal Life contains the studies Amphibians and Reptiles, Birds, Bugs and Spiders, Golems, Mammals, Sea Life, and Slime Molds.

Each study gains points as you level up. Every 10 points, you get to pick another skill from that study.

To start off, you get to pick 1 field to be a focus: studies in that field will increase at a medium pace, and the rest will be slow (for now.) Furthermore, you get to pick 1 study within your focus field to be a specialization. A specialization starts off with 10 points, meaning you immediately gain one skill from it, and it will increase even faster than other studies in its field.

See you Sunday.

Another Round of Item Prices

I was sitting at a hundred and ninety-something recipes in the trade program for a week or two until this week, when I hunkered down and added some things which I'd had to make up ad-hoc weights for last time. Now I am past 200 items inside the table's workings, which is the milestone I set myself for making this post.

So: here is the current trade table, for the market town nearest to the party. (I've also attached screenshots of the version at the bottom of this post.)

Some of the 54 new items since the last time I posted a trade table listing include: coat of plates, half- and full-plate and their component pieces, hide glue; arrows; the bow and its components (which necessitated detouring into the hide glue calculation); two types of ladder (which was related to a revamp of the climbing rules); two types of salted fish; tobacco and a pipe to smoke it with; new types of metal.

Restructured old recipes include splitting beer and ale into "by the gallon," "bottled for carrying along with oneself," and "purchased to drink immediately." I also squashed several bugs associated with the pricing of leather objects, including leather armor, making those items much more reasonable to purchase.

Players Wanting Revenge

Alexis has a new venture: comics. This one perfectly captures what players like to do with their time in the game world.

Goat took your pouch? Burn it. Hireling fucked up? Fire him. Those guys shot at me? Shoot back!

When the party is wronged, they like to punish people! They'll want to get those fuckers!

When in doubt, the DM can always make a fight personal, and then capitalize on that emotion of indignance. It will drive players to jump into action.

Just be careful not to stir it up all the time. Any emotion will get stale if it's overused.

Ladder Recipe

I'm finishing up adding a wooden ladder to my price table. Sounds simple, right? Have a look at my thought process below, to see what I think about when I add something to the table.

I'm modeling each rung as a carved cylinder of diameter 1.5 inch and length 1 foot.

This is just a plain old straight ladder, so the side pieces are two long planks. I've got them here as 17 feet long each, with width and depth both 2 inches. Distance between rungs is 1.5 feet, so that's ten rungs plus a foot of extra at the top and bottom.

(If you're Alexis, sit down for this one.) I've only got one type of lumber in my game. Its density is 40 lbs per cu. ft. I'll concern myself with multiple types one day, but not now.

Each cylindrical rung: cubic feet is (pi * height * (radius ^ 2)). Each plank cubic feet is obviously 17 * (2/12) * (2/12).

Total the volume, multiply by density of lumber, and she comes out to 42.69 lbs.

Now let's talk gameplay concerns.

If wooden ladders are this heavy then that's just incentive for the party to carry around a rope ladder or climbing ropes instead. On the other hand, I'm making some sorely-needed expansions to the climbing rules so that a wooden ladder is the safest way to climb. A rope ladder will still sway as you go, meaning there's still a skill in climbing one (though it's not as hard as a rope.) Furthermore, if there's nowhere to toss the support hooks, you're going to have to spike it like a rope at the top; in that case you can't climb somewhere you haven't been to the top of. A wooden ladder has no such restrictions.

I originally wrote this post as asking for a sanity check on my calculations (and please do offer criticism.) I was worried that it was coming out too heavy. But now that I've thought out loud about how it fits into the climbing-equipment ecosystem, I'm actually fine with the weight! If the party wants the most reliable way to climb they're going to have to cart one of these suckers around.

Setting Up a Default Hexmap

As of last session I have finally gotten the hang of drawing a map on the computer during play. I've resolved to continue doing this as it's much cleaner and quicker than using pencil and paper, and makes it easy to move things around or copy them when needed.

While preparing for tonight's session, I hit upon the idea of making this new task a little easier by setting up a "default" hexmap, shown below. This way, when I need a new area, I've got the players' color dots set up and ready to go on separate movable layers, and the hex grid is placed against a nice white background for visibility. This is conceptually just like setting up one's preferred LaTeX packages or config files as a snippet somewhere on a hard drive. And I'm more likely to use and grow into this software if I make it easy on myself to do something I will do a lot, no?

Armor Achievement

I did some good D&D work today. I added the coat of plates to my economy program, which achieved a few intertwined goals all at once:

1. write economy recipes for every armor type
2. restyle the traditional range of armor scores (9-3) with terminology I find more satisfying (see below) the armors while retaining the conceptual and linguistic shorthand categories of "leather/mail/plate"

These are the divisions of armor types which I've arrived at:

• quilted gambeson (which must be worn under other armors, too)
• leather armor
• coat of plates
• haubergeon
• hauberk
• half-plate (breastplate plus assorted arm armor)
• full-plate (as half-plate plus fauld and leg armor).

These serve me nicely.
Along the way, I also finally diagnosed and fixed the problem which was making leather armor so goddamn expensive. I was using the square footage of the lamellae for the armor to determine the number of tanned cowhides used, rather than the ratio of said square footage to the leather of one cowhide (50 square feet.) Thus the armor was about 20x more expensive than it should have been.
With that settled, it's now clear that the armors form a reasonable cost progression, all without ever having tried to make that the case. It's quite beautiful, and satisfying.

By the way, I realize now that while I led up to an explanation of my recipe system, I've never actually done a post or posts on it here. That I can fix. It'll be fun to piece it together and pick up where I left off several months ago when describing my zoo of computer programs.

Improv

Having taken Alexis's DMing master-classes last fall, and having been back in the DM saddle for nigh on half a year now (after three years of absence), I've been working hard to shore up my weaknesses. Both the classes and my new influx of practical experience have shown that one of my weaknesses is hesitation. Just plain difficulty with making a decision quickly.

In order to combat this, and in order to get some more experience with performance (which is part of what a DM does), I've signed up for and begun taking comedy improv classes at a local theater. The course runs for two months and next week will mark the halfway point.

I can tell you that I'm having the time of my life. I wish I'd done this years ago! It's incredible fun and I've earned some genuine praise from the instructor and from my fellow students.

So the questions now are: is it working? Is it improving my ability to improvise? Have I noticed an improved ability to give answers to players under fire?

Well ... the jury's still out. But I've got something to talk about that I've been ruminating over.

The group improv principle of "say yes" dictates that one should never shut down an "offer" that another performer makes during a scene. Whatever they suggest, take it and run with it. And whatever you suggest, they take it and run with it. This process of mutual building is key to satisfying scenes and producing laughter in the observers.

This is old hat to any DM who's done even a little reading. Many DMs, looking for advice, have turned to the established theater arts to find it. "Say yes" has gotten its due as a tactic for responding to player inquiries which promotes expression and creativity.

But what happens when it comes to rules questions? What happens when the players want to drink just half a healing potion instead of all of it, and get some benefit?

You've got to say "no," of course.

During a session part of my job is to head off at the pass any player schemes which rely on a lack of understanding of some rule. My game is hard and dangerous -- the players have a healthy fear of falling, for instance -- and I want it that way. It makes the players rely on each other, and it makes the satisfaction of success sweeter when challenges are actual, well, challenges.

What I've been ruminating on is whether or not there's a tension between these two concepts: "saying yes" to preserve momentum and to recognize when the players are on to something, and "saying no" when there's a rule in place and the players have no case for overturning it except to try and sneak some benefit. (To roughly paraphrase the two kinds of input.)

So far my answer is NO, there is no tension. It's just that the different principles apply to different parts of my job as DM. One applies to evaluating player ingenuity, and those interactions with the game world which are more freeform. "Say yes" helps me preserve momentum when the party is on a roll. The other applies to assessing the rules at hand and squashing misconceptions, tangents, or (rarely) deviousness. "Say no" keeps my hand on the tiller, modulating player energy and throwing up roadblocks wherever they get carried away on an incorrect course, one which I know to be a waste of time or invalid.

What do you think?

Rule Zero

I was texting with a player of mine today after they had let me know they'd be unable to come to the game this evening. They recalled that they had been laid out unconscious by a bear's paw in the previous session, a few weeks ago when we last played before the holidays.

Then they said to me something like "I guess I'll see if I have any possessions left when I return."

This struck me as odd, so I asked whether they were used to other players taking their stuff when unconscious. The player's response, paraphrased: "No, but we aren't exactly scrupulous people, and in character there's not much reason for loyalty or camaraderie." Emphasis mine.

This is the kind of stuff that makes me wonder what the hell is going on in other people's games. Am I supposed to believe that my poor player has played in groups where it is perfectly fine to steal from other PCs -- or do god knows what else -- merely because there's no "in character" reason for the party members to trust each other?

 In real life, trust takes ages to be established. However, if a group of PCs decide that they're going to be stubborn about cooperating because they don't trust each other, all that is actually going on is this: a bunch of real-life people who have shown up to participate in a group activity are now sitting around dragging their heels instead of actually playing the game.

To say nothing of some dysfunctional group in which this behavior extends to pranks or theft ... or, god forbid, one in which the DM encourages such behaviors. Who wants that kind of bad blood between party members? What the hell kind of team is supposed to be assembled here?

The reason I don't bother with establishing trust between the PCs is because they are special in the real world. Because they're being played by real goddamn human beings taking time out of their lives to meet up for a few hours a week, who don't have time for Edward to get suspicious every time Peter's fresh level 1 fighter suggests a course of action, just because "we only just met you in the last village back, why should we believe you?" The fact that adventurers are usually solo roamers is a convenient layer with which we support the assumption that an additional party member might be found almost anywhere, when the time comes to add one newly-rolled; it doesn't mean that we have to respect every single truth about interpersonal relations when a new member joins the fold.

[Don't be a fool and assume any of this applies to the party's relations to the world. You want to get to know a barkeep, a merchant, a guardsman and have him trust you? You're going to have to earn that trust. But those guys are all NPCs. They're not part of the PC in group. If you really want to roleplay out the process of people coming to trust each other, in a slow fashion resembling real life, perfect! Many PC-NPC relations are like that. But the party needs to know where they stand in relation to each other, with no questions, no suspense, and no pettiness.]

Let me make this clear, in public, where current or potential players can read it. Rule zero at my table is that if you are an asshole to the other players, I don't give a shit whether it's in character: you will be ejected and you will not be asked back.

That should give players like the one I talked to today some comfort.

Edit: in further discussion my player said their comment was mostly joking, so I removed one section speculating about the origin of such a worldview.

Current Trade Table

This post is quite simple. In the six months since I began this blog I've slowly added items to the trade table I wrote about in the very first post. Recently, I reached and then surpassed 148 items, which is a milestone because it's double the number of items in the original posting.

To celebrate, here is the table as it stands. The pretty version is buggy right now, unfortunately, so this is the less-pretty version. If you are having trouble reading them, click the images for full size.