The Tavern

If a feature never kills anybody (assuming good play), then it didn't really exist.

dpeg wrote:If a feature never kills anybody (assuming good play), then it didn't really exist.

Dont worry, plenty of people dont assume good play. Also, luck is a feature i can get by rolling invisible dice inside my head, i dont have to play crawl for that feature. I have to play crawl if i want features that resemble a dungeon crawling hack'n slash role playing type of game. It actually baffles me that i have to read from you, one of the devs of this game a like a lot, something like that. Way to undervalue the huge learning curve i went through(and still going) with this game.

dpeg wrote:If a feature never kills anybody (assuming good play), then it didn't really exist.

Yea, I never got what baseball's selling point is.

dpeg wrote:If a feature never kills anybody (assuming good play), then it didn't really exist.

I mean if you take that logic and apply it to some of the people here then there basically isn't a game after the first dungeon floor

I have several serious replies in this thread. It's not my fault if you don't get them (and there more, and better replies by other posters to help you in your plight.)

Here's a weird suggestion to solve the "memorizing trapless tiles" problem:

Instead of random traps, shafts have a chance to trigger when using a staircase. Whenever you use a downstair to access an unexplored level, there's a random chance for "that staircase had a shaft trap in it!" and then you get shafted for 2-3 floors (only shafting 1 floor wouldn't make much sense anymore). This should only happen when trying to reach an unexplored level so that backtracking players don't have an incentive to avoid not-yet-used staircases.

The risk of multi-shafting is also removed since it only works on down stairs and players who have been shafted will be going up instead.

"The stairs grind and turn, and reveal themselves to be a slide!!"

Getting shafted to V:5 is a problem because of crawl's branch layout, not because of shafts. The fact that V:5 should be completed after U:5 is completely counter-intuitive to a new player.

It would probably be possible to rig up something that uses exclusions to mark all untouched tiles with lua to address the trap issue. Seeing that in action might inspire some soul searching re: traps.

genericpseudonym wrote:Here's a weird suggestion to solve the "memorizing trapless tiles" problem:

Instead of random traps, shafts have a chance to trigger when using a staircase. Whenever you use a downstair to access an unexplored level, there's a random chance for "that staircase had a shaft trap in it!" and then you get shafted for 2-3 floors (only shafting 1 floor wouldn't make much sense anymore). This should only happen when trying to reach an unexplored level so that backtracking players don't have an incentive to avoid not-yet-used staircases.

The risk of multi-shafting is also removed since it only works on down stairs and players who have been shafted will be going up instead.

1)it's not a weird suggestion, you're strange for thinking that
2)your version is a little convoluted when it can instead be implemented with little work: remove shafts and disguise unused escape hatches as stairs (unless the hatch cannot be a stair, e.g. special vault, or you've seen the 3 stairs already)
3)why would shafting 1 floor not make much sense anymore???
4)"an incentive to avoid not-yet-used staircases" is not a bad thing. It's a good thing! There is currently too much incentive to take lots of stairs while exploring, IMO.

2) If the shaft thing only works when the player hasn't yet seen all 3 stairs then it won't usually affect anyone other than speedrunners. If you hit O until the floor is explored like most players, you will almost always see all 3 staircases before you take one.

3) If it's already on the staircase then shafting one floor is no longer dropping you into an unexpected out-of-depth area, although it still means you'd land somewhere without a nearby up staircase.

4) My apprehensions about this would be after e.g. finding an amazing artifact bow and going up 1-2 levels to pick up a pile of arrows you left behind. If unused staircases could still shaft you then Hypothetical Optimal Man would have to specifically walk to the already-used staircase on the trip back down, instead of just using the closest one.

