Pyrel dev log, part 5

[Derakon]

Putting balance and heft in as the primary weapon stats does sound reasonable. Good idea.

Regarding having e.g. "<+5 fin>", any thoughts on having pvals generally display short text for what they modify? In Vanilla it's just "<+4, +1>" and the like. v4's items tend to have longer names in general, and I suspect it's only going to get worse in Pyrel...

[Magnate]

I think a good middle ground to take is to display the Balance / Heft numbers and move +Pro and +Fin to the pvals.
Simlarly, I'd like to see the base level affixes to modify balance and heft rather than prowess and finesse... a "sharp" dagger does nothing for my kobald's ability to hit hard, but does affect how much of his meager arm strength the dagger can convert to damage. So as a sample, something like:
Sharp Dagger of Finesse (1d4, 90/15) <+48 fin>

That still leaves it where an explanation is going to be required for the newbies at one point or another, but it puts the most important weapon characteristics under this system immediately visible.

I think I agree with this - balance/heft are much more significant than +fin/prow.

Please rest assured that there are affixes that affect balance and heft, as well as those affecting fin and prow. In the interests of game balance, the former are rarer and deeper than the latter.

[Kilumanjaro]

I think a good middle ground to take is to display the Balance / Heft numbers and move +Pro and +Fin to the pvals.
Simlarly, I'd like to see the base level affixes to modify balance and heft rather than prowess and finesse... a "sharp" dagger does nothing for my kobald's ability to hit hard, but does affect how much of his meager arm strength the dagger can convert to damage. So as a sample, something like:
Sharp Dagger of Finesse (1d4, 90/15) <+48 fin>

That still leaves it where an explanation is going to be required for the newbies at one point or another, but it puts the most important weapon characteristics under this system immediately visible.

[Derakon]

I don't disagree with that, but you have talked elsewhere about the importance of intuitiveness / noob-friendliness. I don't know whether you think about those things specifically through the lens of V or just roguelikes/gaming in general - but I think a lot of people will think "oh, those are plusses to hitting and damage" because that's a common RPG convention. If you go with the prominence, I think it would help to make it a very early piece of tutorial help that +fin has no effect on accuracy and +prow has only an indirect effect on damage.

Hm, that is a good point. Unfortunately, I think we're kind of stuck here -- we can either hide that information (e.g. by mixing it in with all the other "pvals") and piss off everyone, or show it prominently and confuse newbies. Unless you have a brilliant idea?

I think honestly the way to go here is to have a tutorial that explains things. We'll need one anyway.

[Magnate]

Correct, every modifier on every Item (and almost every modifier on every Creature*) is just an entry in the Stats entity for that object. I do think there's some value in giving prominence to the "most important" stats for an object (thus dice, fin, and prow for weapons, and absorption/evasion for armor), but that's just for purposes of easy legibility.

I don't disagree with that, but you have talked elsewhere about the importance of intuitiveness / noob-friendliness. I don't know whether you think about those things specifically through the lens of V or just roguelikes/gaming in general - but I think a lot of people will think "oh, those are plusses to hitting and damage" because that's a common RPG convention. If you go with the prominence, I think it would help to make it a very early piece of tutorial help that +fin has no effect on accuracy and +prow has only an indirect effect on damage.

* curHitpoints, nativeDepth, and experienceValue are not stored in the Stats entity for whatever reason, but we could easily move at least the latter two into it. I think curHitpoints should probably stay as a separately-tracked value since the game does want to know when things die.

Yes, that makes sense. Good idea to move the other two in.

[Derakon]

No wait, I'm getting confused, aren't I? +fin/prow are *already* treated the same as pvals in the code, aren't they? So we're only talking about the display. I think it might do more harm than good to display (+fin, +prow) where V displays (+hit, +dam), as they're fundamentally different. My suggestion would be to relegate both to wherever pvals are inspected.

Correct, every modifier on every Item (and almost every modifier on every Creature*) is just an entry in the Stats entity for that object. I do think there's some value in giving prominence to the "most important" stats for an object (thus dice, fin, and prow for weapons, and absorption/evasion for armor), but that's just for purposes of easy legibility.

* curHitpoints, nativeDepth, and experienceValue are not stored in the Stats entity for whatever reason, but we could easily move at least the latter two into it. I think curHitpoints should probably stay as a separately-tracked value since the game does want to know when things die.

[Magnate]

I guess this depends on if most weapons will modify accuracy or not. If not, then the accuracy value can go into the pval list, which is already arbitrarily-long.

That's a very good point. Is there any reason why fin and prow shouldn't go into that list too, given that they are now all members of the same homogenous Stats instance?

No wait, I'm getting confused, aren't I? +fin/prow are *already* treated the same as pvals in the code, aren't they? So we're only talking about the display. I think it might do more harm than good to display (+fin, +prow) where V displays (+hit, +dam), as they're fundamentally different. My suggestion would be to relegate both to wherever pvals are inspected.

[Derakon]

That's good to know. I guess the main concern for a nested-dict setup is how long it'd take to load player knowledge when the program starts up, since you have to initialize the whole thing in one go.

I expect most of the accessing is going to be done by e.g.

player.getKnowledge('creature', creature.name, 'magic', 'spells', spell.name)

in any case, since doing otherwise would mean having to manually check for the existence of many, many sub-dicts, making any access of player knowledge into super-ugly code. So it may not matter much what the actual structure is behind the scenes, since only small portions of the code would have to deal with it. A nested-dict structure would be easier for humans to examine, but once the code is reasonably mature, that's no longer much of an issue.

Incidentally, mtadd, thanks for submitting all those pullreqs recently!

[mtadd]

