# It s a Small World, After All

 [ LiB ]

### It's a Small World, After All

The world is going to be simple. I'm going to use a room-based system (I can't think of a single MUD that doesn't use a similar system). The world will basically have just a vector of rooms. Each room is a separate entity in the game, a unit that encapsulates a number of things.

#### Give Me Some Room Here

Rooms in the game are relatively simple. They mainly act as a way of separating the various parts of the game from each other, so that everything doesn't happen in the same place. Because of this, rooms need to know who and what is in them, as well as where the exits are.

Each room has four possible adjacent room indexes, representing indexes of the rooms to the north, east, south, and west. So if a room's north variable is 10, that means room 10 is to the north. If an exit does not exist, the value is 0. Figure 7.2 shows an example of how the rooms are designed. This figure is a visual representation of the rooms. You can see that every room has four connectors, pointing toward another room, and that when its connector value is 0, there is no exit from the room in that direction. Furthermore, each room has strings representing the room name and a description of the room.

##### Figure 7.2. The room connectors point toward other rooms, and connector values control exits.

During the game, the map also uses two lists to track which players and enemies are in the room. This information isn't stored on disk, and I'll go into far more detail on these issues in Chapter 9, "Maps, Stores, and Training Rooms."

Items are also stored in lists, which means that theoretically each room can store an infinite number of items. This may seem like a good idea at first, but it doesn't work out in the real world. Most of the time, every room in the realm ends up getting packed full of worthless items that people can't be bothered to pick up and use. Therefore, I've put a limit on the number of items that can be in a room at any given moment, and that number is 32. Whenever someone drops something, and there are already 32 items on the floor, the oldest item just vanishes forever.

Each room also stores the amount of money lying on the floor.

Rooms have a type value. There are different kinds of rooms with special features. The first room type is a normal room and contains nothing special.

Another type of room is a storeroom . In these rooms, you can buy and sell items. Each storeroom has an extra associated value, which is the store number. Since the realm may contain several different stores, a storeroom needs to be able to tell which type of store it is. I'll cover stores in the next section.

The other kind of room is a training room, where you can train for the next level when you have gained enough experience.

Rooms also have information about what kinds of enemies they spawn. In MUDs, if your players go around killing everything, eventually they're going to run out of enemies, and your players won't appreciate that. Therefore, you need some way of creating more enemies. I've elected to take a simple approach and make the rooms determine what kind of enemies should respawn. To work, this requires two values: the ID of the enemy you want to spawn, and the maximum number of those enemies you want in the room at any given time.

The game works on a respawn cycle: Every 2 minutes, the game goes through every room and tries respawning enemies. If there are too many enemies in a room, additional enemies are not spawned. If you want, you can use this method to make sure that rooms have only one enemy, or up to 16 if nothing is killed in the room for 32 minutes.

That's all the data that is stored in each room.

 [ LiB ]

MUD Game Programming (Premier Press Game Development)
ISBN: 1592000908
EAN: 2147483647
Year: 2003
Pages: 147
Authors: Ron Penton