Pyrel dev log, part 5

[LostTemplar]

Effect animation does not work at least it CURSES and QT versions.

[Derakon]

Y'know, all this element stuff started with me wanting to implement the monster memory? But there turned out to be more prerequisites to that than I anticipated. Oh well...

I've added description strings for each element, which appear (in the WX frontend) when you mouse over the player's resistances on the sidebar. Formatting's a bit screwy -- the text leaves it up to the frontend to insert newlines where appropriate and the frontend isn't bothering -- but the concept is sound.

I also added the polymorph effect from chaos damage. Right now it happens 100% of the time for non-chaos-resistant creatures. I don't know if this is necessarily appropriate, but it's easy enough to change later if necessary.

[Derakon]

I implemented a few spell effects today -- Teleport Away, Teleport To, and Stat Swap. Here's what the data for the Nexus element looks like now:

    {
        "name": "nexus", "shortName": "Nx",
        "damageCap": 500,
        "display": {"ascii": {"color": "VIOLET"}},
        "procs": [
            {
                "name": "weighted random choice",
                "procs": [
                    {
                        "weight": 8,
                        "name": "teleport away"
                    },
                    {
                        "weight": 2,
                        "name": "teleport to"
                    },
                    {
                        "weight": 1,
                        "name": "swap stats",
                        "swapAmount": 3
                    }
                ]
            }
        ]
    },

The way I've done Teleport Away is, more or less:

Repeat 1000x:
  pick a tile within 20 spaces of the map edge.
  is that tile:
    a) not obstructed?
    b) not close to the player (i.e. within 15 spaces)?
    c) not close to the last 8 teleportation landing zones (ditto)?
    if so, move the player there.

This is somewhat lazy, but I think it should generally yield good results. It does mean that teleportation will generally send you to the map edge, but I don't think that's a huge issue for Vanilla. Might be a problem for variants with overworlds though.

Stat swap moves 3 points from one stat to another. Very simple.

[Magnate]

I guess my big concern is that the player know which effect in the monster memory corresponds to which string when the spell is cast. Sometimes this can be overly opaque -- seebs in #angband-dev noted that he thought for years that the "points and curses" was a taunt, not a damaging spell. I guess this doesn't necessitate that we use exactly the same text in both the cast message and the monster memory, but it does point to the fact that Angband's current system is not IMO ideal.

Fair point - but I think this is a problem with Angband's help system, not with the spell messages. In Pyrel you ought to be able to click on/hover over a message and have a pop-up that offers you spell info (or whatever).

[Derakon]

I would urge for more flavour rather than less. One of the big difficulties in V is the terrible string-handling, meaning messages have to be stitched together from components - this is what results in some of the more clunky messages. In Pyrel we can just have a text file with a dict of complete messages for any effect: blindCasterMessage, blindTargetMessage, confusedTargetMessage, etc. etc. etc. I'd happily write some more flavourful stuff. I think the 'advantages' of the flavourless approach are minimal - but then I always argued against Eddie trying to turn V into chess.

I guess my big concern is that the player know which effect in the monster memory corresponds to which string when the spell is cast. Sometimes this can be overly opaque -- seebs in #angband-dev noted that he thought for years that the "points and curses" was a taunt, not a damaging spell. I guess this doesn't necessitate that we use exactly the same text in both the cast message and the monster memory, but it does point to the fact that Angband's current system is not IMO ideal.

I'd be happy to see this, and I thought we were assuming UTF8 support from the off, so there are thousands of glyphs to play with.

Yes, we are. What I don't know, because I have zero experience in that area, is how capable the console version is.

No, this seems like more trouble than it's worth to me. I mean, don't let me stop you, but I don't think it gains much (if you're using UTF8). Possibly worth doing if you're gunning for ASCII compatibility.

I must admit the main use case I thought of was indicating direction of movement for a moving wall; there may well be better ways to do that, so okay, forget about it for now.

Yes, I can get behind some of these. The golden rule is that it has to make the game easier on the eye and not harder, so you need very simple rules for what's bold/underlined/etc. Nothing we have to struggle to learn.

Right, well said. The idea is to make things easier than current, not harder.

[Magnate]

1) How would you feel about having messages like "The <foo> casts Mind Blast" or "The <foo> casts Cause Major Wounds" instead of the current messages ("stares deeply into your eyes" and "points at you and curses horribly")? I recognize that the latter is slightly more flavorful (though IMO the difference is generally slight); the former would make it easier to match up in-game messages with the monster memory, though.