2)um, I meant "unless you've seen the 3 stairs and confirmed that they are indeed stairs, by using them (or by seeing their other ends on the other level??).
3)well I think many people would concur that it's bad enough to land on a new level and potentially not find any stairs until you've explored the whole level. The "extra-out-of-depth" part is icing IMO and irrelevant out of D. Also, it is sometimes good to take downstairs before you've explored the current level, so you can't assume that the player will be comfortable with the next level.
4)ok so this is a consequence of shafting for 2+ floors which is not necessary

I agree with you, HardboiledG. 2+ floor-shafting causes more problems than it's worth.

The super trollish intent of whatever dev created shafts is right there in the name.

"You fall through a shaft!" aka you are shafted.

SHAFTED. The game literally shafts you.

How much more are we players expected to endure before we simply SNAP and overthrow the GDs?

For what it's worth, some devs would prefer that players "snap and overthrow them". It's more often called "creating a fork" and perhaps "hosting your own server", and it's very good for the health of the game.

I like game mechanics that are designed to have a chance to end a run. But, the player should also be given the choice to avoid or try to avoid with intent those mechanics.

In this case, it used to be detect traps. Now I think it's an INT check if i'm not mistaken. Don't remember.

Maybe he's made because he thinks they can't be avoided at all.

Trap detection is entirely based on your XL, which means characters less prepared to face traps are more likely to step on them, which for me is a way to aknowledge that traps are meant to end the game of unprepared characters rather than put prepared characters into interesting situations.

dynast wrote:Trap detection is entirely based on your XL, which means characters less prepared to face traps are more likely to step on them, which for me is a way to aknowledge that traps are meant to end the game of unprepared characters rather than put prepared characters into interesting situations.

i think that's more of a weird legacy leftover from the immediate post-traps&doors period than something that had conscious design intent. i don't think any of crawl's devs have ever thought "boy, i hate low-level characters, let's randomly kill some of them off to increase how unfair the game is."

all before wrote:Getting shafted to V:5 is a problem because of crawl's branch layout, not because of shafts. The fact that V:5 should be completed after U:5 is completely counter-intuitive to a new player.

v:5 is very intentionally more dangerous than the preceding level, a distinction it shares with elf:1, slime:1, and others. like elf, it warns the player of this by immediately tossing them into a huge ambush that signals danger, but isn't especially dangerous if the player leaves quickly.

also, as people noted earlier in the thread, the problem you're talking about can't happen. naturally spawning shafts will never send players onto certain especially dangerous levels, including v:5.

I think shaft traps are good and fun, unlike shadow traps which were bad and unfun (mainly because they didn't go away after being activated once and being a worse effect than Zot traps most of the time). However, if the main issue about them is remembering safe floor to avoid shafts when exploring, why not tie the effect to downward staircases instead?

When the player descends a downwards staircase into a level that has not been generated yet (that isn't the bottom of the branch), roll for a chance to see if the player gets shafted instead ("You fall through a weak section of the staircase for 3 floors!"). This would not go off when using trapdoors (already effectively a one floor shaft), ascending staircases or descending into levels that have already been generated. The effect would remain unchanged (drop you on a random part of the level you fall onto, won't shaft you into branch ends like V:5), and can be tweaked to occur at the same frequency as it does currently. The main difference is that a player may be more prepared for a bad landing (by pre-buffing, for example) because they were already planning to go downstairs, but that might relieve some complaints about shafting so I see that as a benefit myself.

Shaft traps themselves could still generate for the purposes of vaults (if needed), but should always generate visible.

Shaft Traps could *always* send you to a vault. Vaults could be made for this specific purpose, so you don't go from D4 to D7 but rather to "Shaft 1", which is a small level dangerous to a typical D4 character. After all, presumably the trap is intended to drop you into a dangerous situation (both in game and fluff terns). Have it do that by design.

Basically, make shaft traps into non-optional portals to interesting encounters. This feels close to the current intent but avoids some of the (heh) pitfalls of the current model.

Floodkiller wrote:I think shaft traps are good and fun. However, if the main issue about them is remembering safe floor to avoid shafts when exploring, why not tie the effect to downward staircases instead?

That's one way to address the problem. My preferred solution would be something different, because stair-shafting means that you can better prepare for it (for example, you'll always rest up HP/MP before descending to a new level).

