mirror of
https://github.com/evennia/evennia.git
synced 2026-04-06 16:44:08 +02:00
Reorganize docs into flat folder layout
This commit is contained in:
parent
106558cec0
commit
892d8efb93
135 changed files with 34 additions and 1180 deletions
|
|
@ -1,55 +0,0 @@
|
|||
# Zones
|
||||
|
||||
|
||||
Say you create a room named *Meadow* in your nice big forest MUD. That's all nice and dandy, but
|
||||
what if you, in the other end of that forest want another *Meadow*? As a game creator, this can
|
||||
cause all sorts of confusion. For example, teleporting to *Meadow* will now give you a warning that
|
||||
there are two *Meadow* s and you have to select which one. It's no problem to do that, you just
|
||||
choose for example to go to `2-meadow`, but unless you examine them you couldn't be sure which of
|
||||
the two sat in the magical part of the forest and which didn't.
|
||||
|
||||
Another issue is if you want to group rooms in geographic regions. Let's say the "normal" part of
|
||||
the forest should have separate weather patterns from the magical part. Or maybe a magical
|
||||
disturbance echoes through all magical-forest rooms. It would then be convenient to be able to
|
||||
simply find all rooms that are "magical" so you could send messages to them.
|
||||
|
||||
## Zones in Evennia
|
||||
|
||||
*Zones* try to separate rooms by global location. In our example we would separate the forest into
|
||||
two parts - the magical and the non-magical part. Each have a *Meadow* and rooms belonging to each
|
||||
part should be easy to retrieve.
|
||||
|
||||
Many MUD codebases hardcode zones as part of the engine and database. Evennia does no such
|
||||
distinction due to the fact that rooms themselves are meant to be customized to any level anyway.
|
||||
Below is a suggestion for how to implement zones in Evennia.
|
||||
|
||||
All objects in Evennia can hold any number of [Tags](Tags). Tags are short labels that you attach to
|
||||
objects. They make it very easy to retrieve groups of objects. An object can have any number of
|
||||
different tags. So let's attach the relevant tag to our forest:
|
||||
|
||||
```python
|
||||
forestobj.tags.add("magicalforest", category="zone")
|
||||
```
|
||||
|
||||
You could add this manually, or automatically during creation somehow (you'd need to modify your
|
||||
@dig command for this, most likely). You can also use the default `@tag` command during building:
|
||||
|
||||
@tag forestobj = magicalforest : zone
|
||||
|
||||
Henceforth you can then easily retrieve only objects with a given tag:
|
||||
|
||||
```python
|
||||
import evennia
|
||||
rooms = evennia.search_tag("magicalforest", category="zone")
|
||||
```
|
||||
|
||||
## Using typeclasses and inheritance for zoning
|
||||
|
||||
The tagging or aliasing systems above don't instill any sort of functional difference between a
|
||||
magical forest room and a normal one - they are just arbitrary ways to mark objects for quick
|
||||
retrieval later. Any functional differences must be expressed using [Typeclasses](Typeclasses).
|
||||
|
||||
Of course, an alternative way to implement zones themselves is to have all rooms/objects in a zone
|
||||
inherit from a given typeclass parent - and then limit your searches to objects inheriting from that
|
||||
given parent. The effect would be similar but you'd need to expand the search functionality to
|
||||
properly search the inheritance tree.
|
||||
Loading…
Add table
Add a link
Reference in a new issue