The number of siblings of a skill is doing double duty

[ebrahimebrahim]

This issue was brought up by @LeyiZ while discussing ability tree mechanics.

While coming up with ways to account for the inherent difficulty of learning certain skills, we noted that a skill that has more siblings is harder to train. Remember that this is because the chances of training its governing attribute are lower when there are more siblings, which leads to lower attribute bonus.

But the original intention of ability trees was different. The idea was to freely clump together skills that were similar and to put them under a governing attribute. For example see this excerpt from the current manual:

Whether or not one subdivides an attribute into many skills or few skills should not be so directly connected to how hard it is to train those skills.

In short, the problem is that the number of siblings of a skill determines two things that we would like to allow the GM to control independently when making a tree:

1. More siblings results in higher difficulty to train (e.g. neuroscience is hard because it also has chemistry and several other things as siblings)
2. More siblings is a way to make a campaign have higher "resolution" for certain skills (e.g. a particular campaign is heavily focused on climbing and different kinds of climbing, so there are many different kinds of climbing as sibling skills. now suddenly it's really hard to level up any one of them.)

[yusufmte]

Peup. Preliminary thought: Let's withhold further work on Issue #1 until this one is resolved, since this could ultimately lead to fundamental changes in how attribute bonus works D:

That said, I'll defend the current system:

More siblings results in higher difficulty to train (e.g. neuroscience is hard because it also has chemistry and several other things as siblings) More siblings is a way to make a campaign have higher "resolution" for certain skills (e.g. a particular campaign is heavily focused on climbing and different kinds of climbing, so there are many different kinds of climbing as sibling skills. now suddenly it's really hard to level up any one of them.)

Basically, I don't think these two things should necessarily be independent.

First, let's agree that skills are what we ultimately want to be roughly "equal"--in the sense that we don't want the ability tree mechanics to confer unintended advantages or disadvantages between skills. Also, we've been skill-centric in other ways as you've mentioned, like telling GMs to make ability trees by starting with skills and clumping them, along with the action mechanics depending primarily on skills.

Now about the sibling issue, I propose comparing skill families instead of individual skills. With this, one point is that it's not purely disadvantageous to have more siblings. It is for one individual skill, but not for the siblings as a whole. Imagine if you have "Science" attribute governing many science skills, and "Climbing" attribute governing few climbing skills. Raising a science skill is less likely to raise Science, but the payoff would be greater than for Climbing--you would raise the attribute bonus for more skills.

That makes larger skill families more "generalised" in a sense, and smaller skill families more "specialised". Meaning, I'd imagine if you were to compare the same xp expenditure on two differently-sized skill families, you would find that the average level of the small family is higher, but the (lower) average level of the larger skill family is applied to more skills. So it is not purely disadvantageous, just different. And in a cool way! You can imagine lots of strategising that stems from this, especially when players also have to take into account the overall difficulties of the skills in each tree, and narrative components.

Not only do I think that it wouldn't be purely disadvantageous, but I also think that the way in which it's different makes plenty of sense! That is, if the GM clumped many skills under one attribute, and clumped few skills under another, the many-children seem to stem from something more general and the few-children from something more specialised. Improving the general thing is less likely but has greater--or at least broader--payoff. I think if the GM put many things into the same governing attribute, it's plausible that this effect isn't beyond their desire. For example, in real life, Intelligence seems harder to improve than Strength (seems more vague and ethereal) and that seems to be a direct consequence of having many children.

What I'm saying is that the resolution does mean something, can't just be arbitrarily different between different parts of the same tree, and I think it should be that way.

That said, even if we agree on this, it would be good to point out this effect to the GM in the manual.

peup.

[ebrahimebrahim]

What you're saying basically is that number-of-siblings controls a certain trade-off for training, rather than giving a pure advantage or disadvantage? I agree with you that it controls a trade-off for the governing attribute. But it's not a trade-off for individual skills, and why shouldn't I focus on individual skills?

The cool effect that you're describing makes sense and works when the increased number of siblings does in fact correspond to the skill being tightly interconnected with many other skills (like neuroscience), but it doesn't really make sense when the increased number of siblings is due to the resolution the GM wants in a particular domain. Consider the following example trees:

Example 1

strength
  fighting
  climbing

Example 2

strength
  punching
  kicking
  climbing

Suppose a GM starts by making Example 1, and then decides that since this is going to be a fighting-heavy campaign they would like to have a more fine-grained view of fighting. So then the GM makes Example 2. (Imagine that we're looking at a portion of a larger tree here, so the rest of the tree remains fixed during the change from Example 1 to Example 2).

Now what has changed? Well, strength is now harder to level up. Okay, that's weird. Even weirder though, is that punching and kicking are now also harder to level up (due to the diminished attribute bonus effect they receive). So splitting fighting into two more detailed skills has made even the individual skills harder to train!

Now I imagine that the hypothetical GM says Darn it. I wish I could just freely subdivide skills without having to worry about the strange effect on difficulty of training.

(BTW I have some ideas for how to address this, but I'm still working on fleshing them out.)

[yusufmte]

What you're saying basically is that number-of-siblings controls a certain trade-off for training, rather than giving a pure advantage or disadvantage? I agree with you that it controls a trade-off for the governing attribute. But it's not a trade-off for individual skills, and why shouldn't I focus on individual skills?

Peup, the effect on the individual skills makes sense to me as well. The gm is clumping together a larger number of skills, meaning a larger number of skills are interconnected, and the "generalist" effect should be in play.

The cool effect that you're describing makes sense and works when the increased number of siblings does in fact correspond to the skill being tightly interconnected with many other skills (like neuroscience), but it doesn't really make sense when the increased number of siblings is due to the resolution the GM wants in a particular domain. Consider the following example trees:

As for the comments on resolution, and the example that follows, I think we are now getting close to the previously discussed issue (about making things more difficult by splitting them up more). We ended up leaning towards solving that by forcing true trees.

I'm going to focus on the example, but I think this is accurate representation of how this process will usually occur, and how we should write about in the tree design section.

In the example, what the gm should do to increase the resolution of fighting is make punching/kicking children of fighting. Not split them up as siblings clumped together with climbing! I mean in this case, the gm looked at a single skill and split it, which is a good indication that it should be a parent attribute. But even if starting from the list of skills, it seems to make sense that punching/kicking should be grouped together more closely between themselves than they are with climbing.

Example 3

strength
  fighting
    punching
    kicking
  climbing

However, if we end up enforcing true trees, Example 3 would be illegal. Basically, it seems like the gm here tried to circumvent the "true trees" principle by making punching and kicking siblings of climbing, which is poor tree design. However, @MeryemA pointed out that you can still get around this by giving climbing a single child (or single parent). The following is proposed:

Example 4

strength
  fighting
    punching
    kicking
  acrobatics
    climbing

This feels to me like a nicer tree in general. Now punching and kicking are truly grouped together, and exhibit relative generalist benefits, where they can aid each other but each is individually harder to raise than climbing. Climbing is more specialised, raising more quickly but benefiting only itself (and the acrobatics attribute, which could be useful to roll against, but recall the attribute penalty! So specialist thing still applies).

Basically, the idea behind forcing true trees was to disallow inconsistent resolution, and I believe that was a good idea. How finely you split things up in this way should have an effect, and I maintain that effect makes sense as long as:

1. The trees are true
2. The skills are grouped together according to their nature (my criticism of Example 2 is that it lacks this)

And if these are followed then the tradeoff should make sense.

I think it makes for nicer trees as well, easier to read and understand with more distinct tiers, and I also think this would guide the gm more in the creation of the tree (they would end up thinking about how skills relate to each other and coming across something like Example 4, rather than having lots of different options and being unsure which is better). Again, it is just stuff to clarify in the manual.

To elaborate further on how this would "guide" the gm:

1. Imagine that kicking was removed, and it was only fighting under punching. That's still fine--punching is now more specialised, and will be easier to raise, but now whenever a character kicks or does another non-punching move, they shall suffer attribute penalty.

2. Imagine that climbing was split into mountain climbing and urban climbing. (Note how this is different from 1). Those should now be grouped under Climbing-- either replace Acrobatics with Climbing or create a new tier for the whole tree.

In this way, I think it guides the gm in a certain direction in tree creation, and I think that direction ends up producing better trees.

peup.

[ebrahimebrahim]

I agree that it's possible to design trees that circumvent the problems, but I'm not so sure that those trees are necessarily better in any sense other than they get around the weirdness. If possible, I think it's better for us to let the GM freely make trees without worrying about weird mechanics, and have peupfudge be internally robust enough to accommodate whatever the GM throws at it. Maybe I'm asking for too much, in which case we might have to write out some very clear tree design constraints along the lines you're suggesting. I'm going to keep thinking about this for a bit...

[yusufmte]

Peup, the sense in which I think it's better is the generalist vs specialist thing. That is, for a skill that's part of a larger family, investing in it is riskier but benefits a larger family. That seems to make sense!

And I don't think it really imposes many tree design constraints. As long as things are clumped together properly, I think it should be accomodated by the mechanics. Look at 1 and 2 at the end of my last comment--these are natural things to do. Or compare examples 2 and 4--I think it would be intuitive to group "punching" and "kicking" together separately from fighting. We need not impose burdensome constraints, we need only to briefly explain the effect (the generalist/specialist thing).

[ebrahimebrahim]

It's still not that nice that GMs need to become "skilled" at tree design in order to come up with trees that aren't broken. I don't feel like the fixes are really that intuitive. With punching,kicking,climbing it's very clear how punching and kicking can be grouped together, and it's clear by construction because the example was supposed to demonstrate something clearly. But what about more borderline/vague/fuzzy cases? Suddenly regrouping things and varying number of siblings has these weird side effects that the GM needs to be aware of. I'm not against the effects themselves, but I'm against them being "side effects." They should be something that is directly controlled instead.

I think I worked out some issues in my proposed solution; I'm about to post that soon. It's not complete but maybe we can go somewhere from it.

[ebrahimebrahim]

My suggestion uses a slightly more flexible version of weights, which are already part of ability trees anyway. The modification is this: We no longer require that weights add up to 1.

Actually, we never required that weights add up to 1; instead we normalized them so that they effectively add up to 1. From manual:

My suggestion is: don't normalize.

Instead, the weights can be any numbers between 0 and 1, and they directly stand for probabilities. So the weight w_i is the probability that attribute A increases when its child ability B_i increases.

Now look at what happens when we split fighting into punching and kicking, going from example 1' to example 2':

Example 1'

strength
  [1/2] fighting
  [1/2] climbing

Example 2'

strength
  [1/2] punching
  [1/2] kicking
  [1/2] climbing

By deliberately choosing the numbers this way, the GM has exercised direct control over one's ability to get stronger by improving their fighting. In this case, the GM chose to keep that ability the same across both examples, only changing the fine-ness of subdivision of skills. If the weights were forced to be normalized then the GM would have just been forced to use

Example 2

strength
  [1/3] punching
  [1/3] kicking
  [1/3] climbing

[to be continued]

[ebrahimebrahim]

But there was a reason we wanted the weights to be normalized! We wanted attribute levels to roughly track the levels of the skills they governed. So for example if punching, kicking, and climbing have all been levelled up to level 2, then we wanted strength to be likely to also be at level 2. With my new suggestion we lose this feature.

I think it's not only okay to lose this feature, it's actually good because sometimes we don't really want it! Consider the following two examples:

Example 5

strength
  punching
  kicking

Example 6

brawling
  punching
  kicking

They look like similar examples, but the attribute name suggests very different things in these two situations.

Sometimes attributes are simply category labels, likely brawling. Brawling is just, by definition, comprised of punching and kicking. Maybe brawling has some other components, like grappling, that were just not included in the tree.

On the other hand, sometimes attributes really are "attributes." Strength is not just a category label for the combination of punching and kicking; strength is its own thing. It's something you could in principle train on its own, but the tree here just wants you to train it via other things.

Why does this distinction matter? I believe that attributes that are "category labels" are the ones whose level should be roughly tracking the levels of their children, and attributes that are their own thing need not have this. Here's how the weights might be chosen for Examples 5 and 6:

Example 5'

strength
  [1] punching
  [1] kicking

Example 6'

brawling
  [1/2] punching
  [1/2] kicking

Brawling is forced to roughly track punching and kicking. You would roll against brawling if, for example, you need to grapple and grappling isn't in the tree. It makes sense that the level you roll against is expected to be roughly the average of your punching and kicking levels.

Strength now improves alongside either punching or kicking. The fact that we chose to split fighting into punching and kicking no longer weirdly diminishes the effectiveness of training fighting on getting stronger. You would roll against strength if, for example, you need to move a heavy boulder.

[to be continued]

[ebrahimebrahim]

Now there's a new issue to address: How should attribute bonus work? The previous system relied on normalized weights. Attribute bonus would have an unnaturally powerful effect in Example 5' compared to Example 6', and there's just no good reason for that.

Here's one idea: Let the GM choose attribute-related discounts directly, just like they can choose weights directly. This adds a new tree decoration: in addition to each edge having a numerical weight, each attribute node also has a number attached to it, the discount factor it applies to its governed abilities.

When determining XP cost to train a skill, a player looks at the skill's level and finds the base XP cost for that level from our XP table (which now would have only one column!). Then the player multiplies that base XP cost by the discount factor labelled on the governing attribute, and they do this a certain number of times based on the level of the governing attribute. They do this for every ancestor attribute, actually.

Sure there's some calculation on the player's part, but it's no worse than the awkward weighted average, and in fact it might even be less confusing to calculate.

We can suggest that ancestors higher up the tree should probably provide less of a discount factor (mimicking the effect of decreasing weights in our previous weighted average approach), but there's no reason to impose it as a hard rule. There could be situations where one does want something high up in the tree to have a significant effect.

There's a bit of weirdness to choosing discount factors; let me demonstrate with the examples and then suggest a mechanic to correct it. Notation: numbers in curly braces {} are discount factors.

Example 5''

strength {0.85}
 [1] punching
 [1] kicking

Example 6''

brawling {0.85}
  [1/2] punching
  [1/2] kicking

Now these choices of discount factors look like they might have the same effect, both being 0.85. But the effect is quite different. Strength is expected to be roughly twice the level of brawling, so the expected discount factor effect in Example 5'' is much higher. We can correct for this if we pay attention to the sum of the weights coming out of an attribute-- for convenience let me call this quantity the valence of the attribute. The valence of strength in Example 5'' is 2 and the valence of brawling in Example 6'' is 1.

Instead of using the level of an attribute to determine the discount to xp cost for training its governed abilities, we could use attribute level divided by valence.

In Example 6'', if brawling is at level 3 then we multiply XP costs by 0.85^3 (or maybe there's a shift needed because we have negative levels, but let me ignore negative levels for simplicity here). In Example 5'', if strength is at level 3 then we multiply XP costs by 0.85^(3/2), because the valence of strength is 2.

This recovers a lot of what we had before when we forced weights to be normalized, except now the normalization step is moved to attribute bonus calculation, and is no longer allowed to constrain attribute training.

Summarizing everything, here's my suggestion:

• Valences are now allowed to not be 1.
• No more weighted average for attribute bonus. Instead we should have discount factors labeled on the attribute nodes.
• When using discount factors to calculate discounts, one should correct for valence.

[ebrahimebrahim]

I have been playing with these ideas in some example trees and they work okay sometimes, but I'm not confident at all. There's a big problem which I mention below. I think some of the ideas in this setup have hope of resolving lots of issues. Maybe there will be no more need to require "true trees." And also the arbitrariness of the weighted average for attribute bonus can go away.

Okay here's the big issue, which I didn't really notice until after I wrote the above posts: In example 5' it's suddenly too easy to have legendary strength. If you just level up punching 3 times and kicking 3 times, your strength gets leveled up 6 times! And it's much cheaper than paying for 6 level-ups of a skill. So there's another good reason to require that valence always be 1.

D:

[ebrahimebrahim]

XP Flow

Okay forget everything I said above-- here comes a new idea. I've been referring to the new proposed system as "xp flow."

Two laws of peupfudge

The two main tree mechanics that make peupfudge what it is:

• Upward flow: Training an ability can train its governing attribute.
• Downward flow: A strong governing attribute can make training an ability easier.

These are the two laws of ability trees. They are reasonable to us, so if we state them precisely enough then anything that follows from them should also be reasonable, even if it's something we didn't anticipate when writing down the laws. So why do we keep coming up with broken implementations? I think the issue is that we're trying to create a simplified model using ability levels, but we haven't actually sat down and written out what it's a simplified model of, which is ultimately going to involve xp. Once I tried to express the laws in terms of xp, I found that I wasn't making so many arbitrary choices, and that definitely seems promising.

The laws in terms of xp

In this example, imagine that strength governs climbing.

Upward flow: Training your climbing skill means you are pouring xp into that skill. Remember that xp can pretty much be thought of as time spent training. Training also trains your strength as a side effect, but not as much as if you had trained your strength directly. So by pouring xp into your climbing skill, you are also pouring a fraction of that xp into your strength attribute.

Downward flow: Being stronger makes it easier to train your climbing. The more strong you are, the more value xp spent on climbing can yield. If you are very strong, then each xp point you put into climbing contributes more effective xp to climbing. Thus, being strong multiplies the value of any xp you put into climbing.

Notation

For upward flow, we need to know what fraction of the xp injected into a skill will propagate up to its governing attribute. I've been calling this fraction w. (I'm using w because it's a bit like the weights we've previously placed on ability tree edges. But this w means something different, sorry if it's confusing). Obviously w should always be positive. It would probably never exceed 1.

For downward flow, we need to know what multiplier gets applied to the xp spent on a skill in order to determine the effective xp that actually gets applied to that skill. The multiplier should depend in some way on the level (or total xp, whatever) of the governing attribute. There's a little arbitrariness in how we choose this dependence, and I leave the choice as a question at the end of this post. For now, let's say that dependence works as follows: For each level of the governing attribute, the multiplier b gets applied to scale up xp into effective xp. (The b stands for "bonus," like in "attribute bonus." Again, it's going to work differently.) So effectve xp equals b^L x where L is the level of the governing attribute and x is the original xp before applying the bonus. Maybe it should be shifted, like b^(L+4) or someting like that, since levels can be negative. For simplicity for now, let me stick with b^L. The value of b should probably be larger than 1, so that it's a bonus rather than a penalty.

We will also need functions that convert between level L and xp x. Reusing previous notation, we have the inverse functions x=g(L) and L=f(x). It will be useful to also have a name for the xp gaps between different levels: let Dx_L denote the xp needed to jump from level L to level L+1. So Dx_L=g(L+1)-g(L).

Now imagine a chain of abilities starting from a certain skill and going up to a root node of an ability tree. Suppose you spend an amount of xp x on that skill, which currently has level L0. Let dx0 denote the effective xp that gets injected into that skill. That effective xp propagates up the tree to the governing attribute, which currently has level L1. Let dx1 denote the effective xp that gets injected into the governing attribute. The xp keeps flowing up the tree until it reaches a root node. Here's a diagram which summarizes all this notation:

Pretend that the ability with level L3 is the root node.

Describing the flow of xp

Now our goal is to use the two laws to describe exactly how much xp gets injected at each ability. So we'd like to determine dx0, dx1, dx2, dx3 given the initial xp expenditure x. The notation tells us what to do:

• dx0 = (b1)^(L1) x Now some of this xp flows up; exactly w1 dx0 ends up making it up to the governing attribute. But that's not the effective xp that gets injected into the governing attribute, because there's also a bonus coming from above. We have
• dx1 = (b2)^(L2) w1 dx0 Now repeat. The xp dx1 flows up and another bonus flows down to give:
• dx2 = (b3)^(L3) w2 dx1 And again, except there's no bonus coming from above the root node:
• dx3 = w3 dx2

So what happens when you train a skill?

To train a skill in practice should be to level it up by exactly 1 level. A skill will level up by 1 when dx0 = Dx_L0. Solving for x, this means that the xp cost to train a skill is x=(b1)^(-L1) Dx_L0. Remember that the various Dx_L values are just constants determined by the function g(L).

Okay, but what happens to the other abilities now?

The governing attribute of our skill started with level L1 before training, and it got dx1 xp injected into it. How much of a level increase is that? Well the total xp originally was g(L1) and the new xp is g(L1)+dx1. So the new level should be f(g(L1)+dx1). So the level should have increased by f(g(L1)+dx1)-L1. Let me call this quantity dL1, and we can similarly define dL2=f(g(L2)+dx2)-L2 and so on. By design we have dL0=f(g(L0)+dx0)-L0=1.

Now dL1 through dL3 are almost certainly not integers, so what do we do? Suppose we ended up with dL1=0.75. Instead of introducing fractional levels and adding 0.75 to the level of the govening attribute, we can introduce probabilities (maybe dice rolling) here to make the expected increase in level be 0.75, which the actual increase is either 0 or 1. Basically, we roll and have a 75% chance of increasing the governing attribute from L1 to L1+1.

If we ended up with dL1=2.75, which is entirely possible, then we level the attribute by two levels and then roll for a 75% chance of leveling it up by one additional level.

Summary

• The cost of training the skill is x=(b1)^(-L1) Dx_L0
• This determines all the dx_i values, since we have dx0 = (b1)^(L1) x and we can propagate this information up the tree using the rule dx_i = (b_{i+1})^(L_{i+1}) w_i dx_{i-1}
• Knowing the dx_i gives us the dL_i since dL_i=f(g(L_i)+dx_i)-L_i
• For each i, write dL_i=n_i+p_i where n_i is an integer and p_i is in [0,1)
• Now the ith ability gets its level increased by n_i and has a probability p_i of increasing its level once more.

Code

If you pull the latest peupfudge, there is a folder exploring the xp flow idea. There you can find an xp flow version of ability_tree.py and various other scripts. Try playing peupfudge/manual/python/exploring_tree_mechanism/xp_budget_game.py to get started with exploring it.

Questions

1. Are the numbers ws and bs easy enough to understand in order for the GM to choose them? I think the ws are very easy to understand, but I'm less sure about the bs.
2. How should the downward flow really work? I think the following aspect is non-arbitrary: effective_xp = B * original_xp where B is some bonus multiplier which depends in some way on the level of the governing attribute. But I think my choice of B=b^L is a bit arbitrary. Another approach suggested by @LeyiZ is actually to base B not on the absolute level of the governing attribute, but rather on the relative level compared to the level of the ability being considered. In other words, replace (b_i)^(L_i) by (b_i)^(L_i-L_{i-1}) in all of the above. I feel like this makes more sense, so this is actually the approach that is implemented in all the exploration code that's currently in the repo.
3. Right now each edge of a tree can have its own w and its own b, and my initial idea was to set it up in this generality and then specialize to whatever simpler case makes sense. Does every edge really need its own b? Or should the b actually label abilities themselves, with each ability conferring the same b to all its children? Or should there be one b set by the GM for the entire tree? Or should we set one global b ourselves for all of peupfudge?
4. There's no way that the xp flow system would be done as a pure tabletop game, and that wasn't my intentioned. My original idea was to give something that may be complicated but is at least more certain to be correct. Then I thought we could simplify from this point to make something rough to approximate xp flow. So, can we do that? Should we do it? Or should we give up on the idea of simple tabletop game calculations, and make peupfudge rely on a nifty interface to manage trees?
5. Should we still disallow the direct training of attributes? We might want to reconsider in the context of xp flow, since training attributes would be handled in a very consistent way. I think the answer is that we should still mostly disallow direct training of attributes, but maybe the GM can allow it for certain attributes in their tree.
6. We do need to settle on f and g. There's some arbitrariness in this choice, but I think it doesn't matter all that much. It's kind of like just choosing the units that end up getting displayed on the tree. In the code that's currently in the repo, I use a simple exponential function g[L]=120 e^{1.05 L}- 120 e^{1.05 (-4)}. It works pretty well. XP values for levels {-4, -3, -2, -1, 0, 1, 2, 3, 4} end up being {0 , 3, 13, 40, 118, 341, 978, 2799, 8001}. They are very roughly calibrated so that an xp point is like an hour, following our previous discussion on that topic.

[yusufmte]

Peup, this is a beautiful system! You have opened my eyes and shown me the light. I'm not exactly sure how to organise all my responses to it, so I will address the questions in order.

One suggestion we had that went outside of the questions was to replace the stochastic increase system with an injected xp tracking system for attributes. In that sense, the suggestion is for attributes to work similarly to skills. Each ability has an xp cost which is required to raise it by one level. For skills and attributes alike, injected xp is added to a running total until the cost is reached, at which point the ability is raised. It's just that, for attributes, the injected xp is determined by upward xp flow.

(With the suggestion as currently described, there would be no probability involved, which feels peupy. To remedy this, the suggestion includes a global "probability factor" which would be randomised and multiplied by every "injected xp" term. For example, a random number between 0.85-1.15. That would include xp injected into skills, and any xp that propogates up due to xp flow; an effect of this is there will be a wider and wider distribution as xp is propagated up the tree, which seems to make sense: a general statement I think we can agree on is that rootier abilities tend to be more vague and the act of increasing them tends to be less correspondingly less reliable. For example, it's clear what one would need to do to increase their "hammering" skill; less clear what one would need to do to increase their "carpentry" attribute; and even less clear what one would need to do to increase their "mechanics" attribute. For this reason, the increased randomness as one climbs the tree makes sense.)

Now to compare the suggestion to the current stochastic system. We talked a bit about it and noted that (1) if you raise a skill more than once and its attribute doesn't raise the first time, then the likelihood of the attribute raising will increase (due to the increased xp cost for the skill) and (2) probability distribution does get wider as you go up the tree for both systems so that isn't a practical difference. However, regarding (1) I'm still worried that there won't "feel" like there is progress, compared to tracking the running xp total. People wouldn't be directly raising skills, they would be adding, say, 5 xp to a skill at a time, and noting each time a 3% chance of raising the attribute (for instance) which "feels" like nothing. And for (2) it feels weird that we don't have control over the distribution.

Also, this all is somewhat in the context of my answer to Q4, since it may otherwise be annoying to track costs for every single ability...

...However, now that I typed all that, I still might like the stochastic system more... maybe the increase of an attribute won't feel as special if you've gradually been climbing it all along. But I do like how the non-stochastic system makes attributes work the same as skills and represents level as just a landmark for xp. peup D:

Now for the questions:

1. Are the numbers ws and bs easy enough to understand in order for the GM to choose them? I think the ws are very easy to understand, but I'm less sure about the bs.
2. How should the downward flow really work? I think the following aspect is non-arbitrary: effective_xp = B * original_xp where B is some bonus multiplier which depends in some way on the level of the governing attribute. But I think my choice of B=b^L is a bit arbitrary. Another approach suggested by @LeyiZ is actually to base B not on the absolute level of the governing attribute, but rather on the relative level compared to the level of the ability being considered. In other words, replace (b_i)^(L_i) by (b_i)^(Li-L{i-1}) in all of the above. I feel like this makes more sense, so this is actually the approach that is implemented in all the exploration code that's currently in the repo.
3. Right now each edge of a tree can have its own w and its own b, and my initial idea was to set it up in this generality and then specialize to whatever simpler case makes sense. Does every edge really need its own b? Or should the b actually label abilities themselves, with each ability conferring the same b to all its children? Or should there be one b set by the GM for the entire tree? Or should we set one global b ourselves for all of peupfudge?
4. There's no way that the xp flow system would be done as a pure tabletop game, and that wasn't my intentioned. My original idea was to give something that may be complicated but is at least more certain to be correct. Then I thought we could simplify from this point to make something rough to approximate xp flow. So, can we do that? Should we do it? Or should we give up on the idea of simple tabletop game calculations, and make peupfudge rely on a nifty interface to manage trees?
5. Should we still disallow the direct training of attributes? We might want to reconsider in the context of xp flow, since training attributes would be handled in a very consistent way. I think the answer is that we should still mostly disallow direct training of attributes, but maybe the GM can allow it for certain attributes in their tree.
6. We do need to settle on f and g. There's some arbitrariness in this choice, but I think it doesn't matter all that much. It's kind of like just choosing the units that end up getting displayed on the tree. In the code that's currently in the repo, I use a simple exponential function g[L]=120 e^{1.05 L}- 120 e^{1.05 (-4)} . It works pretty well. XP values for levels {-4, -3, -2, -1, 0, 1, 2, 3, 4} end up being {0 , 3, 13, 40, 118, 341, 978, 2799, 8001}. They are very roughly calibrated so that an xp point is like an hour, following our previous discussion on that topic.

Q1: I do think both the ws and bs are good as is, and that both would be easy to understand if we explain them the right way! Attempting to explain them concisely: w is the proportion of the xp that gets injected into a ability that gets propagated into its governing attribute, and so it reflects how beneficial it is (for the governing attribute) to train a given ability. b is the magnitude of the benefit/harm that you get from an ability that you're training being of a different level than its governing attribute (especially if we do the relative level thing mentioned in Q2, I think it is highly intuitive).

That said, I do wonder if we should provide a table that suggests values for w and b. For example, "normal" b could be 1.2, "tight connection" (between the ability and its governing attribute) could be 1.3, "very tight connection"...And so on. Except instead of just peuping we can base those numbers on testing (see answer to Q6). And values could be suggested for w as well. But that makes me wonder...should w and b really be independent? Or should "normal connection" indicate a certain w and b, and "tight connection" indicate another pair, and so on...I think my answer is, we should provide a single table that pairs w and b for a qualitatively described connection strength. That is, "normal connection, w=0.3, b=1.2; strong connection, w=0.4, b=1.3"...But still give the gm the freedom to make them different. For example, if for some weird reason the gm decides the w strength should be "weak" and the b strength should be "tight", they can do that. (This is also kind of giving away what I think for Q3.)

Q2: Peup, I love the relative system! I think it is intuitive and makes a lot of sense, and it feels non-arbitrary. The difference is what feels like it should matter. If you are a great climber with mediocre strength, then your strength is holding you back from improving. If you are a mediocre climber with great strength, then your strength is aiding you to improve. I think it also makes bs make more sense in general! So I am purely in favour of keeping this relative system.

Q3: Peup, thinking we should keep the individual b system. For example, going off the example tree, it seems to make sense that hand-to-hand and climbing are both children of muscle, but maybe climbing should be affected (harmed or helped) more by muscle than hand-to-hand should. Or atleast, I think we can come up with examples where two skills that should be siblings shouldn't receive equal magnitude of harm/benefit from their parent. But as I mentioned in Q1, maybe the ws and bs should be somewhat tied together in a table. I mean, can we think of an example where improving a skill is highly likely to improve its parent, but doesn't receive a high magnitude of benefit/harm from its parent? (Maybe, but then the gm can just give "strong w, weak b" using the table, so I would still be in favour of having them on the same table.)

Q4: Answer to this might make you sad...but suggest relying on a nifty interface (and committing to providing one, which would be nice for many other reasons also--that could also mean that peupfudge would remain unreleased until we also have 1.0 of pfi...). @MeryemA was in favour of relying on a nifty interface, and the following argument is ultimately what swayed me: It would be worse to have our equations (how the system is working) be nonintuitive than to have peupfudge rely on an interface. That is, the xp flow system you have described was born out of fundamentals, born out of exactly how we envisioned ability trees should behave. Each term in each equation is meaningful in some way and is there for a reason, and thus the equations themselves are simple and could be described elegantly in the manual (as you have done above). Any process of simplification would be a movement away from this place. As long as the equations are simple, I am happy, even if actually doing the calculations would be really annoying. Plus, if we can actually commit to providing the interface, peupfudge would still be highly accessible, and not require any resource that I think would be unreasonable to expect of people! That said, I still want it to be peussible to play with only pen and paper (even if really annoying and inconvenient), and with xp flow as described, I do think it is peussible (even moreso with a calculator!). But we will still make the interface. So, I am in favour of not simplifying the xp flow system as described.

Q5: With what's been said so far, I think we can go even further in breaking down the wall between skills and attributes! We can even start just calling them all abilities instead, because, as you say, their training is handled in a very consistent way! We don't even have to police the gm on what to allow / not allow because they already have full control of where to allow xp expenditure; for example, a player would not likely be able to put points into "level" because what task could they perform that enables such allocation? We can just tell the gm that: when taking actions, the most specific possible ability (leafiest) should be used, and when designing the tree, the leaves should attempt to exhaustively cover the actions a character would usually perform in that world. And then players would rarely be able to put points into "attributes" anyway. Although sometimes it makes sense: not being able to directly train "muscle" seems strange, for instance! (Maybe that's a tree design issue?)

There's just one big problem with all this, however...xp injected into attributes is worth purely more than xp injected into skills! If a given attribute governs two skills, for example, one of weight 0.4 and one of weight 0.7, then any xp you can put directly into the attribute would be (1/0.7) greater (peup?) than your usual ability to improve that attribute, and the effect gets amplified as you climb the tree! And yet, xp is just task-based; getting the same amount of xp should just mean you did a similar quality of training for a similar length of time. So why this inequality in the value of xp? I think that means we should disallow training of attributes, and keep attributes as attributes and skills as skills. Or we could rethink the system to accommodate this somehow.

This also brings a question to mind that I'm having trouble figuring out: do we still need to force true trees, or is that no longer necessary under the xp flow system?

If worst comes to worst, I think forcing true trees and disallowing direct training of attributes would solve the "big problem" described above. (Not sure if forcing true trees is necessary though. peup.)

Q6: I like those numbers! But that assumes no weights/bonuses. Going back to the wb table idea, whatever we set to be "normal connection" for both w and b should be what median-yields those numbers! And then we can determine other suggested values for w and b by looking at what the median xp values for those qualitatively described "connection strengths" should be! That way, even the wb table (and therefore gm choices of w and b) would be nonarbitrary. If you like this idea, we could go back to cubic or such and hammer out the exact numbers in a call to make a wb table (like we were doing before, but now under the xp flow system!).

Summary of suggestions:

• Replace stochastic system with running xp totals for attributes (like we currently have for skills), and include a global (us-chosen) "probability factor" term
• Keep w and b as is, and make both be individually settable for each ability, but provide a "wb table" that provides suggested paired w and b values for a series of qualitatively described "connection strengths" between an ability and its governing attribute (very weak, weak, normal, strong, very strong, for example). The gm can still set w and b individually to be whatever they wang.
• Keep relative level system for b
• Don't simplify xp flow, just make a nice interface
• Decide what to do about the true trees thing and how much we should retain the different nature of skills and attributes (Q5, I think these two things are connected)
• Decide on f and g in the context of the proposed wb table (i.e. setting f and g and making the wb table would be done simultaneously)

peup.

[ebrahimebrahim]

I will reply in pieces. This is the first of several replies.

About the global probability factor, it looks like after you mention it you change your mind and decide that the stochastic increase system is possibly better. Indeed, the stochastic increase system does lead to wider distributions as you go higher up the tree. But I do agree with you that it feels weird that we don't have control over the distribution! That is an excellent thing to point out...

Now to compare the suggestion to the current stochastic system. We talked a bit about it and noted that (1) if you raise a skill more than once and its attribute doesn't raise the first time, then the likelihood of the attribute raising will increase (due to the increased xp cost for the skill) and (2) probability distribution does get wider as you go up the tree for both systems so that isn't a practical difference. However, regarding (1) I'm still worried that there won't "feel" like there is progress, compared to tracking the running xp total. People wouldn't be directly raising skills, they would be adding, say, 5 xp to a skill at a time, and noting each time a 3% chance of raising the attribute (for instance) which "feels" like nothing. And for (2) it feels weird that we don't have control over the distribution.

Regarding your worry about (1) there, I think this alleviates it: Imagine that you're using PFI and you click on a skill to consider training it. The interface can display for you all the probabilities that other things will increase. Say the governing attribute as a 3% chance of increasing-- then you can see that. And if you click "train" then the governing attribute might level up, but if not at least you will see the probability of level-up (if you were to click "train" again) update to something much bigger and that will feel like progress!

I definitely want to think about why we don't have control over the width of the distribution, and whether that's good or bad. When I played with the xp_budget_game script, I found that the distributions were generally pretty sharp. There's a lot of randomness for training just one thing once, but it gets pretty sharp quickly if you run a training program that trains a handful of things.

[ebrahimebrahim]

I agree with your initial thoughts on Q5:

when taking actions, the most specific possible ability (leafiest) should be used, and when designing the tree, the leaves should attempt to exhaustively cover the actions a character would usually perform in that world. And then players would rarely be able to put points into "attributes" anyway. Although sometimes it makes sense: not being able to directly train "muscle" seems strange, for instance!

Yes, such a guideline makes sense and it's a natural extension of the idea that only certain skills would get opened up for training based on what led to the gain in XP. The GM already has to "unlock" skills for training, so it makes sense to also say that they can sometimes unlock attributes.

There's just one big problem with all this, however...xp injected into attributes is worth purely more than xp injected into skills! If a given attribute governs two skills, for example, one of weight 0.4 and one of weight 0.7, then any xp you can put directly into the attribute would be (1/0.7) greater (peup?) than your usual ability to improve that attribute, and the effect gets amplified as you climb the tree! And yet, xp is just task-based; getting the same amount of xp should just mean you did a similar quality of training for a similar length of time. So why this inequality in the value of xp? I think that means we should disallow training of attributes, and keep attributes as attributes and skills as skills. Or we could rethink the system to accommodate this somehow.

I don't see this as a problem, actually. It's actually kind of a reflection of reality, isn't it? If we're talking about an attribute that makes sense to train (most attributes do not I think), then what's wrong with the advantages gained by training it? Like if you've got "muscle" governing "climbing" and "fighting", and you can go to the gym to improve muscle directly... what's the problem? It really is easier to improve your muscles by going to the gym rather than by practising fighting or climbing.

This also brings a question to mind that I'm having trouble figuring out: do we still need to force true trees, or is that no longer necessary under the xp flow system?

My hope was that the xp flow system would remove this problem altogether. Right now I don't see any reason for us to force true trees. When I read about our original reason for thinking about true trees, I think the issue can be managed by (a) controlling the ws to get the desired behaviors regardless of an abiiity's "leafiness" and (b) allowing direct training of attributes when it makes sense.

[ebrahimebrahim]

Q2: Peup, I love the relative system! I think it is intuitive and makes a lot of sense, and it feels non-arbitrary. The difference is what feels like it should matter. If you are a great climber with mediocre strength, then your strength is holding you back from improving. If you are a mediocre climber with great strength, then your strength is aiding you to improve. I think it also makes bs make more sense in general! So I am purely in favour of keeping this relative system.

Glad you liked that setup-- then Q2 is resolved!

[ebrahimebrahim]

In reply to your reply to Q4: Okay I'm not sad! I do think it's acceptable to rely on PFI. Honestly, bookkeeping is not exactly the most fun aspect of tabletop RPGs. We're making something unique here-- a computer aided table top rpg! A... CATTRPG. Maybe we're starting a genre! Or maybe it already exists somewhere. Or maybe it doesn't because it's a stupid idea. Let's see :)

For my reference: it remains for me to reply to your replies to Q1, Q3, Q6, mainly I need to think about the "wb table" idea. Also, though I replied to parts of it, I think I still need to ponder the question of whether we should replace the stochastic system with "running xp totals + global probability factor".

[yusufmte]

Imagine that you're using PFI and you click on a skill to consider training it. The interface can display for you all the probabilities that other things will increase. Say the governing attribute as a 3% chance of increasing-- then you can see that. And if you click "train" then the governing attribute might level up, but if not at least you will see the probability of level-up (if you were to click "train" again) update to something much bigger and that will feel like progress!

I definitely want to think about why we don't have control over the width of the distribution, and whether that's good or bad. When I played with the xp_budget_game script, I found that the distributions were generally pretty sharp. There's a lot of randomness for training just one thing once, but it gets pretty sharp quickly if you run a training program that trains a handful of things.

Peup, it is nice to know the distribution sharpens! I like that effect and seeing the chance increase each time the skill is raised...actually sounds very fun and perhaps makes more sense than the nonstochastic system, given the uncertainty involved.

My only remaining concern is this (pushing me towards the nonstochastic idea): why should attributes work differently than skills? Isn't the whole idea behind this to increase consistency between attributes and skills? I think I prefer the stochastic system but am having trouble justifying using a different system for attributes and skills, especially since everything else is so modular. If you can explain that then I will be happy.

[yusufmte]

I don't see this as a problem, actually. It's actually kind of a reflection of reality, isn't it? If we're talking about an attribute that makes sense to train (most attributes do not I think), then what's wrong with the advantages gained by training it? Like if you've got "muscle" governing "climbing" and "fighting", and you can go to the gym to improve muscle directly... what's the problem? It really is easier to improve your muscles by going to the gym rather than by practising fighting or climbing.

Hmm, peup, when you put it that way, agreed! It seems that the increased value of xp for attributes makes a lot of sense! And is not an incidental effect, since the xp flow system was designed from first principles.

My hope was that the xp flow system would remove this problem altogether. Right now I don't see any reason for us to force true trees. When I read about our original reason for thinking about true trees, I think the issue can be managed by (a) controlling the ws to get the desired behaviors regardless of an abiiity's "leafiness" and (b) allowing direct training of attributes when it makes sense.

Peup, I agree that this makes it no longer necessary to force true trees as well! I too thought the xp flow system solved that, but got worried upon noticing the increased value of xp for attributes.

Now I think the peuptree is back to its true beautiful form. I am in favour of not forcing true trees, and always allowing direct training of attributes (but the gm has to allow it based on the use of that attribute as the most specific ability that was used in the xp-yielding task, so it should be pretty rare). Instead I think we should just explain these tree phenomena:

**1. The most specific (leafy) ability applicable should be used both when taking actions and when rewarding xp

2. The tree should be designed such that the actions taken in that world tend to rely on skills rather than attributes
3. xp that goes directly into attributes is "more valuable" (by a factor of the product of the weights leading to that attribute) than the xp that goes into their child skills**

Also: point 2 above kind of answers the question I asked in the previous comment! There seems to remain a meaningful difference between attributes and skills.

[yusufmte]

Glad you liked that setup-- then Q2 is resolved!

peup!

[yusufmte]

In reply to your reply to Q4: Okay I'm not sad! I do think it's acceptable to rely on PFI. Honestly, bookkeeping is not exactly the most fun aspect of tabletop RPGs. We're making something unique here-- a computer aided table top rpg! A... CATTRPG. Maybe we're starting a genre! Or maybe it already exists somewhere. Or maybe it doesn't because it's a stupid idea. Let's see :)

Peup, I like this way of thinking with it, and am no longer sad as well! It does sound like a unique and awesome idea that takes out the annoying aspects of tabletop RPGs. CATTRPG. Let's rely on pfi then. peup.

[ebrahimebrahim]

My only remaining concern is this (pushing me towards the nonstochastic idea): why should attributes work differently than skills? Isn't the whole idea behind this to increase consistency between attributes and skills? I think I prefer the stochastic system but am having trouble justifying using a different system for attributes and skills, especially since everything else is so modular. If you can explain that then I will be happy.

It's not exactly that we're treating attributes and skills differently. Think of it this way instead: we are treating the ability you choose to train differently from other abilities that are affected by its being trained. It all follows from the following principles, I think:

• If you choose to train an ability, then it should level up exactly once and that should cost exactly the xp needed to make it level up once.
• Ability levels should always be integers (Justification: A tree should be simple to read, and ability levels should be simple to describe and compare for quick narrative decisions. Also, ability levels are always added to the results of die rolls anyway, and then compared with integers. This becomes needlessly complicated when they are not integers.)

[ebrahimebrahim]

Now I think the peuptree is back to its true beautiful form. I am in favour of not forcing true trees, and always allowing direct training of attributes (but the gm has to allow it based on the use of that attribute as the most specific ability that was used in the xp-yielding task, so it should be pretty rare). Instead I think we should just explain these tree phenomena:

1. The most specific (leafy) ability applicable should be used both when taking actions and when rewarding xp 2. The tree should be designed such that the actions taken in that world tend to rely on skills rather than attributes 3. xp that goes directly into attributes is "more valuable" (by a factor of the product of the weights leading to that attribute) than the xp that goes into their child skills

Very good! I agree that these are all things that should be pointed out or put into the tree design section.

I don't see how the product of weights is relevant in the third point, but no big deal we don't really need to quantify that anyway.

[ebrahimebrahim]

About the w-b table idea:

I think it's promising! However, I'm struggling to form a solid opinion because I think we should play with trees a lot more in order to develop good ideas about what effects different values of w and b will have.

I think that making a good w-b table will require some analysis on our part. We could always write this stuff up without a w-b table to start with, and then see if we can come up with a good table to put in later on. Were you suggesting coming up with the w-b table by trying to deduce it from principles? If so, then the GM can do that just as well as we can. If not, then we need to do a bunch of experimentation, and that's what I'm getting at. Maybe the w-b table could even be a post-1.0 thing?

However, here's a question you posed that we should agree on before we proceed:

But that makes me wonder...should w and b really be independent?

I do think they should be independent to some extent. While the reasonable choices could perhaps fit into a w-b table, I think it should be some kind of 2D table rather than a 1D table. This is because w and b control different effects, and its conceivable to imagine only one of w,b changing from one situation to another, while the other stays fixed. An extreme situation: Sometimes, we might want to hold b at 1, while varying only w for various skills. I can't think of a specific example where this is reasonable, but it's a conceivable situation right?

To finally reply to your reply to Q3: Okay I do agree that keeping individual b's is good. It makes b's kind of be like w's so that there's not so much of a new concept to introduce, and it also introduces a degree of control that it makes sense to have. Your example is convincing:

Q3: Peup, thinking we should keep the individual b system. For example, going off the example tree, it seems to make sense that hand-to-hand and climbing are both children of muscle, but maybe climbing should be affected (harmed or helped) more by muscle than hand-to-hand should.

Finally, I need to reply to your Q6 reply:

Q6: I like those numbers! But that assumes no weights/bonuses. Going back to the wb table idea, whatever we set to be "normal connection" for both w and b should be what median-yields those numbers! And then we can determine other suggested values for w and b by looking at what the median xp values for those qualitatively described "connection strengths" should be! That way, even the wb table (and therefore gm choices of w and b) would be nonarbitrary. If you like this idea, we could go back to cubic or such and hammer out the exact numbers in a call to make a wb table (like we were doing before, but now under the xp flow system!).

I'm sort of in favor of picking the xp-level function without paying attention to weights and bonuses, and then allowing the weights/bonus effect to play out on top of that. My reasons for this:

• The connection between xp and "hours" is a pretty weak heuristic anyway. There's now way it would really be treated that way in games. I think that no matter what we do, XP is going to have to be a brand new "unit" that everyone gets used to.
• The mapping from xp to level is somewhat arbitrary and really just needs to spread out a wide range of xp across a small range of integer levels, while satisfying a couple of other properties to maintain the weak "xp is time" interpretation. A lot of the arbitrariness stems from the mapping between levels and adjectives, which are also just rough heuristics for interpreting performance.
• Paying attention to weights and bonuses is hard! They could be anything! And I kind of don't want to choose some arbitrary values of w and b on which to "calibrate" the interpretation of xp. It feels better to calibrate xp to no weights and bonuses, and then add the effect of weights and bonuses after. IDK if you agree...

[yusufmte]

It's not exactly that we're treating attributes and skills differently. Think of it this way instead: we are treating the ability you choose to train differently from other abilities that are affected by its being trained.

Peup, this makes sense!

I was about to say I am now fully happy with the stochastic increase system, but I just realised something that confused me...

If you choose to train an ability, then it should level up exactly once and that should cost exactly the xp needed to make it level up once.

This is false, right? When you train an ability, you allocate a certain amount of xp to it (a fraction of what you were rewarded for a task). Then that xp propagates up, and adds to a running total for the ability you are training, until the running total reaches the cost, at which point the ability levels up.

So, if you are repeatedly doing a task for which the gm awards you 5 xp (say, focused reading of "Introduction to Ability" for 2 hours), then you will earn these bursts of 5 xp. Let's say the cost for the next level up of Ability is 300. Eventually you will read this book enough that Ability levels up. But each "session" you do will only have a very low probability of increasing Ability's ancestors, let's say 1% each time. Even after Ability levels up, if you keep reading that book, you will keep gaining 5 xp at a time and continue to have a very low chance to increase the ancestors. So there is no "satisfying jump" even after Ability levels up.

Here's another weirdness: it matters how the xp is split up. For example, if 100 injected xp is required to raise an ancestor, then injecting 100 xp into it all at once will have a higher probability of raising it (1) than injecting 2 xp into it 50 times (something <1). Does that difference make sense given how we think of xp?

Or, did I misunderstand about xp propagation? And is it that xp doesn't just flow up whenever you allocate it, but instead, whenever an ability is raised (after many rounds of allocation), the cost to raise that ability flows up all at once? If it's that, then I think it might prevent both of the problems mentioned above...

[yusufmte]

Very good! I agree that these are all things that should be pointed out or put into the tree design section.

peup!

[yusufmte]

Concerning the w-b table:

I think that making a good w-b table will require some analysis on our part. We could always write this stuff up without a w-b table to start with, and then see if we can come up with a good table to put in later on. Were you suggesting coming up with the w-b table by trying to deduce it from principles? If so, then the GM can do that just as well as we can. If not, then we need to do a bunch of experimentation, and that's what I'm getting at. Maybe the w-b table could even be a post-1.0 thing?

Yes, I am thinking it's something we would make with experimentation. Basically the same thing we were doing when making the xp cost table previously. But now instead of peuping to make the costs, we are peuping to determine the values to describe qualitatively in the w-b table (by experimenting to determine the downstream effects of certain w-b values on parameters like distribution and average xp costs, and trying to find parameters that feel like they make sense).

But, I do think it is important enough to do before 1.0. The reason being: if we release this system as it is, I think the gm would have no idea how to start picking w and b. It would feel like total peuping. Why b = 1.5 instead of b = 1.2? I think the gm would be able to infer relative values of w and b ... that they should be higher for one particular ability than another. But we must provide some numerical anchor that allows them to express their relative selves.

I'm sort of in favor of picking the xp-level function without paying attention to weights and bonuses, and then allowing the weights/bonus effect to play out on top of that. My reasons for this:

• The connection between xp and "hours" is a pretty weak heuristic anyway. There's now way it would really be treated that way in games. I think that no matter what we do, XP is going to have to be a brand new "unit" that everyone gets used to.
• The mapping from xp to level is somewhat arbitrary and really just needs to spread out a wide range of xp across a small range of integer levels, while satisfying a couple of other properties to maintain the weak "xp is time" interpretation. A lot of the arbitrariness stems from the mapping between levels and adjectives, which are also just rough heuristics for interpreting performance.
• Paying attention to weights and bonuses is hard! They could be anything! And I kind of don't want to choose some arbitrary values of w and b on which to "calibrate" the interpretation of xp. It feels better to calibrate xp to no weights and bonuses, and then add the effect of weights and bonuses after. IDK if you agree...

And this is what I think the anchor could be. That is, "normal" values for w and b should correspond to our "xp is time" interpretation. It is a weak heuristic indeed, but it provides some kind of anchor, something that allows the gm to know b = 1.2 may produce more typical results than b = 38.

I do think they should be independent to some extent.

While the reasonable choices could perhaps fit into a w-b table, I think it should be some kind of 2D table rather than a 1D table. This is because w and b control different effects, and its conceivable to imagine only one of w,b changing from one situation to another, while the other stays fixed. An extreme situation: Sometimes, we might want to hold b at 1, while varying only w for various skills. I can't think of a specific example where this is reasonable, but it's a conceivable situation right?

Yes, agree they should be independent! My vision for the table is something like: "normal connection strength, w = 0.4, b = 1.2"...and other rows with different values. But you can let w have a "normal connection strength" and b have a "very weak", it would just be clear that you are doing that, which I think is good.

Okay I do agree that keeping individual b's is good.

Peup!

In summary, I think the w-b table can act as anchor for picking w-b choices, and gives a meaning for our xp interpretation as well if we set the anchor to that (peupy as it is).

peup.

[ebrahimebrahim]

This is false, right? When you train an ability, you allocate a certain amount of xp to it (a fraction of what you were rewarded for a task). Then that xp propagates up, and adds to a running total for the ability you are training, until the running total reaches the cost, at which point the ability levels up.

Hmm actually I totally forgot that we put that in the manual (that xp should be allocated as soon as it's awarded). But what I had in mind is that nothing happens until exactly enough xp is allocated to level a skill up exactly once. Only at that point would xp flow upward.

Or, did I misunderstand about xp propagation? And is it that xp doesn't just flow up whenever you allocate it, but instead, whenever an ability is raised (after many rounds of allocation), the cost to raise that ability flows up all at once? If it's that, then I think it might prevent both of the problems mentioned above...

Right, I was thinking of it in that way. Does that solve the problem in your view? We are treating the thing being trained differently from the things that receive side effects due to xp flow. I think I also have a good justification for wanting the thing you train to level up exactly once as a result of the training, and that's the "satisfying jump" that you bring up...

So there is no "satisfying jump" even after Ability levels up.

What matters for die rolls is the integer level of a skill. So I think it makes sense to have players working towards that integer jump.

Here's another weirdness: it matters how the xp is split up. For example, if 100 injected xp is required to raise an ancestor, then injecting 100 xp into it all at once will have a higher probability of raising it (1) than injecting 2 xp into it 50 times (something <1). Does that difference make sense given how we think of xp?

This is an interesting question. Let me rephrase your example in terms of level rather than xp, so that it's easier to talk about. In the case that "1 level" is injected (so dL=1 in the notation from way above), indeed there is a probability 1 that the level will increase by 1. In the case that "0.02 level" is injected 50 times, it's true that the probability of the level increasing by 1 is lower than 1... HOWEVER the expected level increase is still equal to 1! (That is, if you ran a million trials where in each trial you injected 0.02 level 50 times, then the average increase in level you see throughout those trials is an increase by 1 level.) This can happen because in fact if you inject 0.02 level 50 times, it's possible to get a level increase higher than 1. On the extreme end, you'd have a (very very low, 0.02^50) chance of getting 50 level increases!

So splitting up xp injections more finely does not affect expected value of level gain.

What is affected however is the spread of the level gain distribution. If you inject xp such that dL=1, then you have a sharp distribution telling you that with certainty you get a level gain of 1. If you inject xp such that dL is something less than 1, say it's 1/3, and you do that 3 times.... then the expected level gain is still 1 but the spread of the level gain distribution is higher. The variance (square of standard deviation) would be 2, so you can think of it as a level gain of 1 +/- sqrt(2). I think if you inject xp n times such that dL is 1/n each time, then the expected level gain is 1 with a variance of n-1. (Take this with a grain of salt... I tried to calculate it myself and I'm pretty crappy at statistics)

[ebrahimebrahim]

About w-b table: I'm not yet convinced that we should use it to anchor the xp-level conversion, or that it's needed for 1.0. But I'm open to being convinced.

But, I do think it is important enough to do before 1.0. The reason being: if we release this system as it is, I think the gm would have no idea how to start picking w and b. It would feel like total peuping. Why b = 1.5 instead of b = 1.2?

So this concern is actually the reason I asked Q1: Are the w's and b's easy enough to understand in order for the GM to choose them? Your reply was:

Q1: I do think both the ws and bs are good as is, and that both would be easy to understand if we explain them the right way! Attempting to explain them concisely: w is the proportion of the xp that gets injected into a ability that gets propagated into its governing attribute, and so it reflects how beneficial it is (for the governing attribute) to train a given ability. b is the magnitude of the benefit/harm that you get from an ability that you're training being of a different level than its governing attribute (especially if we do the relative level thing mentioned in Q2, I think it is highly intuitive).

Do you still think this? If so, then isn't the meaning behind w's and b's sufficient for choosing them? For example picking b=1.5 vs b=1.2 is a matter of answering the question: if this attribute is one level higher than the ability that it governs, then by what factor does it scale up the "quality" of time spent training?

[yusufmte]

Hmm actually I totally forgot that we put that in the manual (that xp should be allocated as soon as it's awarded). But what I had in mind is that nothing happens until exactly enough xp is allocated to level a skill up exactly once. Only at that point would xp flow upward.

Right, I was thinking of it in that way. Does that solve the problem in your view? We are treating the thing being trained differently from the things that receive side effects due to xp flow. I think I also have a good justification for wanting the thing you train to level up exactly once as a result of the training, and that's the "satisfying jump" that you bring up...

What matters for die rolls is the integer level of a skill. So I think it makes sense to have players working towards that integer jump.

Peup, yes, this makes everything ok!

This is an interesting question. Let me rephrase your example in terms of level rather than xp, so that it's easier to talk about. In the case that "1 level" is injected (so dL=1 in the notation from way above), indeed there is a probability 1 that the level will increase by 1. In the case that "0.02 level" is injected 50 times, it's true that the probability of the level increasing by 1 is lower than 1... HOWEVER the expected level increase is still equal to 1! (That is, if you ran a million trials where in each trial you injected 0.02 level 50 times, then the average increase in level you see throughout those trials is an increase by 1 level.) This can happen because in fact if you inject 0.02 level 50 times, it's possible to get a level increase higher than 1. On the extreme end, you'd have a (very very low, 0.02^50) chance of getting 50 level increases!

I completely overlooked this, but it makes perfect sense! peup.

Ok, I now support every aspect of the stochastic system!

[yusufmte]

Do you still think this? If so, then isn't the meaning behind w's and b's sufficient for choosing them? For example picking b=1.5 vs b=1.2 is a matter of answering the question: if this attribute is one level higher than the ability that it governs, then by what factor does it scale up the "quality" of time spent training?

I think their definitions are qualitatively intuitive. But I still think an anchor is lacking, which is what the w-b table can provide. And we can set that anchor to a grounding that we've already been working on (the peuping we've been doing with simulating xp as hours and thinking about how much is "normal" to reach the associated adjective).

I think comparing w-b values is something a gm can do; that is, be able to tell what should have a higher/lower w or b than other abilities. But it seems hard to justify picking 1.5 instead of 1.4, without knowing the final xp distributions are affected (what we would be testing in our experimentation). Try to think of a specific skill, like climbing, punching, and muscle; I feel like climbing has a higher weight with muscle than punching does, but how would I go about deciding whether 0.6 of the xp that goes into climbing should go into muscle or 0.7? I feel unanchored.

Essentially, I feel that we have defined a variable nicely, and now the next step is to provide a unit with which to quantify it. We have intuitively defined force as mass * acceleration but amounts of force can't be described unless we provide units.

[yusufmte]

Try to think of a specific skill, like climbing, punching, and muscle; I feel like climbing has a higher weight with muscle than punching does, but how would I go about deciding whether 0.6 of the xp that goes into climbing should go into muscle or 0.7?

Peup, I'm becoming ambivalent again. Now that I say that. Maybe it is anchored and intuitive? I only need to think about how much of what is put into climbing should go into muscle, as if I was training muscle directly ... for example, since xp is directly proportional to time, another way to think of it could be: spending t time on climbing should be equivalent (on average), for muscle, to spending t*w time on muscle. (e.g., for w = 0.5, 2 hours of climbing is like 1 hour of weightlifting)

Ok, I no longer think the w-b table is necessary. And we can do the "xp as hours" thing without considering w or b. We can even peupily pick the costs as before!

Now I am only unsure about b...could a similar analogy be developed as above?

[ebrahimebrahim]

Essentially, I feel that we have defined a variable nicely, and now the next step is to provide a unit with which to quantify it.

I don't think making a w-b table is like providing units, since the w's and b's are unitless. They are ratios of things that do have units. It seems like you realized this in your next post:

Peup, I'm becoming ambivalent again. Now that I say that. Maybe it is anchored and intuitive? I only need to think about how much of what is put into climbing should go into muscle, as if I was training muscle directly ... for example, since xp is directly proportional to time, another way to think of it could be: spending t time on climbing should be equivalent (on average), for muscle, to spending t*w time on muscle. (e.g., for w = 0.5, 2 hours of climbing is like 1 hour of weightlifting)

Exactly right! That's how I was thinking of w when I was playing with training schemes in xp_budget_game. I'm pretty sure w is "anchored". I'm less certain about b, which is why I asked Q1 in the first place. But I think it's okay too?

Now I am only unsure about b...could a similar analogy be developed as above?

Ah you feel the same way. Well let me try: b is the ratio of "effective xp" to "actual spent xp" (see how it's unitless btw?) in the situation where governing attribute is one level higher than ability being trained. So for each hour you spend training, say, climbing, how many effective hours do you want that to count for if your muscle is one level higher than your climbing? What do you think?

Ok, I no longer think the w-b table is necessary. And we can do the "xp as hours" thing without considering w or b. We can even peupily pick the costs as before!

Yay! But the xp flow system kind of requires a function mapping continuously between xp's and levels, so we can't just peup with a table I think. We can peup with picking the function. How do you feel about my initial suggestion for a function?

[yusufmte]

So for each hour you spend training, say, climbing, how many effective hours do you want that to count for if your muscle is one level higher than your climbing? What do you think?

Peup!! Yes, this is highly satisfying! As long as we include both of these analogies in the manual I think they should be fully intuitive! I see now how they are ratios too and unitless by nature.

We can peup with picking the function. How do you feel about my initial suggestion for a function?

I like the outputs of the function very much! That is, the list of total xp at each level. The only thing I'm not sure about is, why is it the way that it is? That is, can we make the function itself make sense? Should we?

[ebrahimebrahim]

I like the outputs of the function very much! That is, the list of total xp at each level. The only thing I'm not sure about is, why is it the way that it is? That is, can we make the function itself make sense? Should we?

I chose that function because it's simple, it's continuous, the inverse is easy to write down and compute explicitly, and I liked the list of total xp at each integer level.

What do you mean by "make sense"?

The goal of the xp <--> level conversion is just to have some convenient units for storytelling. There's nothing that really needs to make sense other than having the adjectives give the right sense, right?

[yusufmte]

I chose that function because it's simple, it's continuous, the inverse is easy to write down and compute explicitly, and I liked the list of total xp at each integer level.

Peup, I agree with these points!

What do you mean by "make sense"?

I guess what I meant is being able to justify the position and value of each term, like why 1.05 instead of 1.1, etc., in some intuitive way ...

The goal of the xp <--> level conversion is just to have some convenient units for storytelling. There's nothing that really needs to make sense other than having the adjectives give the right sense, right?

... But now I see that that requirement doesn't really make sense. Yes! We are just looking for outputs that "make sense" with respect to the adjectives and our peupy interpretation of them, and a function that can provide those outputs while fitting into the xp flow system! So we can peup with the function as we've peuped with the table. That said, I do like its simplicity and really like its outputs! Peup, I am fully satisfied with it.

[yusufmte]

Do we have then any open questions remaining on this issue? Should I itemize the things to change / include in the manual in order to fully implement the xp flow system? Peup, I am really proud of it!

[ebrahimebrahim]

So we can peup with the function as we've peuped with the table.

Right :D

Peup, I am really proud of it!

Me too!!

Do we have then any open questions remaining on this issue? Should I itemize the things to change / include in the manual in order to fully implement the xp flow system?

One thing you pointed out that is still bugging me... is it weird that we don't directly control the spread of the distribution of levels for attributes?

Other than this question, yes I do think everything here is resolved. Then the next task is to write everything up I guess? Yes it would be helpful to itemize things to change. Maybe we should close this issue soon and create cards for the things to change.

[ebrahimebrahim]

Going back to an old comment of yours:

Now to compare the suggestion to the current stochastic system. We talked a bit about it and noted that (1) if you raise a skill more than once and its attribute doesn't raise the first time, then the likelihood of the attribute raising will increase (due to the increased xp cost for the skill) and (2) probability distribution does get wider as you go up the tree for both systems so that isn't a practical difference. However, regarding (1) I'm still worried that there won't "feel" like there is progress, compared to tracking the running xp total. People wouldn't be directly raising skills, they would be adding, say, 5 xp to a skill at a time, and noting each time a 3% chance of raising the attribute (for instance) which "feels" like nothing. And for (2) it feels weird that we don't have control over the distribution.

Specifically

probability distribution does get wider as you go up the tree for both systems

... I'm not so sure about this anymore... D:

[ebrahimebrahim]

After trying things out with xp_budget_game and looking at standard deviations of levels that result from a training sequence... it looks like the the spread definitely does not increase as you go further up the tree! In fact, the spread changes very little and sometimes decreases slightly as you go up the tree! (Obvious exception: Skills always have standard deviation 0 because they are certain to be trained when you train them)

Hmm...

[yusufmte]

...it looks like the the spread definitely does not increase as you go further up the tree!

Peup, really curious...how could that be? D:

In either case, what do you think? Does this mean we should consider the nonstochastic system and seeing whether we can adequately control the distribution via the "probability coefficient"?

I'll itemize the list of changes to the manual soon!

peup.

[ebrahimebrahim]

This is no longer an issue in core peupfudge, since ability trees are gone.

Some of the ideas in here might make a neat module, or maybe a neat idea for a video game skill tree.