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
different
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
come
in:
#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
top_of_world
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
but
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 ------- mailto:deejay@cu-online.com ----------------]
[--- Home page: http://www.cu-online.com/~deejay/ ---------------------]
[- 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: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST