AnonymousHero wrote:
Yeah, I'm leaning towards removing traps entirely too. I've removed them entirely (or, rather, prevented them from spawning) in one of my private branches and have played a few (short-ish) games and I can't say I miss'em at all in terms of game play.
Same here, of course. I stuck with the partial removal because it's less radical, and leaves a role for trap detection spells etc.
My biggest issue with removing them completely is that this leaves a kind of a strange vacuum in terms of there being useless skills[1]/spells. One approach that I've thought about a bit is to allow monsters to create traps (via spell), but to not have any floor traps (perhaps allow inside vaults?). Another approach might be to remove all the instantly-game-ending traps which necessitate 100% detection and simply not have 100% detection in the game -- however, this risks ending up in "a couple of unlucky trap spawns kills character randomly with no possible way to prevent it" territory. But maybe we should just remove *everything* trap-related to give room for a re-think.
The former case, hmm... Yeah, that could be problematic.
The latter is (obviously?) the one I favor. The main reason for avoidance being the amount of code grepping involved, and the existence of monster traps.
Though, on further thought, monster traps are
pretty darned useless. Maybe the entire trap morass should be torn out.
... And yes, for the record, I am volunteering to do that.
I'll have plenty of time before New Year's.
I'll be brutally honest that I'm also slightly motivated by the desire to get rid of the thousands(?) of lines of code required to support traps. (This has to do with a probably-overly-ambitious code conversion project that I've sort of embarked upon... but I don't want to get anyone's hopes up too much in case it never goes anywhere.)
That would be nice in view of lengthy C++ compile times too.
Re the code conversion... What do you have in mind exactly? GoLang, Rust, or such? (I should really start learning one of those.)
[1] ... but let's face it: Any method of finding traps which isn't 100% isn't going to fly in T2, given the extreme nastiness of some of the traps.
Another reason behind my "partial" solution above. If we're going to have traps, it should at least be possible to know where they'll pop up. But I still prefer your solution of removing the current trap code.
EDIT: Fun little addendum: Removing traps leaves Antimagic users with exactly one useful activatable "spell" based on the Anti-magic skill
, namely Continuum distruption. Maybe that should be streamlined such that any
player-initiated teleportation automatically succeeds and enemy teleportation automatically fails (or prompts?) -- though I'd hate to be the one to find all the places where code needs to be changed to achieve this effect
.
Hmm. The streamlining makes sense mechanically, not sure about thematically though. If that, then why not allow AM characters to use devices too? Or, uh... something. AM doesn't make much sense anyway, really.
Thought: maybe get rid of Unbelievers entirely, and merge the Antimagic multiplier into Spirituality, for better saving throw if the player wants?
... Actually I like that latter, because removing AM would allow simplification and de-kludging of the magic code, IIRC.
Also I like the thematic implications. If you want to be a warrior in a world full of wizards, you'd better have good connections.
... and having given it a little more thought: Someone over on the oook forums suggested a few trap ideas, but one that stuck out to me as having great potential was the idea of traps being "static terrain" that was part of the dungeon with timed effects based on player proximity. Those effects could be a timed poison cloud, arrows being fired every turn while you're in line of the trap (or even "one-square-per-turn-speed" radius 1 clouds), maybe a circular "blast" effect whenever you're in a certain radius, whatever.
This is how traps work in Unangband. The problem in Un is that they are
incredibly deadly, and nobody has good trap detection. So my advice in the above case, would be to also make them permanently visible, at least as a generic "unknown trap" feature.
I also think such things would best be done after I rip out the existing trap code.
I think this would could lead to interesting random 'puzzles' if traps were generated randomly in close proximity to one another -- esp. in tight spaces such as vaults.
Indeed. That'd be something to consider for future versions... Maybe some of the monster code could be recycled for that? Traps as stationary monsters with very few vulnerabilities?
Edit: in the meantime though, I'm going to file a pull request for my branch above, so that we have improved gameplay in the mean time.
Guess I'll just have to proceed with ripping out the trap code.
