Thoughts on v4

[CunningGabe]

I have just returned after a long absence, and I've been giving v4 a try. I could scarcely resist when I saw that two long-standing subsystems -- combat and ego items -- had been shaken up. I'm currently playing a High-Elf Warrior and playing slowly to get a feel for what's new. Here are some of my thoughts:

- Early combat is much harder than it used to be, in a good way. It used to be that a warrior (especially a high-elf) could just cream pretty much any monster it ran into very quickly. Now I hear the sound of a miss much more often, and I see the phrase "you failed to harm <it>". It hasn't been so dangerous that I've gotten myself killed (yet), but it does give me more pause before fighting something.

- On that note, I love the new finesse/prowess system. Partially it's because I'm a system junkie, and this is an interesting system that I'm sure it takes a long time to master. Partially it's because we finally have *some* way of differentiating all of the myriad weapons other than damage dice.

- Similarly, the evasion/absorption system works very nicely with the finesse/prowess. I'm just starting to realize that it has become even more important to pick your battles. If you have a high finesse, then monsters with high evasion are easier for you, whereas if you have a high prowess, then monsters with high absorption are easier.

- On to items. First of all, I really like the new affixes system. It's taken a little getting used to -- for example, I keep thinking that a Such-and-Such of Protection is going to be something more than just a passive AC boost. I'm still pretty shallow (DL20 or so), so I haven't run into anything really interesting yet, but I'm curious to see what does come up.

- I'm still trying to figure out completely the way to think about runes vs. properties vs. flags vs. affixes. I guess some things (like being "Sharp") are intrinsically obvious, and those are what properties are?

- I like that a lot of the tvals/svals have been converted to affixes -- particularly because I imagine that makes it easier for, say, better "basic" armor types to appear deeper.

All in all, I'm excited by all the changes! I'm hoping to contribute some of my own soon, though maybe not so sweeping in scope as these ones

[Magnate]

Welcome back - I'm really glad you're positive about v4. It was born during your absence, and we missed your counsel during the debates.

On the fin/prow stuff, Derakon only did an initial pass through the weapons to assign the values, so please feel free to tinker with them when you feel like it. Also, we haven't made (m)any changes to the dice of weapons, which we can now do with a clear conscience. Finesse weapons ought to be higher dice and lower sides, with prowess weapons vice versa. (The critical chance ought to favour finesse to reflect this, because prowess crits will be bigger - it doesn't yet, though of course finesse gets more blows so more rolls for crits.)

On affixes, there's never been an obvious solution to naming items, though Nomad did suggest a matrix system (where items are named using adjectives which are selected from a table according to their final properties, without using the affixes themselves in the name). Any individual improvements to affix names would be most welcome - e.g. something less promising for a standard AC boost.

- I'm still trying to figure out completely the way to think about runes vs. properties vs. flags vs. affixes. I guess some things (like being "Sharp") are intrinsically obvious, and those are what properties are?

My thinking is like this:

- properties are the lowest order of thing and have the widest domain: they include everything about an object, from stats, resists, slays and suchlike to dice, sides, weight, balance, heft, base_ac, +fin, +prow, +ac, etc.

- flags are a subset of properties which happen to be represented as OF_ flags in the code. Players should have no interest in which properties are flags and which aren't, it's purely a code-level distinction, and is the somewhat arbitrary result of historical decisions about the object struct. It would be possible to turn all properties into flags in order to treat all properties consistently in the code, but it's questionable whether this would be a net gain.

- runes are used purely for ID, and currently map to flags. Instead of turning all properties into flags it would be possible, but complicated, to code up additional runes for non-flag properties - we haven't tried this yet. Some runes should be obvious to some or all characters under some or all circumstances. There is almost certainly a really neat way to code an obviousness matrix that we haven't found yet.

- affixes are another internal device, used for item generation - but also currently used in item naming. If we use Nomad's proposed naming system, affixes could and should become completely invisible to players, like flags. Affixes can affect any number of properties of an item, but always affect at least one property and should generally affect fewer rather than more. In particular, affixes should only affect one flag-based property, in most cases. (Since multiple properties can be defined with themes.)

