Hey everyone.

I am not sure of any of you are familiar with the term MUD (which is Multi User Dungeon, a text-based game). If not feel free to go over to www.mudconnect.com to check it out.

Anyway, back to my post. What I am currently planning on doing is changing the way the world works from a room-based world to a location based world, which uses x, y and z coordinations.

The current room-based world would load up each room into a certain number (called vnum) and within each room there the posibility of having 6 exits, which takes the player to another room with the number specified on the exit. In practice this works great. Also a collection of rooms is called an area.

Now my idea is to remove the whole concept of an area existing out of rooms, so instead of a town being an area with a x amount of rooms it is a location, consisting of a x amount of spaces and y amount of spaces (x,y grid system). The z axis would be used for height as to how high a certain place on the location is or how high a player is above the ground (seeing that certain players can fly).

So basically I have taken up thought of this alot more recently and was wondering what would be the best way to go about.

What I thought of was using a file (let's call it locations) and within that file it has names (or numbers) of the locations which needs to be loaded. Each location which is loaded would be loaded from another file (x.loc). Now in each file for each location there would have to be a x, y and z to know the size of the grid, seeing that the inside of a house would be a location just as a whole town would be a location, and they both do differ in size. Also each location would have a main description, but each x, y and z position should have sub-description, seeing that the location could be "The town of Belgaard" and if you are in the northern parts of the town infornt of a store it would be "The bakery".

So basically I would need a structure to load the list of all the locations, and also a structure to load each of the locations specified in the locations file, as well as keep in mind that certain positions in a location may have obsticles etc.

Now what would be the best way to go about, also would the better way be to load a location into the players structure as the player enters a location, or load all the locations into memory. I know loading it into memory once of consumes more memory, but loading it everytime needed would cause alot of lag seeing that your average mud has about 10-25 players on at the same time.

Any advice on this would be appreciated.

Thank you.


P.S If this is very confusing but you do feel that you would like to help I will be more than happy to explain things in much more detail, as well as show the code of how it currently works, etc.

You're basically just describing the "area of rooms" concept with different terminology. Both can be easily written using multidimensional arrays, or sparse matrices. In the file you could have the x/y/x coordinates that relate to the array indexes followed by location information:

0 0 0 Information about the location
0 0 1 Information about the location
0 0 2 Information about the location
0 0 3 Nothing there

Then in your program you can have an array of structures that represent location information:

struct Location {
  /* Location information */
} loc[Z][X][Y];

And in your program, you can load the file into the array easily assuming you have a way to parse the location information into a Location object:

int inrange(int x, int low, int high)
{
  return x >= low && x < high;
}

void LoadFile(struct Location loc[Z][X][Y], FILE *fp)
{
  int x, y, z;

  while (fscanf("%d%d%d", &z, &x, &y) == 3) {
    assert(inrange(z, 0, Z) && inrange(x, 0, X) && inrange(y, 0, Y));
    LoadLocation(loc[z][x][y], fp);
  }

  if (!feof(fp)) {
    fprintf(stderr, "An error occurred while reading the file\n");
    cleanup(); /* Do any application-specific cleanup */
    exit(EXIT_FAILURE);
  }
}

Ok so far I've got it planned out as follow:

#define MAX_GRID_X  100  // 100 x 100 grid size per locations would
#define MAX_GRID_Y  100  // be more than enough, actually overdoing it

typedef struct location LOCATION;
struct location
{
  char *description;     // the description of the current sector

  int   sector_numb;     // unique number for the sector
  int   sector_type;     // the type of sector it is

  int   object;          // point to an object, 0 means no object
  int   mobile;          // point to a npc, 0 means no npc

  int   is_exit;         // point to another location, 0 means no exit
  int   z_coord;         // how high can something go on that point
};

Ok the above structure would hold the data for a single location from 0 to 99 on both the x and y axis. I don't need a z-axis here seeing that each location will be flat, z is used to see how high something can go up, used for when inside a building, etc.

Ok so now I would like to load all the locations into a structure. So I presume to do that I would create a new structre which loads every location into the above structure.

typedef struct world WORLD;
struct world
{
  LOCATION *grid[MAX_GRID_X - 1][MAX_GRID_Y - 1];
  char     *description;

  int       location_number;
};

extern struct world *world_list;

I think I should get the loading correct this way, but I am not sure if it is the right way to go.

P.S Forgot to mention that it is written in C and compiled under linux.

If you want to have multiple "worlds" then yea, that's probably the best way to go about it.

>>LOCATION *grid[MAX_GRID_X - 1][MAX_GRID_Y - 1];
Why are you taking 1 away from each of the sizes? It would be safer in the long run to just change MAX_GRID_X and MAX_GRID_Y to 99 rather than figure out what kind of integer arithmetic to do to avoid out of bounds accesses.

May I suggest linked list, or multi-branched trees, instead of matrices. I used to write some of these, a long long time ago -- like on Apple ][...


There are two ways you can create "worlds". One is as described, in matrices, and the other is links.

In the case of links, there is no real direction, or coordinate system. Points of interests are linked together by "parent-child" links, and can have many to many relationships.

In a matrix environment, you can only do, presuming three axis and that you can move in an angle, 26 directions. (Stacked cubes with 3/3/3 sides.)

The problem here is that you must define all of the matrix, and reserve memory. This becomes very memory and storage intensive as you start adding details to the various locations. With links, or pointers, you can preset the number of links to be say 256 possible exit points, yet not use the memory, only if the actual exit exists.

With linked lists, and still presenting it as an XYZ to the user, you can define the first, say 128 links to descriptions, so you would have a record for the ceiling - '>look ceiling' - 'the ceiling has cobwebs hanging, with 2" spiders staring back at you hungrily'... or if the link wasn't defined use a default answer like 'you see nothing interesting as you stare at the ceiling'.

So the links can lead to new rooms, or path, or can be containers for other information, like descriptions, or an object, or a rule that might trigger an other event.

A perfect example of this is a spreadsheet. Most people think spreadsheets store data in a two dimensional array, but in reality it is just a linked list.

You can also find some very fine example of the implementation of such systems by searching for BBS door games like Trade Wars, or Star Trek.

There was such a link list network where the link took the user to other BBS systems. I have been thinking of such network to write for the web, yet never got the time or chance to deploy it. In the old times, users had to disconnect, and the the "door" would dial the "new" world where the link pointed to.

Ahhh.. The good old times..

This article has been dead for over six months. Start a new discussion instead.