So I would say that simply walking has a small chance to shaft you. Because shafting to an already explored level is not cool, the chance depends on how much you've explored on the levels x+1,x+2,x+3 (assuming you're at a depth where 3-level shafts are possible).

Today I won a GhGl^U, and I realised that --for me-- shafting is extra fun if portal vaults are involved: you get sent to D:5, monsters are nearby, and you get the message about that timer. I love it.

Shafts rule and my most memorable crawl characters are ones I survived very tense situations with. Exploring a new level with monsters that are often too strong to fight head-on, desperately searching and "diving" upward is something you don't get in any other part of the early game, and it's a blast. Keep them forever.

PleasingFungus wrote:i think that's more of a weird legacy leftover from the immediate post-traps&doors period than something that had conscious design intent. i don't think any of crawl's devs have ever thought "boy, i hate low-level characters, let's randomly kill some of them off to increase how unfair the game is."

Yet it remains. Calling a bad aspect "legacy leftovers" does not diminish or dismiss how bad they are. Someone who thinks traps are a good idea would want to change that so it stays relevant throughout the whole game.

Edit: You people who loves shafts reminds me of that guy who comes to your house to play games and when its his turn he finds the most boring way possible to get through the game, to the point you get so bored you have to slap the controller out of his hands for something interesting to happen.

dynast: We need a formula! Filing a complaint won't help, even though the complaint is valid.

Why not just remove the formula? You have to trap detection, ever.

in principle i'd be fine with that; in practice i worry about something like tomb, where the place is totally filled with zot traps

probably trap detection shouldn't scale with level (though you could give some fixed trap detection chance, idk), but you'd want to rethink how generation works so chars in late-game/extended aren't tripping over shit constantly

Idk why tomb bothers you, wasnt the whole point of the place to be filled with traps that you step on? Also most of them are activated by scarabs and other things so its not like it changes much.

PleasingFungus wrote:in principle i'd be fine with that; in practice i worry about something like tomb, where the place is totally filled with zot traps

probably trap detection shouldn't scale with level (though you could give some fixed trap detection chance, idk), but you'd want to rethink how generation works so chars in late-game/extended aren't tripping over shit constantly

I think a proper design would be this: for each branch, there's a set of trap types and chances. And whenever you move single step in that branch, there's that chance to trigger one of those steps -- regardless of where you've stepped before.

As always, the devil is in the details: we don't want shafting L:1-->L:3 when all of Lair is already fully explored. New webs in Spider are fine, I think (and they work differently that I lay out above).

dpeg wrote:I think a proper design would be this: for each branch, there's a set of trap types and chances. And whenever you move single step in that branch, there's that chance to trigger one of those steps -- regardless of where you've stepped before.

As always, the devil is in the details: we don't want shafting L:1-->L:3 when all of Lair is already fully explored. New webs in Spider are fine, I think (and they work differently that I lay out above).

If you want a system like this (where a fully explored level is considered trap safe), you would want to tie trap triggering to the reveal of unexplored tiles.

