Sub-Rooms
Anyone who's played a MUD or text-based adventure game is familiar with the concept of a "room." Each location in the game that you can visit is classically represented by a room. A room includes things like a title, a description, the list of objects in the room, a list of exits leading to other rooms, and so on. Travelling about one of these games is accomplised by using the exits (often using directional commands like "north" or "se") and moving from room to room.
Of course, as many people also know, this is very limiting and unrealistic. You cannot easily see what is happening in an adjacent room. You can't move around in a large room. You're pretty much in the room, or not in the room, and that's it. Some games allow you to look in/at/through exits to see what is the adjoining room. Some actions, such as yelling, might cause your voice to propogate through to the adjoining rooms. All in all, however, the situation isn't very nice.
Some games have experimented with coordinate based systems. There are two main variations on this; one that continues to use rooms, and one that does not. The room based solutions seek to solve one problem: moving around in large rooms. In these systems, you still move from room to room by exits, and each room is still its own separate container. You are able to position yourself in the room, which mostly becomes useful for combat. Some of the more advanced implementations allow for more intricate behaviour based on coordinate location, such as varying object descriptions based on which part of the room you're in or limiting interaction with objects if you are too far away.
The second coordinate method is much more free form. Rooms are done away with, and instead "areas" are defined using geometric equations (most often a point and radius). When you are within range of an object its area description is added to what you "see." The description will often change as you close in, getting more and more detail. For example, a forest might add "The trees at the edge of the forest are small compared to the towering giants seen deeper in the dark wood." to the description printed with the "look" command when you are just barely within its radius. A waterfall might add "The faint sound of rushing water from a distant waterfall can just be made out." to the description. And so on.
The second system has some very interesting possibilities. The world can be described in a way which in a much looser format while still providing very indepth descriptions. Especially when more complex geometry is used to describe the world and effects like blocking visuals, directional descriptions, and so on are put into place. The system can easily be combined with a room-based system when very precise and controlled movement is needed, such as in a dungeon or other indoor area. The main problem comes from the incredibly amount of detail and work that needs to be put into each area to make it work properly. The descriptions need to match various distances, direction ("You hear the waterfall to the east" vs "You hear the waterfall to the southwest"), blocked visuals, etc. You are, in essence, creating a 3D engine, but instead of just describing the object as a model, you need to write out full descriptions for all the different ways the object could be "rendered." It's a lot of work.
Additionally, coordinate based systems suffer from both a lack of fine grained control and complexity. You still need a room based solution to lay out indoor areas or dungeons, as otherwise you would need a complex 3D representation of the indoor area and an advanced text description generator. ("A passage opens to the north, leading along a torchlit hallway. The faintt outline of a door can be seen at the end of the dimly lit passage." How do you get a good, indepth, varied description like that out of even a detailed 3D representation of a room?) Movement either becomes very inprecise (the "north" command moves some fixed units towards north) or requires very complex commands to specify the direction and distance, or raw coordinates, to move to. The player is then also required to know their coordinates and understand what those mean in relation to their destination.
The solution I'm in favor of, which I'm not aware of having been used yet, is to continue using rooms, but break them into smaller units which are heavily interconnected. I'm dubbing them sub-rooms.
The idea is very simple. Each sub-room works exactly like a traditional room. You are either in it, or not. The room contains a title, a description, a list of objects, and a list of exits. The big difference is in the exits. The exits not only describe ways to leave the current room and enter the next, but also a wide variety of flags which specify how events in one room propogate to the next and what can by default be seen or interacted with in adjoining rooms.
My favorite example is a large room broken into several pieces. There is the main floor of the room, a stairway running along the north wall with a balcony at the top. There is a door on the balcony and a door under the balcony, both of which lead into hallways. Players in any part of the room can hear things which occur in another part of the room. However, players on the balcony cannot see anything under the balcony, nor can players under the balcony see anything on the balcony.
Movement in this situation continues to work as it classically does. "go under balcony", "climb stairs", "out", etc. Player interactions, however, can be much more complex. In a classic MUD, either the entire room is a single area, or the balcony is a separate room requiring special commands to see down to the floor and listen to anything occuring there. In this model, a player could run up the stairs, comment to his friends, and then go through the doorway. The sounds of battle occuring in the hallway would drift to the ears of people in the room. Players could leap off the balcony onto the floor below. A player could crawl onto the balcony above and listen to a private conversation going on in the room below. And so on.
This system would actually be very easy to implement. As mentioned above, many of the changes are on the exits themselves. You'd just add a number of properties to each exit specifying whether to display people in the adjoining sub-room, whether speech should carry through, and so on. The rest of the changes would be to carry through the actions. If you say something, check each exit in your sub-room and, if they specify for speech to carry through, print out what is said to the connected room. The room description code (for "look" and similar) would be updated to display characters in adjoining rooms if the exit specifies it to be so. ("You are on the balcony. Jay is also here. You see Rob on the floor below.") Finally, the object lookup code (used to find the player object when you type in a command with "jay" for example) would then be updated to search adjoining rooms as well.
That fairly well sums up the sub-room idea. Combining it with features that exist, but are rare, in classical MUDs, such as basing an exit's status on the status of an object in the room, would allow for very indepth areas. Imagine being able to jump on a table in a fight. Or being able to kick the table out from under someone in a fight. Pretty nifty stuff.