From: JSwing Newsgroups: rec.games.roguelike.development Subject: Variable Scale Maps Date: Tue, 15 Oct 2002 18:20:27 -0000 Brainstorm of the month, posted for comment to rec.games.roguelike.dev Here's a common RL example: ###### #..?.# #....# #!..@# #....# ##.### For argument's sake, let the tile with the potion (!) also contain another object. There are no monsters or visible traps in the room. The player wants to do two things: 1) Pick up the stuff on the floor, and 2) Exit through the doorway (south) Conceptually, two actions. But in most RL games, this will take 7-10 key presses. The same thing occurs when a character has cleared out a level and wants to drop to the next one (or climb to the previous one). Step by step the player must guide the @ to the stairs. Tap tap tap on the keys, and ouch is my hand tired. Most games do have some shortcuts. A 'run' command is common. And plenty of games have autopickup. But I've got another idea: variable scale maps. The concept: If there are no hostiles in the room, treat the room as a single space. That is, all commands (pickup, move, search, etc) apply to all the squares in the room at once. Essentially you let the player wander around the room and perform the action repeatedly without requiring additional key presses. The details: The map has to be one that is divisible into discrete areas (rooms). Sprawling levels like Crawl has won't work, nor will mazes or the NetHack mine system. If there are enemies in the room, everything works just the way it does today. Movement, combat, and so forth are on a space by space basis. When a room is cleared of enemies, commands are applied to the room as a whole. So if a player presses the key to pickup items, he goes through a multi-item pickup procedure that includes every item in the room. If the player searches for secret doors, he searches all of the walls at once (and the floors for traps, etc). Movement also becomes easier. Label each of the room exits with a number (0-9). The player presses the number and bam - the character is at the numbered exit. If the next room is similarly cleared, the process repeats, allowing the player to zoom through known and conquered areas of the dungeon quickly. If the room contains a hidden (unknown) trap, moving around the room (required of almost any room-scaled action) sets it off once. If the trap is known, the player automatically avoids it. If the player wants to access the trap, let them use a ^ key (or somesuch). This makes traps more significant, even for pure random placement. If the room has a unique feature (fountain, forge, whatnot), the player can access the feature without bothering to manually move the @ on top of it. Using the feature insta-moves the character to the feature location, to handle results like monster spawning. The look/examine command also expands to cover the whole room. I'd recommend a mini-list with the colored symbol followed by the description so the player can associate the text with the icon like: The room contains: ^ - pit trap ? - a Scroll of ZZZ (unidentified) ! - a Potion of Speed, and a Dagger Others' tastes may vary, and the result is always implementation (and screen space) dependent. The system could also be expanded to cover an entire level for climbing up or down stairs. If the level is cleared out, a simple climb stairs command ought to take the character to the stairs and then up or down. Mostly useful for climbing out of side dungeons. Action costs: How much should the room sized actions cost, in terms of energy/turns/food? I suggest it should be a fraction of the cost of doing the tasks individually. Maybe half, or a quarter of the cost. I'm thinking that when a character isn't under pressure (threat of combat) he can focus more on the non-combat task at hand. Or you could go with a cost based on the size of the room, or even a low fixed cost. Conceptual implementation: Each monster has a zone of control. This is the square the monster is on and the surrounding 8 squares. xxx x@x xxx When one or more of the floor squares of a room is covered by a monster zone of control, then room-scale operations are impossible. If none of the floor squares of a room are covered by a monster zone of control, then operations are room scaled (if applicable to the action). Counting the area immediately around the monster handles the case where monsters are standing in a doorway. The radius is only one square to prevent it from leaking through walls. Of course, monsters with a ranged attack have a greater area of effect than melee monsters, so the zone of control could be set to to the range of a monster's attack, but it would require a light-source type check to prevent the zone from flowing through a wall. Practical implementation: The game needs to include a Room data structure. This would contain data for the floor locations (a simple UL , LR combination for square rooms), and a number for room-scale vs single space operations. The number would be the number of squares in the room covered by a monster zone of control. As long as it is greater than zero, the game uses single space operations. If the game includes different sides (where the monsters might interfere with each other) then there will need to be a value for each side. Each floor space gets a new attribute: Zone of Control. This is a reference count for the number of monsters whose zone of control covers this square. If the game includes different sides then there will need to be separate data values for each side. As a monster moves (or dies), the monster's zone of control moves and the reference counts get updated. The floor space also gets a pointer to the appropriate Room structure. If the reference counts change to or from zero then the room structure gets updated. The code to perform actions can check if the room the player is in has zero monster zones of control. If so, the action is applied to all squares in the room. Side effects: Tinkering on paper, I noticed that this alters chases somewhat. In a dungeon level that is empty but for a pursuer and victim, and the two are separated by more than one space, the time a chase involves jumping from one room exit to another, with little chance of cornering the victim as long as the rooms have more than one exit. If the dungeon level is not empty (or wandering monsters appear) then the chase gets resolved once the wandering monster is encountered, since it blocks the player from jumping from room exit to room exit. If the two are adjacent, then they proceed on a space by space basis. I haven't figured if this needs to be fixed yet. Unresolved: If the room-scale player action takes multiple turns, it would be possible for a monster to arrive and interrupt the player. At this point the player's position is undertermined, as is the state of anything discovered so far. Some reasonable algorithm is needed for this case. not difficult, just unfinished. Comments? JSwing