I hadn't looked at the relevant code before throwing out my idea for storing the player knowledge. I think a hierarchy of dicts is the most flexible, and is the right choice.

However, if performance is a consideration, it'd be faster to have all the keys in one dict, and represent the hierarchy through the respective key names, rather than a hierarchy of dicts, due to the extra calls made to __getitem__ descending through the tree. Attached is a script (run with ipython) that shows 3 implementations (nested dict, flat dict, flat set), and their resulting memory size, as well as time to fill and access, respectively.

create nested dicts
1000 loops, best of 3: 848 us per loop
size 1048
access 1 1000 loops, best of 3: 375 us per loop
access 2 1000 loops, best of 3: 687 us per loop

create dict with path keys (i.e. creature.Fire Hound.magic...)
10000 loops, best of 3: 132 us per loop
size 12568
access 1 10000 loops, best of 3: 119 us per loop
access 2 1000 loops, best of 3: 213 us per loop

create set
10000 loops, best of 3: 148 us per loop
size 8424
access 1 10000 loops, best of 3: 120 us per loop
access 2 1000 loops, best of 3: 214 us per loop

Though the flat key uses more memory (multiplier scales with levels in tree) to store the paths through the tree, the puts and gets are about 3 times faster. As always, there are tradeoffs, and as this isn't a critical path of execution, I'd go with the nested dict, as you suggested originally. Just some food for thought here.

[Derakon]

If we're having a separate accuracy stat then we need to move to triplet plusses in item naming:

A Sharp Dagger of Flame (1d4) (+fin, +prow, +acc)

I guess this depends on if most weapons will modify accuracy or not. If not, then the accuracy value can go into the pval list, which is already arbitrarily-long.

[Magnate]

I definitely think this is appropriate in some cases, and monster memory is an excellent example of that. On the flipside, I think affix knowledge ought to be binary ("I recognize this affix and therefore know everything it contributes to the item" vs. "I don't recognize this affix"), just to simplify the ID "game" even further.

This is assisted by the fact that the intention of affixes is that they each modify only one thing: they confer one flag, or modify one stat.

At the moment some modify +hit/+dam, which made sense under the old system but does *not* make sense under the fin/prow system, so I will separate them out. If we're having a separate accuracy stat then we need to move to triplet plusses in item naming:

A Sharp Dagger of Flame (1d4) (+fin, +prow, +acc)

[Derakon]

Maybe knowledge could be fuzzy, for instance, instead of actually displaying the damage dice rolls for a given attack {2d10+5}, you display a damage range that the player actually experienced {7-12}, by tracking min/max damage experienced by the given attack.

I definitely think this is appropriate in some cases, and monster memory is an excellent example of that. On the flipside, I think affix knowledge ought to be binary ("I recognize this affix and therefore know everything it contributes to the item" vs. "I don't recognize this affix"), just to simplify the ID "game" even further.

This makes a good argument for using a dict as the underlying structure instead of a set. I don't have a strong opinion about your LDAP-style "path" key system; any particular reason why we would want the structure to be, effectively, flat instead of a bunch of nested dicts?

[Magnate]

Instead of a hierarchy of dict() like player.knowledge['creatures']['Fire hound']['magic']['spells']['breathe fire'], you could have a set() of keys, where each key is a path through the structure above, like in LDAP, e.g. "creatures.Fire hound.magic.spells.breathe fire".

This only applies if knowledge of a particular attribute is boolean, either known or unknown.

Maybe knowledge could be fuzzy, for instance, instead of actually displaying the damage dice rolls for a given attack {2d10+5}, you display a damage range that the player actually experienced {7-12}, by tracking min/max damage experienced by the given attack.

I don't have the knowledge to recommend a better coding structure, but +1 for fuzzy knowledge - hugely flavourful IMO.

[mtadd]

Instead of a hierarchy of dict() like player.knowledge['creatures']['Fire hound']['magic']['spells']['breathe fire'], you could have a set() of keys, where each key is a path through the structure above, like in LDAP, e.g. "creatures.Fire hound.magic.spells.breathe fire".

This only applies if knowledge of a particular attribute is boolean, either known or unknown.

Maybe knowledge could be fuzzy, for instance, instead of actually displaying the damage dice rolls for a given attack {2d10+5}, you display a damage range that the player actually experienced {7-12}, by tracking min/max damage experienced by the given attack.

[Derakon]

When Angband's monster data initially got converted into JSON for Pyrel, the spells list was omitted. Today I went through and brought the spells back in, which was mildly laborious. I uploaded the mapping I used to rename the spells since Pyrel's datafiles are moving away from the FLAG_IN_CAPS style that Angband uses. Feel free to suggest different names.

The spells haven't all been implemented yet, so right now monsters will waste a lot of turns trying to cast spells that don't exist. But the groundwork has been laid; now it's mostly just a matter of filling in the gaps.

Anyway, as a result, the monster memory looks more or less complete:



The only remaining things I want to see are damage estimates for the spells, and better drop descriptions. Well, and some mouseover data, but that's going to be hard to communicate in a screenshot. I've laid the groundwork for mouseover information -- if you mouseover the player's elemental resistance grid in the wxPyrel frontend you'll see descriptions of the elements, for example -- but it hasn't been tied in everywhere yet.

In a different direction, I've been spending some time thinking about player knowledge. One possible way to do this is to just have a dict in the Player class that contains all of the keys the player knows about. So when they learn that fire hounds can breathe fire, for example, the game would set player.knowledge['creatures']['Fire hound']['magic']['spells']['breathe fire'] and player.knowledge['creatures']['Fire hound']['magic']['frequency']. Helper functions would make interacting with such deeply-nested dictionaries less painful.

This seems like a kind of hokey approach to the problem, but it does seem like it'd work. Any thoughts?