- currently, affixes and runes overlap because squelching is done by affix and not by rune. Whether an affix is "known" (and can therefore trigger squelching if all affixes are known) is determined by whether all its properties (both flag/rune and non-flag) are known. This is currently decided by some wonky code like attack_plusses_are_visible and defence_plusses_are_visible and so on, and could benefit from being reorganised. (It's also been agreed that v4 can usefully dispense with pseudoID since runes render it pointless.)

More on this anon. Thanks for making me think it through.

[fizzix]

On the fin/prow stuff, Derakon only did an initial pass through the weapons to assign the values, so please feel free to tinker with them when you feel like it

The same goes for absorption/evasion. I chose values that looked reasonable on paper based on calculations. I'm glad to hear that you think it's reasonable. Regardless, I'm sure there's room for improvement here also.

[CunningGabe]

On affixes, there's never been an obvious solution to naming items, though Nomad did suggest a matrix system (where items are named using adjectives which are selected from a table according to their final properties, without using the affixes themselves in the name).

That's not a bad idea, as long as the matrix can be specified in an edit file (as the affixes themselves are).

- flags are a subset of properties which happen to be represented as OF_ flags in the code. Players should have no interest in which properties are flags and which aren't, it's purely a code-level distinction, and is the somewhat arbitrary result of historical decisions about the object struct. It would be possible to turn all properties into flags in order to treat all properties consistently in the code, but it's questionable whether this would be a net gain.

Agreed. As much as I am for making the game as modular as possible, there has to be a bottom layer somewhere!

- runes are used purely for ID, and currently map to flags. Instead of turning all properties into flags it would be possible, but complicated, to code up additional runes for non-flag properties - we haven't tried this yet. Some runes should be obvious to some or all characters under some or all circumstances. There is almost certainly a really neat way to code an obviousness matrix that we haven't found yet.

- affixes are another internal device, used for item generation - but also currently used in item naming. If we use Nomad's proposed naming system, affixes could and should become completely invisible to players, like flags. Affixes can affect any number of properties of an item, but always affect at least one property and should generally affect fewer rather than more. In particular, affixes should only affect one flag-based property, in most cases. (Since multiple properties can be defined with themes.)

Okay, the pieces are starting to settle into place in my head a little more. If an item has only a single affix, would it be named with just that affix?

- currently, affixes and runes overlap because squelching is done by affix and not by rune. Whether an affix is "known" (and can therefore trigger squelching if all affixes are known) is determined by whether all its properties (both flag/rune and non-flag) are known. This is currently decided by some wonky code like attack_plusses_are_visible and defence_plusses_are_visible and so on, and could benefit from being reorganised. (It's also been agreed that v4 can usefully dispense with pseudoID since runes render it pointless.)

Certainly agree that pseudo feels really silly at the moment. I like the idea I saw somewhere here of just seeing how many identified vs. unidentified runes there are.

Thanks for the thorough explanation!

[d_m]

On affixes, there's never been an obvious solution to naming items, though Nomad did suggest a matrix system (where items are named using adjectives which are selected from a table according to their final properties, without using the affixes themselves in the name). Any individual improvements to affix names would be most welcome - e.g. something less promising for a standard AC boost.My thinking is like this:

Without having thought through Nomad's solution or others, I do think it's important to avoid littering names with "of Sharpness" and "of Protection" if those just translate into a simple numerical bonus to prowess or absorption.

[Magnate]

Okay, the pieces are starting to settle into place in my head a little more. If an item has only a single affix, would it be named with just that affix?

Yes - this goes for both a prefix and a suffix, so one of each is also easy to name. Where an item gets more than one prefix or more than one suffix, the highest "level" one is used in the name (where level is one of bad, average, good, great, uber) - if both are the same level, it just uses whichever appears first in the edit file.

Note that themed items always take the name of the theme, but that the theme is only ever a prefix OR a suffix, meaning you can have a Prefixed Item Of Theme or a Themed Item Of Suffix.

[Derakon]

Note that themed items always take the name of the theme, but that the theme is only ever a prefix OR a suffix, meaning you can have a Prefixed Item Of Theme or a Themed Item Of Suffix.

Can you have a Themed Item of Other Theme? Or can each item only have one theme?

[Magnate]

Can you have a Themed Item of Other Theme? Or can each item only have one theme?

Only one theme. Themed items are in general significantly more powerful than un-themed items. A theme is just intended to mean "bunch of affixes designed to work well together like old ego items".

[Nomad]

Oh, yes, my promise to try and tackle the naming issue. Unfortunately I've been horribly busy of late and may still be for some months yet, but anyway, my thinking ran roughly along these lines:

* Add a 'category' field to ego_item.txt, and group together affixes of equivalent value, so that all base four resists are category 'base4', all stat sustains are category 'sustain', etc.

* Create a new edit file, ego_group.txt, with entries in the format:

N: priority : category : affix_is_obvious : group name

Where:
- priority is an ordered ranking rising from 0 (least important) to n (most important)
- category lists all the same categories specified in ego_item.txt
- affix_is_obvious is a boolean for whether the affix conveys bonuses with visible pvals, or whether it's only noticable when you look at the Inspect screen
- group name is the collective name that's used when an ego has multiple affixes from the same category, e.g. a shield with two base4 resists would use the group name 'of Resist Elements'

* When naming an item, step through the list of affixes, looking up the category information for each one. Store the priority of the first affix, and then for each subsequent affix, compare priorities.

Pseudocode:

IF this affix has higher priority than the stored best
   set this as the new best affix

ELSE IF this affix has equal priority to the stored best
   flag that this item has multiple 'best' affixes and should use the collective category name

ELSE IF this affix has lower priority than the stored best
   check the boolean affix_is_obvious
      if affix is not obvious, flag that item has hidden affixes

Then use the overall best affix as the final name (or the collective name if it's been flagged that there are multiple 'best' affixes). If the item has hidden affixes, add some sort of notation such as an asterisk to indicate that there's more to be seen on the inspect screen.


So by this system, if you set up the priorities in ego_group.txt so that FA > base four resists > AC boosts, you'd get this:

- A shield with FA and an AC boost would be named Shield of Free Action (AC boost is obvious, so no need for * notation)
- A shield with FA and rFire would be named Shield of Free Action* (* indicates to Inspect to see the non-obvious rFire affix)
- A shield with rFire and rCold would be named Shield of Resist Elements (best affixes are equal so use collective group name for them)

...Or something along those lines.

[CunningGabe]

Oh, yes, my promise to try and tackle the naming issue. Unfortunately I've been horribly busy of late and may still be for some months yet, but anyway, my thinking ran roughly along these lines:<snip>

Looks good! That's much cleaner than I imagined it would be.

[Nomad]

Looks good! That's much cleaner than I imagined it would be.

Yes, it does sound nice and neat before I have to figure out how to actually get it working code-wise.

[debo]

Everything looks cute until you write it in C