Annikka/evennia
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

Finish refactor of components

Browse source
This commit is contained in:
Griatch 2022-11-26 18:35:34 +01:00
parent c7ec3dfad3
commit bc092b8b2b
9 changed files with 213 additions and 369 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/source/Concepts/Zones.md
View file

@ -1,5 +1,6 @@
# Zones
Evennia recommends using [Tags](../Components/Tags.md) to create zones and other groupings.
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
@ -15,26 +16,21 @@ 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.
*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.
distinction.
All objects in Evennia can hold any number of [Tags](../Components/Tags.md). 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:
All objects in Evennia can hold any number of [Tags](../Components/Tags.md). 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:
`dig` command for this, most likely). You can also use the default `tag` command during building:
@tag forestobj = magicalforest : zone
tag forestobj = magicalforest : zone
Henceforth you can then easily retrieve only objects with a given tag:
@ -45,11 +41,7 @@ Henceforth you can then easily retrieve only objects with a given tag:
## 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](../Components/Typeclasses.md).
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](../Components/Typeclasses.md).
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
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.