I would urge for more flavour rather than less. One of the big difficulties in V is the terrible string-handling, meaning messages have to be stitched together from components - this is what results in some of the more clunky messages. In Pyrel we can just have a text file with a dict of complete messages for any effect: blindCasterMessage, blindTargetMessage, confusedTargetMessage, etc. etc. etc. I'd happily write some more flavourful stuff. I think the 'advantages' of the flavourless approach are minimal - but then I always argued against Eddie trying to turn V into chess.

2) How about making use of accented characters to help differentiate monsters within a given category? For example, ë to represent beholders; putting an ´ accent generally on more powerful entities, marking carrion crawlers with ç. The idea would be to help make creatures stand out more, so that players have more than just color to work with. Of course, some combinations aren't necessarily legal ASCII combinations (though they might be legal UTF-8), but that brings me to my third question:

I'd be happy to see this, and I thought we were assuming UTF8 support from the off, so there are thousands of glyphs to play with.

3) What about having some things in the game be represented by two overlaid characters, possibly in different colors? Specifically here I'm thinking of more detailed traps; a moving wall could be represented by a # with ^v<> overlaid on it to indicate direction of motion, or a beartrap might be represented by overlaying { and } on top of each other. My experiments indicate that this won't necessarily always look good, but I haven't tried multicolor overlays yet (it'd require rejiggering the drawing code and the color-parsing code).

No, this seems like more trouble than it's worth to me. I mean, don't let me stop you, but I don't think it gains much (if you're using UTF8). Possibly worth doing if you're gunning for ASCII compatibility.

4) What about bold text, underlined text, boxed text, etc.? For example, the current resistance display is just "dark grey if you don't resist, element color if you do resist". We could extend that to "with a red outline if vulnerable" (outlined like the player cursor), "bold if double-resisted", "with a white outline if immune", etc. Of course this all requires more drawing capabilities, which may not always be available to e.g. the console implementation. But I think there's a lot of possibilities that would improve the game without sacrificing the information density that we get with an ASCII-like display.

Yes, I can get behind some of these. The golden rule is that it has to make the game easier on the eye and not harder, so you need very simple rules for what's bold/underlined/etc. Nothing we have to struggle to learn.

[Derakon]

A few questions for you all:

1) How would you feel about having messages like "The <foo> casts Mind Blast" or "The <foo> casts Cause Major Wounds" instead of the current messages ("stares deeply into your eyes" and "points at you and curses horribly")? I recognize that the latter is slightly more flavorful (though IMO the difference is generally slight); the former would make it easier to match up in-game messages with the monster memory, though.

2) How about making use of accented characters to help differentiate monsters within a given category? For example, ë to represent beholders; putting an ´ accent generally on more powerful entities, marking carrion crawlers with ç. The idea would be to help make creatures stand out more, so that players have more than just color to work with. Of course, some combinations aren't necessarily legal ASCII combinations (though they might be legal UTF-8), but that brings me to my third question:

3) What about having some things in the game be represented by two overlaid characters, possibly in different colors? Specifically here I'm thinking of more detailed traps; a moving wall could be represented by a # with ^v<> overlaid on it to indicate direction of motion, or a beartrap might be represented by overlaying { and } on top of each other. My experiments indicate that this won't necessarily always look good, but I haven't tried multicolor overlays yet (it'd require rejiggering the drawing code and the color-parsing code).

4) What about bold text, underlined text, boxed text, etc.? For example, the current resistance display is just "dark grey if you don't resist, element color if you do resist". We could extend that to "with a red outline if vulnerable" (outlined like the player cursor), "bold if double-resisted", "with a white outline if immune", etc. Of course this all requires more drawing capabilities, which may not always be available to e.g. the console implementation. But I think there's a lot of possibilities that would improve the game without sacrificing the information density that we get with an ASCII-like display.

[emulord]

I think if you want to make Mumak fire breathers, instead of messing with the damage caps, you should mess with the divisor for damage type.

HP/4 for hounds
HP/6 for most
HP/8 for golems/weak breathers.

[Derakon]

Dark blue on black is notoriously bad for everybody, not just colorblind players.

Okay, I can desaturate it:



Or change it to anything else, really.

[Pete Mack]

Dark blue on black is notoriously bad for everybody, not just colorblind players.

[Derakon]

So do I - but I can imagine a scenario where I want different cap for the same element for two different monsters. Let's say we want to give a mumak cousin a fire breath - we'd want a lower cap than for more powerful monsters with the same hp.

I could see that. I think this is one of those things that you'd possibly change if you were working on a variant -- it's not especially difficult to subvert the damage cap if you think it's a good idea.

