Re: [CODE] Some input please for idea

From: Jack Wilson (
Date: 10/28/96

Chris A wrote:
>         There are two ways that I can see of doing it.
>         1. Setup the butler program so that it sends the player to the
> realm. (Ergo, there will be four seperate versions running).
>         2. Modify the stock-circle so that it is a constant
> through-out the rest, and uses tables to decide where that player is.
> Also using bit-vectors and the like to set up specific realm rules.
> (Although magic should be the same thorough-out.)

> Anyone ever try to do this?
> Anyone ever succesful?

Yep.  It's actually very easy to do this.  Just set up #define's for all
the "global" variables that are actually instance variables in the
worlds.  For example, try:

struct World {
   struct room_data *world;
   int top_of_world;

Then, in your main program, have a global variable called current_realm:

   struct World *current_realm;

Whenever input is received from a player, the game sets current_realm to
whatever World that player is currently in.  That's where your macros

   #define WORLD           current_realm->world
   #define TOP_OF_WORLD    current_realm->top_of_world

Replace every instance of world in the source with WORLD, and
with TOP_OF_WORLD.  Take the same approach with all the other "world
variables" in the game.  You then need some extra logic in the login
sequence to assign realms to players, and a loop to go through all
the World's and call the heartbeat functions such as pulse_violence.
The database initialization has to fire up multiple worlds (you can
again do a quick hack to make this work by using a World loop and
calling all the DB init routines from inside it).

Don't forget to give each World its own lib directory, as well.  Your
mileage may vary - you may want the worlds to share the wizhelp files
not the player help files, for example.

> Is this the right system to be doing this?

It worked great.  Took me about 4 hours to dream up and implement
this approach.

> Is there a better one?

I think a lot depends on the situation.  This approach is a very
easy way to retrofit existing muds with multiple seperate realms.
However, a startup mud that's trying to build a player base should
be trying to add features and/or areas, not creating new ways to
seperate the players from each other.

[----- Jack Wilson ------- ----------------]
[--- Home page: ---------------------]
[- PGP fingerprint:  99 C9 B7 A3 C4 72 DD 87  72 CF 67 50 63 48 D0 6D -]
| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |

This archive was generated by hypermail 2b30 : 12/18/00 PST