I think traps are fine the way they are, but on the other hand they are only dangerous to new characters, up the damage done by gas, dart, pit attacks, for deeper levels.
Future of Angband development
Collapse
X
-
-
Anything that doesn't give 100% trap detection is a failed concept, because it implies that it is acceptable for the player to be randomly attacked with no possibility of preventing it. That's why hidden traps are such a terrible idea. Sure it's realistic for them to be hard to discover. But it doesn't work gameplay-wise.
You think that making it impossible (or impossibly tedious) to reliably detect traps will somehow make them fun?
Passive 100% trap detection when adjacent to them works reasonably well -- that's what Dungeon of Dredmor does. You can be surprised by a trap while in the middle of a fight, but at least you're given a choice of how to deal with it, instead of just being randomly afflicted by the trap's effects.
tl;dr traps need to be more than a "play in a tedious fashion or accept being randomly dicked over" mechanic.
Yes, I think making it impossible to reliably detect traps will make them more fun (as long as the traps aren't instadeath). It's probably better for it to be completely impossible than just tedious and more trouble to prevent people from being tempted to play in a tedious way.
It's okay for traps to be not reliably detectable as long as they aren't deadly. I think the best solution is for traps to be significant, damaging, but not deadly. Traps are already very rarely deadly. 'Randomly dicked over' is what Angband often does to you anyway. As long as it isn't an unavoidable instadeath, then 'randomly dicked over' is a perfectly acceptable game mechanic.
To me, it'd be a lot more frustrating for something very bad to happen from a trap that I saw one turn ago, but accidently moved into, than for something bad to happen from a trap that I was unable to detect.Will_Asher
aka LibraryAdventurer
My old variant DaJAngband:
http://sites.google.com/site/dajangbandwebsite/home (defunct and so old it's forked from Angband 3.1.0 -I think- but it's probably playable...)Comment
-
If you detect traps 100% of the time when adjacent to them, there's no reason for them to be hidden in the first place (of course in the current system their being hidden doesn't have much point either). And if they aren't hidden, then you can't really call them traps -just obsticles.
As for the rest of your post, I think we'll simply have to agree to disagree, since I take the opposite stance on every single statement you made.Comment
-
Teleport (because that can be instant death, and it is very annoying even without)
Trap door (just because that can ruin your day when you are clearing GV)
Summoning is OK if we apply "summoning sickness" IE. summoned monsters start with zero energy (they could still act before you do if they are faster than you, but that's not so likely).
Then rest of the traps are somewhat OK. I think that paralysis and slow are only two really dangerous after that, and both are safe with FA.Comment
-
Originally posted by Will AsherTo me, it'd be a lot more frustrating for something very bad to happen from a trap that I saw one turn ago, but accidently moved into, than for something bad to happen from a trap that I was unable to detect.www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.Comment
-
If you leave those two and remove reliable 100% fail proof detection I have to agree with Derakon.Comment
-
This is fixed for 3.4 btw - summoned monsters start slowed for one turn, so they're at 10 speed less than normal, *and* they start with 0 energy. They can still move before you if their native speed is >10 higher than yours, i.e. you're at +9 and they're at +20 - but this should not be very common ..."Been away so long I hardly knew the place, gee it's good to be back home" - The BeatlesComment
-
I think the discussion turned against 100% reliable passive detection. I don't think anyone spoke out against 100% reliable active detection. Then again I didn't re-read, so my recollection of recent post might be skewed.www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.Comment
-
I can think of two traps I want to remove from game in order to make 'Randomly dicked over' acceptable:
Teleport (because that can be instant death, and it is very annoying even without)
Trap door (just because that can ruin your day when you are clearing GV)
Summoning is OK if we apply "summoning sickness" IE. summoned monsters start with zero energy (they could still act before you do if they are faster than you, but that's not so likely).
Then rest of the traps are somewhat OK. I think that paralysis and slow are only two really dangerous after that, and both are safe with FA.Comment
-
I can think of two traps I want to remove from game in order to make 'Randomly dicked over' acceptable:
Teleport (because that can be instant death, and it is very annoying even without)
Trap door (just because that can ruin your day when you are clearing GV)
Summoning is OK if we apply "summoning sickness" IE. summoned monsters start with zero energy (they could still act before you do if they are faster than you, but that's not so likely).
PS: sorry to tangent to DAJ talk when the thread is supposed to be future of (V) Angband development. Maybe I should post this as a separate thread instead?Will_Asher
aka LibraryAdventurer
My old variant DaJAngband:
http://sites.google.com/site/dajangbandwebsite/home (defunct and so old it's forked from Angband 3.1.0 -I think- but it's probably playable...)Comment
-
To me there is a difference between trap door and traps that can lead to an unavoidable death. If I'm plundering a vault or about to kill a boss and fall down a trap door, that's ok for me. One cannot get everything that one wants, and there will be more chances to find loot.Comment
-
Forget about "how" for a second, just list here what you think could be better.Comment
-
I think damage dice of middle weapons could use rebalancing, to offset the lack of blows compared to lightt weapons, in example change damage dice values.Comment
-
Tweaking of the object list to get the balance right is implicit in v4 IMO. We've argued about it over and over again and at this point I think the devs are just going to implement what they think were the best ideas from the lot and we'll see how it plays. It's going to be an iterative process.
Similarly, there were discussions about trying to limit the player's knowledge more, for example by nerfing detection. Some of that's been done already -- object detection now doesn't show you exactly what item is on a tile, just that there is an item there.
Extending that to limiting monster detection could probably be done fairly straightforwardly, with a number of possible levels of delineation. For example, you could remove extended 'l'ook, but leave everything else the same -- then players who have memorized the monster list will have an advantage. You could detect the letter but not the color of the monster (black and white monster detection, basically), which eliminates that advantage. Or you can try to get fancy with detecting threat levels, coloring the monster based on their relative danger rating. Again, this is an area where I expect we'll want to experiment some.
Malak: per your specific idea, what problem are you trying to solve? The fact that small weapons are preferable to large ones in the early game? Boosting midweight weapons won't fix that (at least, not in isolation); it'll just make those weapons too good later on. The problem with lightweight weapons largely comes down to off-weapon combat bonuses. If a warrior gets 3 blows/round and +3 to damage from his STR rating, then a 1d4 dagger (+0,+0) is more or less equivalent to a 3d4 bastard sword (+0,+9), which of course isn't going to be available early on.Comment
-
Tweaking of the object list to get the balance right is implicit in v4 IMO. We've argued about it over and over again and at this point I think the devs are just going to implement what they think were the best ideas from the lot and we'll see how it plays. It's going to be an iterative process.
Similarly, there were discussions about trying to limit the player's knowledge more, for example by nerfing detection. Some of that's been done already -- object detection now doesn't show you exactly what item is on a tile, just that there is an item there.
Extending that to limiting monster detection could probably be done fairly straightforwardly, with a number of possible levels of delineation. For example, you could remove extended 'l'ook, but leave everything else the same -- then players who have memorized the monster list will have an advantage. You could detect the letter but not the color of the monster (black and white monster detection, basically), which eliminates that advantage. Or you can try to get fancy with detecting threat levels, coloring the monster based on their relative danger rating. Again, this is an area where I expect we'll want to experiment some.
Malak: per your specific idea, what problem are you trying to solve? The fact that small weapons are preferable to large ones in the early game? Boosting midweight weapons won't fix that (at least, not in isolation); it'll just make those weapons too good later on. The problem with lightweight weapons largely comes down to off-weapon combat bonuses. If a warrior gets 3 blows/round and +3 to damage from his STR rating, then a 1d4 dagger (+0,+0) is more or less equivalent to a 3d4 bastard sword (+0,+9), which of course isn't going to be available early on.
Note that I'm only proposing rebalancing a few extra ponts on a die, nothing drastic like adding another dice to the roll, to become in effect like a heavy weapon. bastard sword 3d4 becomes 3d5 just a few points difference but slightly greater damage output than your 3 blows from a dagger, basicaly 3d4,there is a reward for the 1 blow per round if it hits and that is doing 15 points damage vs 12 points total damage from a dagger.Comment
Comment