Up to Main Index                             Up to Journal for March, 2016

                     JOURNAL FOR MONDAY 28TH MARCH, 2016
______________________________________________________________________________

SUBJECT: What are zone links and why do we need them?
   DATE: Mon 28 Mar 22:16:43 BST 2016

A few people have asked me to explain what zone links are and why we need
them. As I have been busy pondering on the best way to implement zone links I
thought now would be a good time to write about them.

Zone links are essentially exits that lead between different zones. Assume we
have two zones: Zone A and Zone B. To keep things simple they will only have
two locations each:


                              Link Between Zones
                                      |
           |------- ZoneA -------|    |    |------- ZoneB -------|
            _______       _______     |     _______       _______
           |       |     |       |    V    |       |     |       |
           | Room1 |<--->| Room2 |<- - - ->| Room2 |<--->| Room1 |
           |_______|     |_______|         |_______|     |_______|


For each zone we need a zone file:


  // file: zonea.wrj
    Ref: ZONEA
   Zone: Zone A
  %%
    Ref: ROOM1
  Start:
   Name: Room 1
  Exits: E→ROOM2

  This is zone A, room one!
  %%
    Ref: ROOM2
   Name: Room 2
  Exits: W→ROOM1

  This is zone A, room two!
  %%


  // file: zoneb.wrj
    Ref: ZONEB
   Zone: Zone B
  %%
    Ref: ROOM1
   Name: Room 1
  Exits: W→ROOM2

  This is zone B, room one!
  %%
    Ref: ROOM2
   Name: Room 2
  Exits: E→ROOM1

  This is zone B, room two!
  %%


Riveting stuff eh? :) WolfMUD was originally designed to make it very simple
for people to collaborate and share zones with each other - this version of
WolfMUD makes it even easier. If you look closely at the above two files you
will notice they both use the references ROOM1 and ROOM2. The references - the
Ref: fields - are only local to the zone file they are defined in. It is only
the Ref: in each zone record (ZONEA & ZONEB) that have to be unique.

The down side of this is we cannot refer from one location to another between
zones - the refs are local to the file they are in.

Hence we have zone links. A zone link is simply an exit to/from a location in
one zone to another in a different zone.

The question then becomes: How do we represent zone links?

To make zone links easily identifiable I've added a new ZoneLinks field
instead of expanding the Exits field. This means you can easily search for
zone links in your editor or with commands like grep. The format is similar to
the Exits field though:


  ZoneLinks: E→ZONEB:ROOM2


This says there is an exit east from the current location that leads to ROOM2
in zone ZONEB. Pretty logical. As with exits the separator between the
direction and destination '→' can be any non-letter character as can the
separator between the zone ref and location ref ':'.

Adding this to our example zone files from above we now have:


  // file: zonea.wrj
    Ref: ZONEA
   Zone: Zone A
  %%
        Ref: ROOM1
      Start:
       Name: Room 1
      Exits: E→ROOM2

  This is zone A, room one!
  %%
        Ref: ROOM2
       Name: Room 2
      Exits: W→ROOM1
  ZoneLinks: E→ZONEB:ROOM2

  This is zone A, room two!
  %%


  // file: zoneb.wrj
    Ref: ZONEB
   Zone: Zone B
  %%
        Ref: ROOM1
       Name: Room 1
      Exits: W→ROOM2

  This is zone B, room one!
  %%
        Ref: ROOM2
       Name: Room 2
      Exits: E→ROOM1
  ZoneLinks: W→ZONEA:ROOM2

  This is zone B, room two!
  %%


If you are authoring a zone and don't know where it will be linking to you can
enter a blank field:


  ZoneLinks:


This indicates to you and other users of your zone that this location is a good
link point to another zone. You can even be more specific:


  ZoneLinks: S


This indicates that when linking this zone to another the linked exit should
preferably go south.

A question zone links then bring up is: Should zone prefixed references be
generalised and usable anywhere? Part of me says yes and part says no.

Yes, because you could create a storehouse of general items and then put
references to the items wherever you need them. For example if there are
twenty armed guards with swords you can define a stock sword and just
reference it twenty times, once for each guard - or just define a general
guard, complete with equipment and reference that twenty times!

No, because... well you could reference anything from anywhere! This would
make zone loading and initialisation more complicated and would require more
state information to be kept until everything is loaded. It would also add
complexity to a future goal of making zones reloadable on the fly.

--
Diddymus


  Up to Main Index                             Up to Journal for March, 2016