dpeg wrote:My preferred solution would be something different, because stair-shafting means that you can better prepare for it (for example, you'll always rest up HP/MP before descending to a new level).

You... don't already do this? You don't rest up HP/MP before descending to a new level? I thought that was default behavior.

Why do you want people getting shafted to be damaged on top of being shafted?

dpeg is saying people can't rest always rest up to full before getting shafted since it happens unexpectedly, but if shafting only happened when you took stairs you could always rest before shaft

...but currently shafting only happens when exploring (unless you fail to mark walked-over explored tiles) so you'll be at full hp/mp anyway...

duvessa wrote:(unless you fail to mark walked-over explored tiles)

I don't know anyone who actually marks walked-over tiles. Besides you, I guess. For a normal player's experience, shafting usually happens when exploring, but also sometimes when retreating/running away or whatever.

Yeah I don't retreat into potentially trapped tiles if I can avoid it (and I pretty much always can). I also don't see how the number of players that do it is relevant to the design problem.

Speedrunners also exist.

In .18, does L8 count as a branch end? If so, I just got shafted from L5 to L8, which I thought was impossible.
I'm not complaining, I'm just curious if this was a bug or not, I'll live ;0

Arrhythmia wrote:Speedrunners also exist.

While true, if shaft traps are meant to only be threatening to speedrunners they're very, very silly.

I agree that normally one doesn't explore on less than full health and MP, or at least that one shouldn't do that if they're trying to win. Of course, there's always the small chance of getting shafted while repositioning in a fight, that for whatever reason has to take place in unknown territory. If you always drag enemies back to explored territory, that's not a concern.

infinitevox wrote:In .18, does L8 count as a branch end? If so, I just got shafted from L5 to L8, which I thought was impossible.
I'm not complaining, I'm just curious if this was a bug or not, I'll live ;0

"Shafts cannot take you to branch ends" is a lie. Shafts cannot take you to the last levels of Elf, Swamp, Shoals, Snake, Spider, Slime, Vaults, Crypt, Tomb (but shafts can't be created there anyway), Hells, Zot. Other branch ends, like Lair and Dungeon, are fair game.

Anyway if you want to keep traps then just make it so that traps are triggered when they come into LOS, not when stepped on. Then don't let vaults place traps. That's all you have to do. No more trap avoidance.

Floodkiller wrote:When the player descends a downwards staircase into a level that has not been generated yet (that isn't the bottom of the branch), roll for a chance to see if the player gets shafted instead

Apply this to upwards stairs as well and I'm sold

Shard1697 wrote:I don't know anyone who actually marks walked-over tiles. Besides you, I guess. For a normal player's experience, shafting usually happens when exploring, but also sometimes when retreating/running away or whatever.

You don't have to literally mark squares. You can improve your chances of winning by putting some effort into exploring in a systematic "default" way. Crate likes to link some tv where he dies to a (spear? blade?) trap while fleeing down a hallway in Crypt. He wouldn't have hit the trap if he had, say, a habit of defaulting to exploring and fleeing in multi-tile hallways on the right side, when there's no reason not to.

No, I don't do this. The point is, although duvessa tends to describe the extreme end of the tedious behaviour, there are more realistic less extreme compromises between tediousness and effectiveness. But that's not a tradeoff you want your players to have to consider, all else equal.

Lasty wrote:For what it's worth, some devs would prefer that players "snap and overthrow them". It's more often called "creating a fork" and perhaps "hosting your own server", and it's very good for the health of the game.

er,
so devs (disgruntled ones?) would prefer it + it is good for the game's health? If the fork is good and devs take a liking to it, it means that devs don't have a clue about what they're doing. If players and devs migrate to the fork and abandon the stone soup branch, that kills the game (tho it's good for the DC family?) And if devs react to the fork and mirror it to keep ahead, that means they have to be pressured in order to make decisions, and stall otherwise. There's no way to understand this that doesn't cast the devteam, as a collective, in an unflattering light... What did I miss?

HardboiledGargoyle wrote: What did I miss?

The entire concept of open source software.

It isnt a competition, the current stone soup contributors arent trying to "win" or "be the best branch", they are taking a project they like and contributing to it in a way they think makes it better, if someone else contributes code that they like and think is better then they will integrate it if they dont they wont.

if some people would rather contribute to a different fork, if they do so in a way that the stone soup contributers arent interested in, then they can ignore it, and if they like it, they can just pull that code into their fork. More forks just means more options to pick and choose from, worth less work.

There is nothing that "paints them in a bad light" there is no light, for that matter there is no "them" it is just a bunch of individuals who decide to do some stuff in their spare time, collectively, nobody has to prove anything to anyone else.

Liking something that someone else does doesn't mean you are bad at it, artists can like other people's art without it meaning they are bad artists.

HardboiledGargoyle wrote:If the fork is good and devs take a liking to it, it means that devs don't have a clue about what they're doing.

No? It doesn't mean that at all. Why would it mean that?

HardboiledGargoyle wrote:
Lasty wrote:For what it's worth, some devs would prefer that players "snap and overthrow them". It's more often called "creating a fork" and perhaps "hosting your own server", and it's very good for the health of the game.

er,
so devs (disgruntled ones?) would prefer it + it is good for the game's health? If the fork is good and devs take a liking to it, it means that devs don't have a clue about what they're doing. If players and devs migrate to the fork and abandon the stone soup branch, that kills the game (tho it's good for the DC family?) And if devs react to the fork and mirror it to keep ahead, that means they have to be pressured in order to make decisions, and stall otherwise. There's no way to understand this that doesn't cast the devteam, as a collective, in an unflattering light... What did I miss?

That's a long walk to take in order to find a way to cast a bad light on the devs. If you really feel that way about this, then I can only imagine how hard it is for you when others succeed at anything you do.

On the contrary, I feel that product matters; who makes it is not relevant. With the caveat that product is determined by maker, and thus restricted. I'm thinking hard, how you found envy in my post.
I looked at all possible ways the forking can be good for the game and drew the implications - that's not a long walk, and if it is, what's the short walk?
(I didn't oppose your original statement, but was fazed that you wrote it, with what looks like sincerity)

Shard1697 wrote:
HardboiledGargoyle wrote:If the fork is good and devs take a liking to it, it means that devs don't have a clue about what they're doing.
No? It doesn't mean that at all. Why would it mean that?

because, um, they wouldn't have opposed it in the first place, if they knew what they were doing. How else to understand?

that assumes that forks are only created for ideas that have been discussed beforehand, instead of say a completely new idea that the devs haven't heard of

CanOfWorms wrote:that assumes that forks are only created for ideas that have been discussed beforehand, instead of say a completely new idea that the devs haven't heard of

Or that the devs didn't implement an idea because they didn't like it, rather than several other possibilities (laziness, crawl devs preferring conservative gradual changes, etc.).

i like a lot of the stuff in dcss-ca but 95% of it is never making its way into vanilla (conservative estimate)

like, look at this list of scroll ideas. nuts, but very cool in its own way

just a different design philosophy

Not that the original post implying that appreciating forks reveals a conspiracy by the Developer Illuminati was anything but trolling, but of course the devs behind a fork could take the time to implement something useful for DCSS that we don't have the time/expertise to implement ourselves. The vast majority of changes in the fork might be things the original project doesn't want, but they can incorporate only those changes in the fork they do want, and then the fork has been valuable to the original project.

We'd take reasonable changes/features/implementations from anywhere, including a fork like dcss-ca with very different notions for what's good design. That dev might just find the time to implement some interface, refactoring, or functionality we've been wanting but that took very substantial work or that we simply hadn't thought of in the first place.

I think it's worth looking to NetHack as an example of a "family" of forks that has resulted in some significantly improved games, and the latest version of NetHack included a lot of the work that was done in forks during the decade between releases.

I'd also just love to play some forks that actually offer some concrete examples of what the game would be like if we followed some players' design sensibilities to their logical conclusion. An actual implementation of duvessa's idea of Crawl would be really interesting, as would crate's and tabstorm's. Or, on the opposite end, I'd love to see what a real Sandman25Crawl or BerderCrawl would look like, though I think dcss-ca is handling that extreme pretty well, all things considered.

In conclusion, though I hate food, I love forks.

The Tavern

Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service

Re: Terrible design choice and service