Tag: the box

RPG-ology #31: Screen Wrap

This is RPG-ology #31:  Screen Wrap, for June 2020.


This was originally published on June 29, 2001, at Gaming Outpost, as Game Ideas Unlimited:  Screen Wrap.

I usually call it “recursive occlusion”; but that’s because that’s what Peter Davison’s Doctor called it in Castrovalva, and now that I get around to thinking about what that means he must have been referring to the method of construction—that the Master had built a trap for him by creating a world based on a formula in which each element was dependent on all previous elements, resulting in a blockage of all exits.  But that’s not important.  The idea is a lot simpler than that.

Years ago there was a video game called Tank.  Tanks would wander around the screen trying to shoot each other.  Thing was, in the early versions you could shoot off the top of the screen and the bullet would come in at the bottom; or you could shoot off one end and have it come in the other.  In some versions you could actually drive the tank that way, off one side and on the other.  It wasn’t the only game that did that, and it was a simple solution to a basic problem:  what do you do about the boundaries?

But it’s an idea I’ve used many times to mystify and confuse my players—and in more variations than you might have imagined.  But if you’ll come with me for a moment, I’ll try to help you imagine a few.

The first one’s easy.  The characters enter some sort of complex—a section of tunnels in a dungeon, an area of rooms and hallways in a space station.  As they pass a certain point, they are inside the boxThe box is clearly marked on your map—it shows that any exits to the east connect to those to the west, and those in the north run to those in the south.  If a character walks into that last ten-foot section on the edge of the box, he’s immediately teleported to the first ten foot section on the other side, so going out one side means coming in the other.  Only one of the entrances is also an exit.  You will be surprised at how many times the players will redraw the same configuration of tunnels before they realize that something is amiss.

The second variation takes the idea to another level.  I did this to one player once, and I’m not sure he figured it out even after someone explained it to him.  I put the same room in two different places on the map.  I denoted them with subscripts so I could keep them straight.  Because they were the same room, if you entered the room, you were in both places at once; but when you exited the room, you always left from the other one.  They weren’t far apart in this experiment—which actually added to the confusion, as he entered the first, left the second and walked back to the first, and drew it twice, but in the wrong position.  At one point part of the party left the room and came back, and then when they all left together they got split up, because some had entered the first room and some the second, but they all were together whenever they were in the room.

You could use this idea to move characters very long distances—another dungeon, another space station, another planet.  You don’t even really need the rooms—you can just use some innocuous looking door.  Looking through the door, you see another room; step through the door, you’re in a room that looks just like the one you saw, but isn’t it.

These ideas have basically focused on keeping the player character inside the box.  You can as easily turn it on its head, and use the same principles to keep him out of the box.  For example, If you’re walking down corridor A and reach room 210, you next pass through a transfer point that takes you to corridor A outside room 280; if you reverse, the transfer will take you from 280 back to 210.  If the player doesn’t know the room numbers or layout, he won’t realize that he’s been moved—until he completes other sections of the map which go around this blocked area, and discovers that the distance between two points in the A corridor is an awful lot shorter than it should be.  You can make it so that access to that central area is only from a specific entry direction, such as above or below or a particular lesser-used corridor (but it can be exited at any point at which it connects).  Or you can determine a sequence of events or “switches” that must be activated to open the area to the characters, such as finding the key, or deactivating the grid, or realigning the circuits at every entrance.

I used an idea like this for a Minotaur’s labyrinth once.  My players were good; they could map a maze in a minute, comprehend any convoluted corridors I created.  The worst thing about facing a Minotaur isn’t the beast itself; it’s the fact that you’re on it’s turf, and it knows how to get everywhere while you’re wandering lost.  But once you’ve mapped a bit of it, it’s pretty easy to keep from getting lost, and the beast’s advantage is gone.  So what I did was create a layout of halls that frequently ran the same distance in the same direction, but parallel to each other a dozen feet apart. Then I put “transfer points” in the halls such that if you were going one direction you would get bounced to another hall, but if you were coming back nothing happened.  The creature knew its way around, and could use the magic to its own advantage; the players always knew which direction they were headed, but once they got involved in the tunnels they never knew quite where they were or how to get back.

Doctor Who faced a Minotaur-like beast called the Nimon once (I won’t swear to the spelling).  This time it was Tom Baker finding his way through the maze.  The thing that made that maze so difficult was that it constantly changed—he worked out that it was a huge set of switches in a communications and transmat system.  That’s a very difficult thing to do—but I can think of two good ways to make it work.  One would be to draw up maybe four or five distinct maps that were the same size and shape and had a few good fixed internal landmarks; that way at random intervals you could randomly change which map was in effect.  Of course, jumping from map to map could be tricky.  You might try making one map on paper that had the landmarks and a few fixed walls as reference points, and then getting four or five sheets of clear plastic overlay to put on top of the map, on which you would draw (or maybe if you’re really ambitious line with thin strips of black tape) the details of each position.  When the layout changed you would pop the new overlay on top, see where the characters are, and slide the old one out.

Of course, this idea doesn’t actually fit the pattern of the others, the pattern of moving the players from where they think they are to somewhere else.  But it probably makes them feel like it does, and sometimes that’s even better—especially if you’ve used tricks to move them around before.  They’ll leap to the conclusion that you’ve moved them, and begin trying to work out where they are.  You can get this effect with even simpler tricks.  Try making a matched pair of seemingly unique landmarks a short distance from each other in a confusing section of paths.  Players unaware that there are two (and especially those uncertain about their mapping skills) will come to the second and think they’re back at the first.

Something like that happened in one of my games, when the player was exploring the world we call Tristan’s Labyrinth.  (It was not called so when Tristan was exploring it.)  The labyrinth is endless; it is made of an L-shaped section designed to fit together such that all exposed sides are the same length (well, a single and double length) with doors that match up, so that you can build outward from one to as many as you need.  This means the same patterns of rooms appear, but not always in the same directions.  You can get the same effect with any of a number of random-connect dungeon floor plans; somewhere I’ve got a set of squares and rectangles published by TSR a generation ago, although I was never terribly happy with the way they fit together.  Just use the same piece against itself, turned around.  In the one game, the player found himself in a room with an interesting shape and several exits.  Deciding to use this as the base for his explorations, he traced out one of the exits some distance and back again, and then another.  The third tunnel took him off the map piece onto the adjacent piece, and connected to another tunnel which led to that same room on the next piece of map.  Carefully he followed it, reaching that identical room.  He looked at it.  He studied it carefully.  He compared it to what he had already drawn.

And then he changed his map.

If you use these tricks, there will be many times when your players will start erasing what they’ve charted, changing and fixing and trying to figure out where they are and how they got there.  But there is nothing like realizing you have gotten them so confused they are erasing the map when it was right.


Previous article:  Story-based Mapping.
Next article:  Doing Something.