I threw together a first pass at defining all of the resistable elements. You'll note that instead of experience drain here, I have temporary level drain. It's an idea I've always wanted to try out, since I think it'd be a lot more interesting gameplay-wise. No permanent damage to your character, however the immediate ramifications are much more severe than losing experience.

I added the "shortName" field with an eye towards the player status display and monster memory. Here's what the player status display looks like currently:



Obviously missing several fields, but they won't be hard to add. I gave the player a semi-random assortment of resistances for this screenshot. I figure that FA, SI, etc. can be fit in as well without taking up much space. More importantly, a similar display can be used in monster memory, which I want to have use a more tabular arrangement like this old example. Ideally you'd also be able to mouse over an entry in the sidebar and get a popup that gives you more information on that particular stat.

Also notice that I'm using blue for "normal value" instead of green. . This is mostly as a nod towards red-green colorblind players. I guess that this could be an option, but I don't think it's an especially huge deal for non-colorblind players to get used to blue instead of green. As your HP (or other stats) get depleted, the color will smoothly cycle through purple to red, using HSV (hue-saturation-value) to do color rotations.

Oh yeah, and the STR/INT/etc. stats will have linearized display. No more 18/x stats.

[Magnate]

Regarding damage caps: your average fire hound does ~11 damage/breath because they have 35HP. Meanwhile Glaurung has 6250HP; if he used the same formula with no cap then he'd be doing over 2k damage with a breath when he's at full health. Even resisted, that's instadeath for, say, most mages.

So I'd say we can either keep the damage cap system, or we can change the formula for calculating damage so that it has a nonlinear dependency on creature health (like a logarithmic formula). Functionally that works out to being like a damage cap -- damage asymptotically approaches some fixed value but does not cross it -- but it's not a hard "damage cannot ever exceed this". On the flipside, that makes it very hard to determine how much damage you can expect a given attack to deal -- assuming we keep the HP dependency of breath damage. Which I would like to do; I think it's a neat mechanic.

So do I - but I can imagine a scenario where I want different cap for the same element for two different monsters. Let's say we want to give a mumak cousin a fire breath - we'd want a lower cap than for more powerful monsters with the same hp.

Also, my plan for damage caps attaches them to the elements, not to the attack type. While most attacks in Vanilla that hit the cap are breath attacks, darkness storms and nether balls can potentially hit the damage cap. I understand Vanilla doesn't work this way, but I think it's more intuitive and the effect on balance will be minimal.

Yes, no problem with this at all.

[Derakon]

Regarding damage caps: your average fire hound does ~11 damage/breath because they have 35HP. Meanwhile Glaurung has 6250HP; if he used the same formula with no cap then he'd be doing over 2k damage with a breath when he's at full health. Even resisted, that's instadeath for, say, most mages.

So I'd say we can either keep the damage cap system, or we can change the formula for calculating damage so that it has a nonlinear dependency on creature health (like a logarithmic formula). Functionally that works out to being like a damage cap -- damage asymptotically approaches some fixed value but does not cross it -- but it's not a hard "damage cannot ever exceed this". On the flipside, that makes it very hard to determine how much damage you can expect a given attack to deal -- assuming we keep the HP dependency of breath damage. Which I would like to do; I think it's a neat mechanic.

Also, my plan for damage caps attaches them to the elements, not to the attack type. While most attacks in Vanilla that hit the cap are breath attacks, darkness storms and nether balls can potentially hit the damage cap. I understand Vanilla doesn't work this way, but I think it's more intuitive and the effect on balance will be minimal.

[Pete Mack]

Sounds excellent.

But why do you want a per-element damage cap, ever? Why not have a single global default damage cap?

My point is that damage caps are a kludge. If something is too dangerous it needs rebalancing for the case where it's too dangerous, not capping.

Because doing it your way would drive players crazy.
Damage caps are for breath attacks only. If different monsters have different max damage (beyond the max damage imposed by HP), then players will have to have specific knowledge of those monsters that do extra damage.

[Magnate]

Mm, this is a fair point. I see a few possible options; the simplest would probably be for the code that parses spells from the creature record to check a new file, spells.txt, before it goes to proc_templates.txt. spells.txt would allow for spells that chain several procs together. If no entry in spells.txt is found for the specified spell name, then proc_templates.txt would serve as a fallback option.

Sounds excellent.

This is the default damage cap; if you want to specify a different one for a specific spell then you can of course do so. I haven't added the code for applying damage caps yet, though.

But why do you want a per-element damage cap, ever? Why not have a single global default damage cap?

My point is that damage caps are a kludge. If something is too dangerous it needs rebalancing for the case where it's too dangerous, not capping.