Sunday, April 1, 2018

Expanding Some Vague Ideas

This post is in response to the comments Alexis left on my half-baked post from a few months ago.

1. My item #1 was not about point buy; it was about having an attackable pool of points associated with each ability score which were separate from HP. E.g. if you have 15 CON then you also start with 15 "CON HP". I don't think it would be good for anything at the moment; it was just the seed of an idea.

2) Ignore #2 and #3. Let me re-explain #4.

Think about stealth (and the detection of creatures who are using stealth) in your game. Let's call the person sneaking the "sneaker" and the one who is being snuck past the "target." The rough idea is that the sneaker picks a range to sneak to, and then dice are rolled to see how far out the target can perceive at this moment. If the dice come up equal or higher than the number of hexes to the sneaker, then the sneaker is perceived.

While I was thinking about your rules, I started to think about other scenarios in which a roll is made to see whether a creatue perceives something "sneaking up on them." For example:

      Suppose that that aura of a magic item fluctuates depending on its strength. Magic can only be perceived by a creature with some sort of magic-sensing ability, eg. Detect Magic. To such creatures, a weak item is perceivable from 1d3 hexes away, a medium item 1d6, and a strong item 1d6+2.

This hypothetical rule is very similar to the sneaking rules, except that it's the natural fluctuations of the magic aura which are represented by the roll of the die, rather than the fluctuation of the target's ability to perceive the sneaker. What intrigued me about it is that I can imagine other such perception rules which are dependent on having the appropriate senses: if you have tremor-sense, then maybe a creature of 100 lbs or less can be felt 1d3 hexes away, a creature 101-500 lbs can be felt 1d3+1 hexes away, a creature 501-1000 lbs can be felt 1d3+2 hexes away, and so on.

3) Let me re-explain 5. I was actually hoping to get to something like this on the podcast.

Most (all?) rules are about measuring quantities, and mandating some relationship between them.

For example, "If you have X HP and are hit for Y damage*, your HP after taking that damage is X-Y". That's an obvious rule about the application of damage to hit points. The two quantities are X and Y. (*Assuming damage reduction, resistance, etc. has been already applied, and Y is the amount of damage actually getting through to the character.)

Here's another example: "If Cure Light Wounds is discharged on someone, that someone heals 1d4+4 points of damage (but will not heal beyond their maximum HP)." In this case we need to refer to the amount of healing provided, and a condition dependent on the max HP of the spell's target.

I believe that rules should be written so that every possible value for their quantities is accounted for. If the rule makes reference to an ability score as a quantity, then the rule ought to be defined for scores of 0, 1, and other values outside the typical 3-18 range** for player characters (**or 2-19 if you use typical racial effects). The core stealth rule ("compare dice roll to sneaker range") has a quantity created when the target rolls dice, and that number can be compared against the sneaker's range no matter what specific dice pool the target rolled.

That stealth rule is a good example of what I'm trying to get at here: no matter what number gets rolled on the dice, the rule can account for it. I think all rules should be like this. But some rules are not: for example, many of the bonuses and disadvantages conferred by ability scores are limited to the player-character range of 3-18. I don't like this. I'd prefer for rules to, as much as possible, be equally applicable to qualities that both PCs and NPCs share, because they are all entities co-existing in the same world.

Why do I prefer that? Because if the rules on how to lift doors, or add Str bonus to attack rolls, can be evenly applied no matter who is encountered, then the effect is that the players able to learn consistent mental models about how the game world is structured. Suppose the party is fighting a tough humanoid enemy. If the party's fighter  can tell that the foe has no fighter levels, then the bonuses on its attack rolls must either be coming from racial advantage; from a high Str; or from some other, unknown source(s).

I recognize that the outcome in the above scenario (the party is able reason about where the enemy's bonuses are coming from, even if they don't know everything) is perfectly possible under rules where ability score bonuses are only defined on the range 3-18, and so on. I just want to make sure that MY rules for ability score bonuses -- and for everything else -- take into account the values that PCs ordinarily won't obtain, but NPCs may have.

Friday, March 16, 2018

Clothing and Costume

This evening, I worked on D&D economy recipes. I have fixed the ludicrous clothing weights by learning more about yarn thicknesses, and adjusting my terrible estimates for how thick average yarn is. My original wild guess was more than EIGHT times thicker than it should have been. Now the ordinary yarn recipes are set at a reasonable unit of 2250 feet per lb, with a thickness of 16 wraps per inch.

While learning about clothing design to adjust the square footage of cloth required for each item, I stumbled across the fascinating blog of Angela Clayton, a self-taught New York seamstress and costume designer who has made many historical and contemporary projects. The project which led me to her blog was her recreation of a dress based on a painting of a 15th-century Holy Roman Empress.

Her blog is Angela's Costumery. The dress post is here and accompanying video is here. I highly encourage you to check it out. If you like my blog you'll like the level of detail with which she documents her costuming process.

I will write more about clothing when I have made more progress on the recipes. Perhaps a before-and-after of the old recipes and the newer better ones.

Also, I am running again! We have had two sessions so far. My new players are enthusiastic and adventurous and I expect great things of them. 

Saturday, December 30, 2017

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.

Friday, December 22, 2017

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.

Thursday, October 26, 2017

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.


















Saturday, October 7, 2017

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!

Monday, September 25, 2017

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.