Progress on Wayfarer is much slower than it was before switching to Evennia. A lot of this is due to my unfamiliarity with Evennia; I'm spending far more time researching what the 'Evennian' way of doing X is versus just implementing it and moving on. I'm still hopeful that this switch will be a net time savings due to not having to re-implement a lot of Evennia's existing features, but it'll be slow going for a while more.
As a note to future users of the Wilderness contrib, I'm finding that some of the design decisions don't make sense in the original contrib. For instance, map generators are responsible for dictating whether or not a given coordinate set is valid, but the code for updating coordinates via movement is a standalone function outside of the map generator class. I've moved it inside to allow map generators to dictate their own coordinate-change behaviors (wrapping worlds, etc).
Current work list:
- Design method of generating and saving playfields out-of-band to avoid loading the server during exploration.
- Design method of saving and loading alterations to playfields (sector/biome evolution, clear-cutting, etc).
- Re-implement work from custom codebase re: procedural generation.
Showing posts with label wilderness contrib. Show all posts
Showing posts with label wilderness contrib. Show all posts
Thursday, May 16, 2019
Saturday, May 4, 2019
Ways to represent coordinate-based worlds in Evennia
I've been talking with Griatch (Evennia's principal developer) in the MUD Coders Guild's public Slack server, and he noted several ways of getting Evennia to work with a coordinate system. I'll summarize the information I gleaned here; any errors, omissions, or bad visualizations should be assumed to be my own.
1) It's possible to use a global script (i.e. an OOC object in Evennia lingo) to hold a 2D array of room objects directly. Evennia's Attributes system supports this kind of storage natively and efficiently, although cacheing the array is also advisable.
2) Alternatively, tags can be used on objects to represent their axial coordinates (example: tag="xcoord 3", tag="ycoord 4"). Tags can be shared between objects, meaning that to tag anything within a 10x10 coordinate grid you'd only need to create 20 tags in the database (10 for X, 10 for Y). Less optimally, attributes can be used to store coordinate pairs, but these cannot be shared between objects and would need one attribute per object (10x10 = 100 attributes just for the rooms). Tagging is the approach described in Evennia's Coordinates writeup.
3) Finally, for very large grids, it's advised to use the wilderness contrib which uses one room per player. As the player moves around, the room moves with them, a bit like a giant hamster ball rolling across the world. The wilderness keeps track of the things inside it, and when you move it checks to see if anything occupies the same space as you; if it finds things, it adds them to your room (or merges your room with theirs if they are a player). This keeps room memory usage light and allows for large spaces.
I was originally considering very large playing fields (500x500, or even 1000x1000), but after looking back at this post on Wayfar 1444's chargen system, it's clear that I was vastly over-estimating the size of the original planets. Restricting the playing fields to 100x100 may be advisable to ensure that players run into each other more frequently. This will also naturally lessen the amount of work the procedural generators have to do.
1) It's possible to use a global script (i.e. an OOC object in Evennia lingo) to hold a 2D array of room objects directly. Evennia's Attributes system supports this kind of storage natively and efficiently, although cacheing the array is also advisable.
2) Alternatively, tags can be used on objects to represent their axial coordinates (example: tag="xcoord 3", tag="ycoord 4"). Tags can be shared between objects, meaning that to tag anything within a 10x10 coordinate grid you'd only need to create 20 tags in the database (10 for X, 10 for Y). Less optimally, attributes can be used to store coordinate pairs, but these cannot be shared between objects and would need one attribute per object (10x10 = 100 attributes just for the rooms). Tagging is the approach described in Evennia's Coordinates writeup.
3) Finally, for very large grids, it's advised to use the wilderness contrib which uses one room per player. As the player moves around, the room moves with them, a bit like a giant hamster ball rolling across the world. The wilderness keeps track of the things inside it, and when you move it checks to see if anything occupies the same space as you; if it finds things, it adds them to your room (or merges your room with theirs if they are a player). This keeps room memory usage light and allows for large spaces.
I was originally considering very large playing fields (500x500, or even 1000x1000), but after looking back at this post on Wayfar 1444's chargen system, it's clear that I was vastly over-estimating the size of the original planets. Restricting the playing fields to 100x100 may be advisable to ensure that players run into each other more frequently. This will also naturally lessen the amount of work the procedural generators have to do.
Subscribe to:
Posts (Atom)