Pyrel dev log, part 3

[buzzkill]

(thus, an item that improves your DEX based on your magic device skill, which is based on your INT.)

So your INT is partially derived from DEX? I still don't see what magic device skill HAS to do with it. It seems like an unnecessary middle-man.

The idea here would be that any time a new Derived-tier modification is applied to the user's stats, it'd go onto the end of a queue; mods would be applied in the order on the queue. But the user would have access to the queue and would be allowed to re-order things as they wish. The default ordering then would be "order in which you received the mods", which is at least somewhat reasonable on its own.

If this is the solution, then there's a a problem with the solution.

I think your moving into unlikely hypothetical situations, instead of creating a system that is going to deal with reality. Maintainers that want to accomplish the "unlikely" can always modify the source.

[ekolis]

So your INT is partially derived from DEX? I still don't see what magic device skill HAS to do with it. It seems like an unnecessary middle-man.

I think it's the other way around - INT normally affects magic device skill, but this special modifier would affect DEX based on magic device skill, so INT would be indirectly affecting DEX. Why the middleman, and not have INT affect DEX directly? Well, there could be other modifiers to your magic device skill besides that from INT!

[Derakon]

So your INT is partially derived from DEX? I still don't see what magic device skill HAS to do with it. It seems like an unnecessary middle-man.

Magic device skill is in there because you're using a magical item to get the bonus; the hypothesis here is that high MDS makes you better at, well, wearing jewelry and the like. And as ekolis notes, INT is not the sole contributor to MDS.

I think your moving into unlikely hypothetical situations, instead of creating a system that is going to deal with reality. Maintainers that want to accomplish the "unlikely" can always modify the source.

Making a system that can deal with the current reality is pretty straightforward, because the current reality is not capable of doing anything especially complicated. But part of the reason to write Pyrel in the first place was to free ourselves from the limitations of the old system. You can bet that as soon as Pyrel 1.0 goes out (if not sooner) we'll be working on Pyrel v4 and playing around with all the special effects it can handle. So I don't think this situation is unlikely at all.

[Derakon]

The user as in the player? Sounds like this could get annoying from a UI perspective (not to mention hard to balance).

Yeah, I generally use "user" to refer to players, and "client" to refer to other programmers.

AFAICT the auto-tiering thing is pretty simple: 1) "Compress" the DAG to minimize distance from the root to every other node while maintaining proper dependencies, basically maximal path compression. 2) Classify into tiers based on distance from the root node. This will give you the minimal number of necessary tiers and the nodes in each tier.

I can think of at least one simple way to this: Do a topo-sort and build the tiers iteratively: If the next node in the topo-sorted list is pointed to directly by any node in the current tier, then start a new tier. If it isn't, then simply add to current tier. (With appropriate degenerate cases for the root, etc.)

There may be far better algorithms for doing this, but it's been a few (well, many) years since I took any Graph Theory classes

This is certainly doable and could possibly be useful for simplifying any UI we write about this problem, but it doesn't change the fact that we have to resolve loops somehow. It'd just tell us "Yep, you have an INT->MDS->DEX issue, you'll need an extra tier to handle that."

[AnonymousHero]

This is certainly doable and could possibly be useful for simplifying any UI we write about this problem, but it doesn't change the fact that we have to resolve loops somehow. It'd just tell us "Yep, you have an INT->MDS->DEX issue, you'll need an extra tier to handle that."

I was actually think that you could just let all the calculations happen lazily and detect loops while doing them. For display you can do the tiering thing I outlined above.

What I mean is that the calculation for "DEX" simply calls to the calculation to "MDS" which in turn simply calls to the calculation for "INT". Detecting a loop is as simple as having a counter on each stat which is incremented by one every time you call the calculation is is decremented by one once the calculation finished. If the counter ever reaches 2, then there's a loop and the calculation will never finish.

[Magnate]

Making a system that can deal with the current reality is pretty straightforward, because the current reality is not capable of doing anything especially complicated. But part of the reason to write Pyrel in the first place was to free ourselves from the limitations of the old system. You can bet that as soon as Pyrel 1.0 goes out (if not sooner) we'll be working on Pyrel v4 and playing around with all the special effects it can handle. So I don't think this situation is unlikely at all.

