Pyrel dev log, part 5

[Pete Mack]

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

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

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

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.

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

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]

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

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

[LostTemplar]

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

[Derakon]

Sorry about that; I may have accidentally broken it with recent changes that fixed some lack of thread safety issues. Or it may be that they've never worked properly. I haven't managed to successfully install PyQt4, and I've not yet gotten around to installing the curses libraries either, so my ability to test is necessarily limited.

I'd suggest comparing the receiveAnimation functions in the respective front-ends; the wxPyrel version should be definitive.

[LostTemplar]

Hmm, about curses code I cannot understand why it doesn't work.

However in QT code there were broken link to receiveAnimation, so it were never called, if fixed it starts working allmost. It still shows animation at wrong place (offset from corner of the window, not map) and at wrong time (explosion first, then flying projectile. Maybe due to multiple threaded execution)

[Derakon]

I finally managed to get Qt installed on my laptop, so I've started working on this. Animations are working okay; right now I'm trying to figure out why text rendering is screwy, though. QtPyrel's writeString() function isn't monospaced, which makes the sidebar and inventory display a bit screwy; however, turning it off makes things look really ugly. Compare:

Non-monospaced: sidebar, inventory

Monospaced: sidebar, inventory.

(That last image was taken after inflating the character dimensions by 1 pixel in X and Y, which is why it's bigger)

I should note that I don't particularly enjoy working on frontend display stuff, and I'm by far most familiar with the WX frontend (and with WX in general), which is why Qt and curses haven't been getting much attention from me.

[LostTemplar]

Nice, so it is only my problem.

[Derakon]

I should clarify: animations were broken; I did the necessary work to fix them (though I haven't verified explosions yet). I also did the work to make the character status sidebar display properly; right now I'm dithering about how much work I want to spend on making things look pretty.

In general I think we should only have one of the WX or Qt frontends be fully-supported, since they do the same thing (provide a windowed experience). Spending the work on supporting both is silly. Personally I find WX easier to deal with, in part due to experience and in part because of the amount of pain I went through in installing PyQt, but I understand others may feel differently.

cursesPyrel has gotten zero attention from me thus far, sorry!

EDIT: pushed my QtPyrel fixes to the repo.