class Flower ;
end
# Flower that doesn't eat flies.
class Tulip < Flower
end
# inherit flower
class VenusFlytrap < Flower
def eat_flies
end
end
@ancestors here
$the_pit [*-mvc]
$place [*fmvcG] (MI)
$location [*fmvc] (MI)
$physical [*-mvc] (MI)
$described [*-mvc] (MI)
$has_name [*fmvc]
$foundation [*fmvc] (MI)
$root [*-mvc]
$has_commands [*fmvc]
$foundation [*fmvc] (MI)
$root [*-mvc]
$event_handler [*-mvc]
$foundation [*fmvc] (MI)
$root [*-mvc]
$command_cache [*-mvc]
$has_commands [*fmvc]
$foundation [*fmvc] (MI)
$root [*-mvc]
$realm_settings [*-mvc]
$foundation [*fmvc] (MI)
$root [*-mvc]
For my requirements, I need Objects in my MUD to be fairly realistic, and highly mutable. Most of the gameplay will come from using/manipulating objects in interesting ways.
I also want to place a limited set of build tools in the hands of the players, so that they can (within reason) create new objects on the fly. This includes really fringe cases, like a stone statue that can be turned into a golem which can then attack, and be damaged like a mob, or a chair that can be animated an ridden like a horse (but not turn into a horse, just ridden like one). The goal is to have a MUD that's dynamic enough to create worlds such as Harry Potter, Full Metal Alchemist, Looney Toons, Fantasia, etc., with high levels of fidelity, not just skills that "look" like they're doing what they should, but actually have visible effects.
This means that somehow, every object needs to know how to react to every effect, if at all.
Evennia seems to assume a standard OO model (which makes sense, since we're dealing with python here). OO models have proven themselves useful in many MUDs, but I don't think they'd work here. Take for example, a rose. In a standard object model, the rose could be an instance of flower, which is a subclass of plant, inheriting from the base object. The properties of flower allow for the user's creation of roses, petunias, daffodils, or whatever kind of flower they want, as long as the flowers conform to the properties of flower that I have designed.
What if they wanted a venus flytrap, however? They could make a flower, call it a venus flytrap, and describe it prettily, but it wouldn't catch flies. There would be no reasonable way to make it catch flies, either. I wouldn't want to add a damage field to flower when it's going to be null 99% of the time.
Multiclassing could solve this, but this requires that I allow for creation and storage of dynamically generated python classes, and that seems messy and prone to bugs.
There are other options I considered. One was having components. Objects by themselves do almost nothing, but contain a list of components that handle the data they use and what they're capable of doing. Thus, a venus flytrap could have all the components a plant normally has, plus an attack component, and a targetting component to attack flies.
The other is giving the user some control of Evennia's scripting system. This should allow for almost anything to be done, but comes at the cost of needing to create some kind of user friendly python interface for people who don't know python (and a security system to stop people from crashing the game with arbitrary python code).
I was strongly considering developing an entity system (here), which behaves similarily to a component system, but is highly memory efficient (The component system described above would have an instance of a script for each object. This is probably ok, but doesn't scale well for large numbers of objects, and causes problems if a frequently used script (say, AI) is particularly intensive. In an entity system, there is only one instance of each script, which processes a list of objects that register with it. This would be excellent in a system with few scripts and lots of objects). The problem is that Evennia's object system is very tightly integrated with everything, so a redesign would have me changing just about everything about the codebase. I think I would almost be better off starting from scratch (something I don't want to do). Doing this, I think, is chasing performance gains where they might not be required.
Which of the ideas I listed do you think best fits my requirements? Are there any paradigms I'm missing that would allow for highly mutable objects? Am I barking up the wrong tree entirely? (too bad! Doing it anyways! :redface: :biggrin:)