There's also the issue of people only being able to modify the source if it's sufficiently well-designed to allow them to accomplish what they want. If we don't solve this problem, whoever does will have to completely rewrite this bit of code, not just modify it. This is the problem with the current codebase - way too many things need completely rewriting for it to support any serious creativity. Heading this off with good low-level design is one of the main reasons for creating Pyrel - it's certainly the reason I'm working on it.

So, I'm glad I was right about the problem being in the derived tier, but I'm actually not sure I see a need for the before/after chargen split. If we're going to let the player decide, we should let them decide at chargen too, should the circularity ever come up.

[emulord]

I feel like rather than trying to figure out if its looping and stuff like that, instead we should have a strict ordering of stats. It makes more sense to a player.

Innate Dex -> Modified Dex -> % Modified Dex -> AC -> % modified AC.

So you can have things that affect Dex and AC.
Gloves of Agility [+1 AC] (+3 dex), +(70% Dex into AC) gets parsed like this:
so with a naked character with 15 dex equipping this gets:
On equip, 15 innate dex -> 18 modified dex -> 18 % modified dex -> 1 AC -> 13.6 AC

Since other things can affect dex independently, affecting the dex, when you equip anything, recalculate all stats = to and below affected tiers. Its probably simpler and faster than figuring out dependencies dynamically.

[emulord]

We would just ban things affecting higher or equal tiers. Magic device skill would NEVER affect dex, because why would it? A temporary item could increase dex, but it wouldnt be able to be based off of Magic device skill, because you might be able to make unbounded increases in stats.

Here are the total tiers imo. Maybe these could be compile time decided? Or hardcoded, whichever is easier.

1. Gold, Exp
2. Level
3. Str, Dex, Int, Con, Wis, Chr
4. Social Class, Weight, Height, Available spells, Max Mana, Max Health, Stealth, Speed, Magic device, disarming, AC, saving throw

I feel like having (+Chr bonus based on current Con) items is silly. Removing the possibility is fine.

Or you could do Castle of the winds style where it prevents you from putting on a item that would cause a loop. In that case its nesting bags of holding or items within themselves. Just say "the item's magic prevents you from putting this on while you're wearing the __Other offending item".
Idk how you'd prevent potion or temporary item use.

[Derakon]

We would just ban things affecting higher or equal tiers. Magic device skill would NEVER affect dex, because why would it? A temporary item could increase dex, but it wouldnt be able to be based off of Magic device skill, because you might be able to make unbounded increases in stats.

You're suggesting basically the "tiered stats" approach I mentioned earlier, and I still think that approach is too limiting. Why shouldn't magic device skill be able to affect DEX? In this system it would represent your ability to properly use magical equipment. I could readily imagine a game system where different classes got different benefits from their gear -- warriors would have great innate powers and would be good at using weapons and armor, but benefit relatively little from jewelry; the reverse would be true for mages, who want to pile on as many magical trinkets as possible because they simply can't use "real" gear effectively.

Also, this:

Innate Dex -> Modified Dex -> % Modified Dex -> AC -> % modified AC.

ignores that stat mods can invoke arbitrary functions to decide what the modifier is. For example, there could be an altar on the level, and the closer you got to the altar, the better your AC was (because your god protects you). Or if it was not a coaligned altar, then the closer you got, the weaker you'd become...until you finally got close enough to smash it, anyway. Again, interesting potential mechanics that can only be supported if we err on the side of flexibility.

[emulord]

That kind of thing would be doable in this system. A "on movement" effect determining distance from altar and modifying AC by a % for example. It might be slow I guess, but with that much recalculation I don't see how you could avoid that.

The problem is that its terribly obscure for a player. Players can see loops like "wait, my magi helm increases dex by 40% Magic Device, and my Gloves of wand use increase Magic device by 40% dex. Its a converging sequence, but my calculation seems off from what the game is telling me..."

