Proposal for an upper bound on turns taken: Zot Specters

[Nasst]

I know a lot has been said about food (and its removal) already, but I need to repeat some of what's already been said to provide the necessary context for this conversation. Firstly, I agree with the position that the only function food fulfils in its current state (0.25) is preventing exploits resulting from having limitless turns. These are things like waiting thousands of turns on stairs until monsters come to LOS. These tactics are tedious and feel very scummy, if by chance any of them happened to be optimal, it would be a loss for the game as a whole.

Now, how would food look like if it was more cleanly designed for that goal alone? I imagine a scenario like this:

• No chunks, or nutrition costs.
• Goldified rations.
• No [e]ating rations, rations automatically going down after a fixed amount of turns.
• Plenty of rations: no one starving unless they're doing something exploity

While this scenarios is certainly better than the current status of food. I would argue it still has significant problems:

It's unnecessarily transparent: A mechanic intended to limit a class of obscure exploits should not be part of the information that is given to most players, given that is not relevant to them. New players expect that the information given to them will be relevant.

It's a global clock, instead of a per-level one: A global clock essentially "rewards" you for finishing a dungeon level in 2000 turns instead of 3000. This might not be tactically relevant (if food is plentiful enough), but that clashes against players intuitions, which leads me to my next point...

It misuses player intuitions about food: There are many, many games where food is a scarce resource to be preserved, where hunger is a real threat. Players often come to crawl with these intuitions. We should work with player's expectations, not against them.

How do we solve these problems? Introducing: the Zot Specters.

The idea is simple: after a huge amount of time in a level, we start spawning an enemy which is unkillable, granting no xp, piety, or any other reward. The spawn rate should be constant, and, since the enemy is unkillable, they'll start accumulating in the level making it more and more dangerous. The mechanic should be obscure to most players: even playing a weak background/species combo, resting, luring, and running around, you should never encounter a Zot Specter. Once you do encounter a Zot Specter, the reason should be clear when reading its description. ("These damned souls, cursed to serve the orb for all eternity, will come after you if you spend too much time in the same part of the dungeon"). A Zot Specter can be damaged as normal, but any damage that would kill it, instead teleports it into another part of the level, avoiding feel-bad situations where a player dies after being trapped by a specter with no access blink/teleport. The specters should have a source of low but guaranteed and unavoidable damage (smite for example), so they can't be used as shields.

[Siegurt]

Note that the work to remove much of food-related stuff is currently underway already:

https://github.com/crawl/crawl/search?o ... pe=Commits

[Nasst]

Note that the work to remove much of food-related stuff is currently underway already:

https://github.com/crawl/crawl/search?o ... pe=Commits

Thanks Siegurt! Yes, I was aware. My proposal intends to address the (admittedly minor) problem of potential exploits resulting from a lack of food.

[petercordia]

This proposal sounds quite similar to the hell-crawl clock.
I hate that clock. One of the main reasons I don't play Hellcrawl very often.

Sometimes a floor takes a little longer. It feels nasty to be unable to finish a floor.

[andrew]

Well one could make the per-level clock something huge (10000 turns, say, or even more). Hellcrawl's is 3000, right?

[Hellmonk]

I don't think a per-level clock works well unless you restructure the dungeon to eliminate backtracking or make the clock so generous as to be toothless. Otherwise you end up in awkward situations where the clock appears to punish players for actions unrelated to scumming, or in the worst case could block them with an unclearable level they must return to without killing them outright. There are ways around this, but they introduce more complexity to the clock design.

Gonna write up my clock thoughts in a separate thread.

[bel]

The OP is talking about a very narrow case: how to prevent "infinite" scumming. For this purpose, a per-level clock is sufficient, assuming that the number of turns is high enough (which the OP says it is).

The OP is not at all the same as the Hellcrawl doom clock. That clock has many problems which I've discussed in the Hellcrawl thread, among other places. One main problem with it is that it's a fixed amount (3000 turns -- which is not large enough, unlike the OP), and it is unrelated to the hardness of the floor.

[andrew]

Well as Hellmonk says, though, there would still be a problem if (for whatever reason) a floor ended up in an effectively untraversable state. I suppose it might be ok if Zot Specters start spawning slowly, and the player is clearly warned.

[vt]

The mechanic should be obscure to most players: even playing a weak background/species combo, resting, luring, and running around, you should never encounter a Zot Specter.

I suspect it will be hard to meet this constraint with a per-floor limit without allowing faster players playing stronger combos to engage in some wait-scumming. Looking at some of the longer games in 0.25+, both of myself and overall, I suspect you probably want at least ~30k auts a floor, and depending on how strictly you want to take the constraint, maybe more. (Esp. if you're given the same amount of time for Vaults 5 and for Lair 3!) I'd say that's enough time for a more melee oriented and stronger character to shout for several hundreds turns on the stairs and still complete the level comfortably.

There's a huge range in what a "normal" time frame is for a 3-rune game.

Unless you think the problem with waitscumming is literally the volume of auts you can put into it if you want (I don't, really---it's pretty bad gameplay even if you can only do it for a thousand turns each floor) I suspect it's hard to fix it this way without making a clock that actually rushes slower characters along.

[andrew]

I was assuming that the goal is only to prevent the most extreme forms. (I'm biased; my first win, Z:5 took me something like 10000 turns.)

[Siegurt]

So here's some "crawl" specific problems with a hard (or even medium hard) clock that need resolving:

1. There's a wide variance in the number of aut's it's "reasonable" to spend on a level, Ogres for example have a large HP pool put poor defenses, meaning they have to spend a lot more auts resting than say, gargoyles, and playstyle and character build can all have a very large impact on 'reasonable time spent'.
2. Generally less powerful choices need to use more auts, any clock that puts real pressure will cause the diversification between weaker and stronger setups to be greater, lower game replayability.
3. Crawl's back-tracky nature means that you can spend an arbitrary amount of time trolling around levels you've already cleared, sometimes this is "travel back to get that thing I left on the floor and want to switch to using" but the same series of actions could be interpreted as "wait scumming" depending on circumstance, there's not a good mechanical way to distinguish between the two. (That's why putting a timer on literal "wait" actions is useless, since you could bypass such a timer by simply macroing walking around in a circle or what not, similarly you can't make the wait timer reset when you leave a level, because any sort of "wait scummy" actions could just as easily be replicated by macroing back and forth between levels)
4. Different floors have different amounts of turns that it's "reasonable" to spend on them, and there's not an easy way to extract what that value is.

Until you have a solution to those problems (And probably other ones I hadn't thought of or explicitly mentioned), any sort of clock implementation will fail, either it will provide no incentive to not wait-scum, or you'll end up punishing some cases where someone was just taking the next indicated action and not actually engaging in any sort of abuse.

Also there needs to be a definition for what is "wait scummy" actions, what sort of benefits are provided by having an unlimited number of turns you could wait, if all such benefits are eliminated (I'm not sure it's possible to do so) then there's no problem with having no clock, because tedium is only a problem if it can provide an advantage.

I suspect at least one of these is possible, but difficult.

[andrew]

Another problem with per-level clocks: assuming they're lenient enough to not constrain normal play (which seems to be what's wanted), you'll usually still have significant time left on the previous floor's clock. Whereas you won't know yet how long the current floor will take you. So it will be optimal (even more than now) to always go back upstairs to rest.