Pyrel dev log, part 5

[LostTemplar]

Nice, it now works.

[Derakon]

I started work on implementing proper melee combat -- shouldn't be too hard -- and came to a realization: because the player is now Just Another Creature, a lot of rules that were specific to the player now apply to creatures as well. Most relevantly, items carried by creatures are now subject to being destroyed by elemental attacks (and if creatures were smart enough to equip items, then they could be damaged by acid and disenchantment too).

I don't know how much of an effect this will have on overall loot availability, but it will mean that mages see fewer items than before, since most of their early attacks are elemental. I suppose there's some interesting tradeoffs here -- want that potion that monster is carrying? Don't use cold attacks on it! -- but handling them properly would require much better messaging of what is in a given monster's inventory.

Also, my plan for weapons that have slays is to allow slays on any creature category. The player is a creature category. There could (potentially) be weapons of Slay Player.

Lorgan, Chief of the Easterlings smites you. -more-

[ekolis]

Why are players a race unto themselves? Shouldn't that be slay human, or slay half-orc, or slay kobold, or whatever race the player actually is?

[Derakon]

They also have those attributes, just like a monster could be a natural evil troll or something.

I've implemented melee combat for the player. It uses the finesse/prowess system originally implemented in v4. In short, this means:

* The player has finesse and prowess instead of to-hit and to-dam.
* Weapons have balance and heft (typically these two values sum to 1)
* # blows = 1 + balance * finesse / 10
* Damage multiplier = 1 + heft * prowess / 10
* Base damage = roll of damage dice per blow

Slays add onto the damage multiplier, so e.g. if your base multiplier is 3 and you have a flame brand +2, then your multiplier is 5 vs. monsters not resistant to fire.

Elemental brands deal their extra damage as elemental damage, and can apply (at reduced strength) to resistance monsters. It is still the case that only the most powerful slay or brand takes effect -- and that takes monster resistances into consideration.

I've implemented a new system for critical hits. We'll see how it plays. It's a supercharge system; as long as the game can pass a 1 in (2 / (heft * prowess)) check, your damage multiplier is increased by 1. For a .5/.5 weapon, the odds of getting a level-1 crit are 1 in 8; for a .25/.75 weapon they're 1 in 10. So "unbiased" weapons tend to get more and better crits, while badly biased weapons get few and worse crits. This doesn't really scale at all through the game though, so crits won't have as much of an impact on endgame damage as they do in Vanilla. I'm not entirely certain about this system. I could change it so that crits multiply the multiplier instead of adding to it; functionally this means that a level-1 crit doubles damage, level-2 triples, etc.

Messages have been consolidated:

You attack the Filthy street urchin (10) [smite 10]
You attack the Yellow mold (9) [hit 6, hit 3]
You attack the Yellow mold (11) [hit! 7, hit 3]
You attack the Filthy street urchin (14) [miss, burn 14]

Exclamation points indicate critical hits; the more exclamation points, the better the crit.

Incidentally, you might think that that "smite" message means I was using a weapon of Slay Evil. Not so! One of the daggers in Debug Town is a Dagger of Slay Townsfolk.

I regret nothing.

EDIT: went ahead and changed it to 1.5 / (heft * balance), which means about a 1 in 6 chance for unbiased weapons to 1 in 16 for maximally-biased (.1/.9 split). Also changed it so crit multipliers apply after all other multipliers, so a level-1 crit doubles damage, level-2 triples, etc.

[Magnate]

Wow - progress! Why did you decide to change the crit system from the one in v4?

[Derakon]

IIRC the one in v4 ended up meaning that no attacks early on were crits, while every attack later was a crit. Not quite that bad, but the scaling was way off, and I don't think it was fixable (it used something like "if finesse * balance > X, or prowess * heft > Y").

Also, supercharge systems for crits just plain make sense.

[Magnate]

IIRC the one in v4 ended up meaning that no attacks early on were crits, while every attack later was a crit. Not quite that bad, but the scaling was way off, and I don't think it was fixable (it used something like "if finesse * balance > X, or prowess * heft > Y").

Also, supercharge systems for crits just plain make sense.

Yes, I was thinking of the supercharge mechanic in v4, rather than the crit threshold. But while we're on the threshold, I think you have it backwards - I think balanced weapons should critical very rarely, the whole point being that they deliver smooth, steady damage for pretty much any build. Extreme finesse weapons should deliver *lots* of little crits, and extreme prowess weapons should deliver a lower number of vastly bigger crits. That, to me, is the sense of the fin/prow system.

[Derakon]

Hm, I was trying to think of a bonus for using the unbiased weapons, since they'll otherwise be strictly inferior for most classes (since their stats will be heavily biased towards either finesse or prowess). But I suspect you're right. The better way to make unbiased weapons more attractive is probably to have the sum of their balance and heft exceed 1. So a Longsword might be a .6/.5 weapon instead of .55/.45, say.

As for frequency of crits, remember that prowess characters already get very few attacks compared to finesse characters. I think crit frequency and the effects of crits on damage should be the same for both character types. If 10% of your blows do 2x damage, then the finesse character will see regular crits that have a small effect on their total damage while the prowess character will occasionally completely destroy their target with a single blow, and that sounds fine by me.

[LostTemplar]

Finesse and prowess are already main combat stats, so crits, based on them basically adds nothing. Crits may be a good way to make something else to contribute to combat ability. E.g. crits depending on intellect or perception may be fun.

[Derakon]

I've just pushed an initial version of monster memory to the repo. When you hit the '/' key, the game prompts you for creature name, and then searches for a monster with that name. If it can't find one, then it finds the best matches it can and asks you to pick one:



Then it brings up information on the creature:



This is based on the monster memory mockup I made awhile back. It's not complete -- most obviously, I don't have spell information up yet because no monsters have spells yet (they need to be copied over from the old data files), but also I have rather anemic drop information (I spent basically zero time on figuring out how to describe LootTemplates), and the melee descriptors look kind of weird. But the basic principle is sound.

[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?

[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.

[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.

[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]

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)