And thats a best case scenario.

That "classes get different benefits from equipment" is definetly possible! If you mostly use % improvement items, then Gloves of slaying improve % damage and % Strength, and amulets give %Int and so on.

If its specifically a Magic device skill, alter the tiers of everything.
You need a transparent and simple method to get rid of looped effects anyway. If you're set on the flexible approach, I suggest limiting equipped items to prevent loops with a CastleOfTheWinds message. The polarity of the magical items prevents you from using both. I suppose temporary items and terrain effects wouldn't be too bad with just one layer, and terminated when it detects any looping.

[emulord]

Either way, how are you going to determine order?
If its general, having
Dex = f(Dex)
Dex = g(Dex)

in general is different than the other ordering. Thats why I separated % and constant changes into separate tiers. I suppose if you had loop detection and did all constant changes first, then all % based changes it could work fine.

Unfortunately this prevents effects like AC = 110% AC, which are exponential increases, unless you had another layer. The problem is some functions are not associative. Unless you have some way to order it, you're going to have min-maxing like taking off equipment and putting it on in a different order to maximize gains, and thats just horrible.

[buzzkill]

Why shouldn't magic device skill be able to affect DEX?

Because MDS (as it exists now, unless I'm mistaken) is a skill, not a stat. Stats determine skills, not the other way around. Wearing glasses will (in some cases) make you a better reader, which in turn may raise your intelligence, but wearing glasses doesn't in and of itself make you any smarter. So, glasses could increase you reading skill (more logical), or they could increase INT (less logical), or both (impractical).

Why not have WIS modify INT and vice-versa??? It makes perfect sense. STR, DEX and CON should all modify one another too, shouldn't they???

It seems to me that having MDS modify INT, is a lot like having INT modify INT. If someone, in the future, wants to implement such an insane system, they can, but it's not a feature one should expect given the illogic. Trying to please all the people all the time... well. Any system that does what you're trying to accomplish will be imperfect or lacking in some respect, so why not just the maintainer that wants to do such a thing, hack it in there themselves. At the very least, if they write the code themselves, it will do exactly what they want it to do.

Emulord makes a lot of sense.

[Derakon]

Remember the context here. MDS isn't directly improving a stat; it's improving your ability to use an item that improves a stat. It makes perfect sense that the better you are at using magical devices, the better the results you would get from them, and magical devices that improve your statistics are a time-honored tradition.

Of course stats shouldn't automatically boost each other in the absence of any other effects.

[Nick]

You're suggesting basically the "tiered stats" approach I mentioned earlier, and I still think that approach is too limiting. Why shouldn't magic device skill be able to affect DEX?

Because if DEX increases MDS and MDS increases DEX, your graph is no longer acyclic. Which is like perpetual motion, unless I'm missing something.

EDIT: Which, looking at your previous post, I must be.

I'll have another go. If you have a magic device which improves your DEX when used (ie a temporary effect), then the player is in a different state after using the device, and that should be regarded as a different vertex of the graph, I think. Or something. Probably just ignore me.

[Magnate]

Because if DEX increases MDS and MDS increases DEX, your graph is no longer acyclic. Which is like perpetual motion, unless I'm missing something.

EDIT: Which, looking at your previous post, I must be.

I'll have another go. If you have a magic device which improves your DEX when used (ie a temporary effect), then the player is in a different state after using the device, and that should be regarded as a different vertex of the graph, I think. Or something. Probably just ignore me.

The important point here is that circularities are inevitable: if we allow DEX to modify MDS and then MDS to modify INT, that is fundamentally no different to allowing INT to modify MDS and then, via whatever route, MDS to end up modifying INT.

So we have two options: we either explicitly disallow this, or find a way to make it work. I'm with Derakon on not disallowing anything where possible. To make it work, there needs to be a point at which all calculations are resolved, before moving on to the next set of calculations - i.e. we calculate MDS including a modifier based on INT, then we recalculate INT including a modifer based (somehow) on the previously-calculated MDS. IMO Derakon's idea of allowing the user to choose the order of calculation achieves this.