feat: Improved rules regarding treasure chests by providing clarifica… #4
Conversation
…tion and removing ambiguities. Original Treasure Chest Rules: A treasure chest is always in a 3x3 empty room with exactly ONE entrance. The chest can appear in ANY of the 3x3 tiles in that room. (Yes, a treasure chest can appear directly in the entrance) Original Ambiguity halfburnttoast#1: Counter-intuitive that a tile in the room is considered the entrance. It would be clearer to treat the empty tile orthogonally adjacent to the room as the entrance. Original Ambiguity halfburnttoast#2: Based on the previous text, it seems possible for a treasure room to contain more than one chest, but this should not be the case. Treasure rooms should only contain exactly one chest. Original Ambiguity halfburnttoast#3: Based on the current entrance definition, this might be a valid setup, but it shouldn't be (1 = entrance, 0 = empty tile, X = Wall): XXX0XXXX X001100X X000000X X000000X XXXXXXXX (two connected treasure rooms). This should not be possible though. Proposal S: Each treasure room contains a single chest in a 3x3 grid of walkable tiles and has a single entry point located orthogonally adjacent and outside the treasure room. The treasure room must be fully enclosed by walls or the map border on all orthogonally surrounding sides, except for the designated entry point, which must be an empty tile. Proposal S Notes: - Addresses Counter-intuitive entrance: Proposal S specifies that the entry point should be located orthogonally adjacent and outside the treasure room, providing a clearer definition of the entrance location. - Addresses Multiple chests in a treasure room: Proposal S explicitly states that each treasure room contains a single chest, eliminating the possibility of multiple chests within a room. - Addresses Validity of treasure room connections: Proposal S implicitly restricts the formation of connected treasure rooms by emphasizing the need for full enclosure by walls or the map border on all orthogonally surrounding sides.
|
I like the idea of improving the instructions. I would like to avoid using more complex terminology when describing it, though. I imagine some people would read "orthogonally adjacent" and their eyes would glass over. |
|
On the one hand, I understand the desire to keep the vocabulary, simple, on the other, I'm finding myself hard-pressed to describe "orthogonally adjacent" more simply and equally succinct without becoming ambiguous. Any equivalent I know is either more verbose (such as: ["horizontally or vertically adjacent", "next to (non-diagonally)"]) or not as clear and unambiguous (such as: ["adjacent", "directly adjacent", "next to", "directly next to"]) Perhaps this could be addressed by marking the first occurrence of orthogonally with a "*" and having a glossary of terms at the end (or start) -- perhaps with a picture for visualization. |
|
On a related note, I've made a preliminary version of a guided example solve (a walk-though for a solution). It's still a bit rough on the edges (could do with some rectangles/highlights on the images, and some tweaks to the wording) but I'd welcome your thoughts on it. It's on the guided_example_solve branch of my fork here: https://github.com/earlyraven/Dungeon-Cross/tree/guided_example_solve. Perhaps instead of following the tutorial's scroll-able text-and-image-block form it should be a gallery of images or pages (with just next and previous instead of scrolling) or a .gif transitioning between each step. I don't think it's quite ready for a PR (unless you're fine with changes to it later), but I'd really welcome your thoughts on it. |
|
Nice work! I really like the idea of the guided tutorial. The original Dungeons and Diagrams had a guided tutorial which was far less comprehensive than what you put together. I think the visual explanation works a lot better at clearing up ambiguous language. I'll get back to you when I get some more time to look over it in more detail, but I like what I'm seeing. Unfortunately, I don't think pygame supports animated gifs. So, any animation would need to be setup like a spritesheet. I don't think it's really necessary for it to be animated, but it might be worth looking into. If it's too much trouble, I'd say we just keep it static images. |
…tion and removing ambiguities.
Original Treasure Chest Rules:
A treasure chest is always in a 3x3 empty room with exactly ONE entrance. The chest can appear in ANY of the 3x3 tiles in that room. (Yes, a treasure chest can appear directly in the entrance)
Original Ambiguity #1: Counter-intuitive that a tile in the room is considered the entrance. It would be clearer to treat the empty tile orthogonally adjacent to the room as the entrance. Original Ambiguity #2: Based on the previous text, it seems possible for a treasure room to contain more than one chest, but this should not be the case. Treasure rooms should only contain exactly one chest. Original Ambiguity #3: Based on the current entrance definition, this might be a valid setup, but it shouldn't be (1 = entrance, 0 = empty tile, X = Wall): XXX0XXXX
X001100X
X000000X
X000000X
XXXXXXXX
(two connected treasure rooms). This should not be possible though.
Proposal S:
Each treasure room contains a single chest in a 3x3 grid of walkable tiles and has a single entry point located orthogonally adjacent and outside the treasure room. The treasure room must be fully enclosed by walls or the map border on all orthogonally surrounding sides, except for the designated entry point, which must be an empty tile.
Proposal S Notes: