-
Notifications
You must be signed in to change notification settings - Fork 0
ArtMOO System Design
This page describes the layers that make up the ArtMOO system to aid in understanding the structure of the code and how all the parts fit together.
There are only four kinds of data objects in ArtMOO:
- Objects
- Verbs
- Properties
- Tasks
Objects are the main building blocks of the world. They can be people, rooms, furniture, or the weather. They can also be more abstract, such as using an object to group verbs together into a sort of library that is useful for programming.
Objects are arranged into a hierachy. Objects usually have a parent object, though they can have no parent like the Root Object. Objects can also contain other objects, so room object can contain people objects and furniture objects. A person can carry other objects.
Properties are attached to objects. They have a name and contain some kind of data.
Verbs are attached to objects. They also have a name and contain the code that operates on other objects and generally make things happen.
Tasks are scheduled bits of code that are started inside a verb and will happen at some point in the future. You can set a timed task, something like 'execute this bit of code in 1 minute from now' or an event task that responds to some kind of extenal event like a person typing something or a network request completing.
At the lowest level, all the data for the MOO is stored in a SQLite database. There are four tables: object, verb, property, and task.
There are C++ classes that encapsulate each of these types: Object, Verb, Property, and Task.
The ObjectManager class is the low level access to the MOO system. It's job is to load objects/verbs/properties/tasks into memory from the database and write out changes that have been made to them.
Loading an object can be an expensive operation if there are many verbs and properties attached to the object so the ObjectManager keeps them in memory as long as they're being used. After a while, the objects are flushed from memory so it doesn't need to keep the whole database in memory at one time.
ArtMOO supports the concept of transactions by recording all the changes into a changeset.
When a command is entered into the MOO it might cause a large number of changes to the system, moving objects around, adding and changing properties, and if there is a problem in the code at any point we don't want the system to be half changed, leaving objects in an unknown state.
A changeset also includes the text that is output to the people connected to the MOO so they will only see the output if the command completes successfully.
The verb scriping language is Lua. The lua_* classes provide the libraries and functions that can be called by the code stored in verbs.
This layer controls access control to the objects. The previous layers allow complete control over the objects, such as being able to delete the Root Object, which is obviously not something we would want just anyone to be able to do.
We introduce roles at this point:
- Wizard - the highest level, complete control over the system#
- Programmer - can add and edit their own objects and verbs in the system
- User - can interact with the system but can't run any code directly, only existing verbs
The lua_* classes provide the functions to Lua to interact with the object/verb/property/task system and also enforce the above rules so a Programmer cannot delete objects that are owned by someone else, for instance.
Obviously you don't want to give Programmer roles to just everyone, and Wizard level should be reserved for those that you have complete trust in to not destroy your system.
Finally, we have the code that runs from verbs, tasks, and code that is entered directly by Programmers and Wizards.
This is the Lua code that is stored in the verb objects that operates in the sandbox and has access to the Lua libraries and functions provided by the lua_* classes.