I'm about to violate a core tenant of Angband's user interface contract, and I'd like your advice.
Up until now, Unangband has followed Angband with regards to what can be in a single grid. In Angband, a single grid can hold:
1. a monster
2. either a trap or one or more objects or 'interesting' feature
3. if not an interesting feature or trap, then the grid must be a floor which is safe to walk on
This is a very important contract between the game and the player. That is, if there is an object in the grid, it is safe to walk on. You can actually use this to determine where traps are, by throwing objects around a room and see where they don't drop. More importantly, it allows you to interact with stacks of objects, by moving around the room, picking them up.
I'm in the process of implementing ranged traps. Ranged traps will have a region that they target, which triggers the trap when you move into it. This violates the above constraint, because you will end up with a grid that holds an object, and then a ranged trap where the region it targets includes the grids with the object.
I want to include the trap regions in the map display, to help the player avoid them. This leads to a second violation of the above contract: it's now possible to end up with a grid which is in the region of multiple traps. So I'm stuck with a user interface dilemma.
How do I display multiple trap regions, so that the player can most usefully determine which region is safe or unsafe, and the area effects of multiple regions? In Unangband, you can display up to 256 colours (more like 28 legible differences) and one ASCII character in each grid. There is no reverse video or stacking of multiple characters in a grid.
I want to be able to distinguish between the traps themselves, which you can disarm, and the trapped regions, which you can't disarm. The trap character is ^, and for historical reasons, I'd like to display the regions using x to indicate the trapped area - using the same colour as the particular trap type. I may have to use another character though, as x is already used for bridges of various kinds.
Suggestions welcome.
Monday, 15 December 2008
Violation of Contract
Subscribe to:
Post Comments (Atom)
Posts
9 comments:
I'm not familiar with historical reasons, but for UI purposes, it might make more sense to use a non-reserved color along with the trap sign (^). That way, the message is still the same to the player: If you step here, a trap goes off and it might be bad.
In the case of overlap, where a ranged-trap area overlaps an walk-over trap, I'd say give the walk-over priority. Areas should be easy enough to determine from the area they cover, so it's the singular case of the walk-over that should be noted.
In this instance, how do I associate which trap with which region it affects. I'd like a colour based association if possible.
What about a trap region that overlaps objects? How do I distinguish an object that the player may want to get, as opposed to an empty floor - both of which are within range of a trap.
Greetings Andrew. I'm just off a massive archive binge of your blog, and I must say that both the ideas you present, and their realisations (as far as I've seen in Un) are nothing short of brilliant. Great work!
As for the interface agreements, have you considered an approach based on layers? You might actually move all trap detection information on a separate sheet in another game window, so it could be placed in a term?
So it could be i.e. like that: in main term you see things as they are now (main game map, with known traps displayed, if they are not obscured by objects, and, possibly, with mo range of trap detection shown), and in the secondary trap layer term you see a portion of same screen centered on your character, but in b/w, and with coloured traps and their ranges (the same colour, but different symbol), superimposed. And those no-detection crosses go there too (as they are sometimes a little ambiguous - is there no X because detect traps detected no traps there, or was i detecting life a while ago and that removed the shroud too)
And adding a keypress to show this layer (like it's done for minimap, or inventory) in main window for those who play termless.
Is there something blatantly obvious I'm missing why this method should not work? ;)
The layer-toggle would suffice. Another idea would be to show the borders of such regions, using those cool ascii cods for single or double borders. Borders can have different colors and when they cross there wouldn't be any confusion.
BTW you may want to respond to the comments in the previous post, I admit they're rather lengthy (my own included), but IMO it's a worthy discussion :)
I'm definitely steering towards a layer toggle approach of some kind. An obvious toggle would be to switch a layer off if you are in a state that allows you to avoid that trap. Another would be to switch all layers except one off, if you are using the 'l'ook command to look at a particular trap.
ToME allows traps and objects on the same grid; Sangband also has an interesting trap system, although I can't recall if it allows traps and objects to co-exist, but it's worth a look.
I'd go either with layers (via toggle) or, for the 'multiple objects on one tile' with the Dwarf Fortress method of alternating between the two symbols. E.g. a ring on a trap would flash between = and ^.
Are the areas going to be visible when the trap apparatus itself is not?
If that's the case the player should either (S)earch when he sees one and have the areas show up over objects at that time or look at the actual trap during which time the same sort of display would show up for that trap. No color coding necessary for that one but it would take a bit longer for players to work out their chosen route, perhaps to the point of tedium.
Shoku: I've ended up with trap regions being visible even if a trap is not, making the region the same colour as the trap, and with the ability to show only an individual trap region while you are looking - done by selecting the source trap and pressing 's'.
It seems to work fine.
Post a Comment