08 Jan, 2010, Brinson wrote in the 1st comment:
Votes: 0
The MOO server code, and the LambdaCore Database, comprise perhaps the most versatile MUD base in existance. It is not often that you can peruse the listings and find everything from Medieval, to Space, to Harry Potter, to Modern Day muds all running the same set of base code.

I'm recounting right now, however, its flaws, for one reason. I want to fix them. Anyone who wants to help me is perfectly welcome. I'm going to provide a moderate overview of the code, and then go into how I intend to change it. Hopefully within the next couple of months I'll be posting a release here, of my own MOO database with the following things implemented.

MOO stands for Mud Object Oriented, and Object Oriented is a bit different in moo, because the objects are mud objects. All code that comprises a MOO, aside from its most basic server code, is written in the MOO language, which is a very simplistic variation of C. All MOO code is stored on objects inside the game. Your login process, your Character creation process, your rooms, your command, everything, all stored on objects, which are assigned numbers.

A simple command would be something such as a slap social, and it would be added with the command @verb #6:slap any none none. #6 is generic player, and all players are children of this character, and thus share its commands. I could just as easily have put the command on a specific player.

I would then program the verb using the @program command with something like:
player:tell("You slap ", iobj.name, " REALLY hard.");
iobj:tell( player.name, " slaps you REALLY hard.");


"Name" is a property on the character, who is also an object. Properties can be defined as numbers, strings, or lists.

And you've added a commPages: << prev 1 next >>
Pages: << prev 1 next >>
and to your game.

Number One

The first problem with MOO is the lack of a virtual numbering system. Each objects exists only once in the mud. This changes gameplay. My last MOO had stores create items for you spontaneously when you purchased them, as children of the one I coded. It worked fine, until I realized my database was becomign massive, and it was becoming very disorganized.

I've implimented a rudimentary virtual numbering system in the MOO I'm currently working on. Basically I've recoded #0:contents to return two properties instead of one, listing both contents and "vcontents". I then recoded every command that manipulates and lists objects to add to the vcontents list rather than physically changing the item's location property. It works, but part of the verb code no longer works, ie, the part which lets you @verb item:use this none none, which allows the verb only to work if the item is accessible. This code is hard coded into the server, in C. I will likely toy with it eventually, but my C skills are rudimentary at best.

I additionally coded a match verb on #0 which checks for the iobj/dobj string and then returns the obj number, so instead of using this, you'd use any, and have the first line of the code be such as:

this = player:match(iobbjstr);

Which would allow the code to execute as normal, but it seems unnecesary if I can properly modify the server code.

Number two

Organizational Structure in MOO is terrible. Imagine having a thousand characters in one .db file which is loaded into RAM the moment you boot the MOO. The most popular MOO, lambdaMOO, uses over 300mbs of ram to run. Now, my piddly moo uses less than 4, but if the database grows unchecked, it can be quite dangerous.

I'm planning to implement player purging systems to purge inactive players automatically to keep the organization down.

Number Three

Nothing in MOO is stored in files. I'd like to move parts of MOO into files. Ideally, I'd move players into files, but this seems unlikely to work, due to ownership issues. If a programmer is suddenly loaded out of the MOO I am unsure what would happen to all of their objects.

Instead, I am toying with the idea of using an account system. Each player would stay in the database, but their characters, ie their names. descriptions, back stories, ect, would be stored in a file, which would be read when they chose that character. As these files could be massive, I think this would work well to conserve ram.

Number Four

Equipment System. I am going to add an equipment system with generic items, and a store system so items can be purchased and virtually added to your inventory. In addition, items will affect your long description in the room. Held items, and jewlery, for instance, will be visible when you enter the room.

Number Five

I'm going to implement the barebones of a combat system. The code which controls delays and basic punch attacks. Weapon code will be left to individual mud owners. Though a generic weapon item with the wield, sheath, and perhaps other basic commands will be added.

If anyone has any experience with moo I'd appreciate your comments. If not…well, I'd still appreciate them.
08 Jan, 2010, Sandi wrote in the 2nd comment:
Votes: 0
I guess my first question is, How familiar are you with MUSHes? They've addressed a few of the memory issues, notably with player purging and object recycling. They also provide an option for 'disk-based' operation, which cycles out unused objects from RAM.

I'm a fan of discreet object numbers. ROM's 'string' command seems laughable when you're used to addressing an object by number rather than name. I'm not totally clear on what your virtual numbering achieves, but I wonder if MOO has a set of parent() and child() functions?

While I'm not saying things couldn't be better, to some extent you have to accept the fact that 'random' object creation means the db is going to be a mess to the eye of a human, and work on tools to manipulate it rather than structures to organise it. On the other hand, the human-readable flatfiles of a DIKU are a joy to work with compared to the flatfiles of a MUSH. (And truthfully, I don't know of anyone else but myself that even reads MUSH flatfiles, let alone touches them.)
08 Jan, 2010, Cratylus wrote in the 3rd comment:
Votes: 0
Brinson said:
The MOO server code, and the LambdaCore Database, comprise perhaps the most versatile MUD base in existance


I'd like to know why it's more versatile than anything else that lets you
emote, roleplay, and instance arbitrary items.

Brinson said:
If not…well, I'd still appreciate them.


You asked for it!

It sounds to me like you're turning a MOO into an LP mud. I think that's fine if the
point is to enjoy what you're doing. If the point is actually the finished product, then
you might want to look at solutions, from MUSH to LP, that already do some or
all of what you're looking for, and start from there.

-Crat
http://lpmuds.net
08 Jan, 2010, Sandi wrote in the 4th comment:
Votes: 0
Cratylus said:
Brinson said:
The MOO server code, and the LambdaCore Database, comprise perhaps the most versatile MUD base in existance


I'd like to know why it's more versatile than anything else that lets you
emote, roleplay, and instance arbitrary items.

Because he knows the MooPL. You know LPC. What's most versatile for him is not what's most versatile for you. Since I know mushcode, I might argue for MUX2, but I've been working on ROM for the last ten years because there's something to be said for "purpose specific" when designing a game. Still, the "OLC" of a MOO or MUSH is very tempting.
08 Jan, 2010, Cratylus wrote in the 5th comment:
Votes: 0
Sandi said:
Cratylus said:
Brinson said:
The MOO server code, and the LambdaCore Database, comprise perhaps the most versatile MUD base in existance


I'd like to know why it's more versatile than anything else that lets you
emote, roleplay, and instance arbitrary items.

Because he knows the MooPL. You know LPC. What's most versatile for him is not what's most versatile for you.


Well he didn't say "for him". In fact, the context was about all these different kinds of
muds, so it's pretty clear the versatility he was talking about wasn't "for him", unless,
of course, he was running those muds.

My point in asking the question wasn't sparking a snark from Sandi, but rather to
set up my subsequent comment. "Are you sure you're using the right tool for the
job?" is germane when the OP is talking about a major rework of code to do stuff
that other code does out of the box.

If the rework is the fun part and the point, awesome. Otherwise, it's quite fair to
suggest that the OP has odd presumptions of versatility, and time can be saved
with other, just as versatile solutions.

-Crat
http://lpmuds.net
08 Jan, 2010, Tyche wrote in the 6th comment:
Votes: 0
Most if not all of these problems have been solved by muds that were inspired by MOO, in particular COOL and Cold. I'm sure their solutions could be backfitted into MOO (not a trivial task by all means)

Quote
Number One
The first problem with MOO is the lack of a virtual numbering system.


The problem that MOO and Mush have is in forcing a building/programming user to use them. ColdC implemented symbolic object names in addition to DBREFs. For example, one can refer to object #0 as $system and object #1 as $root. ColdCore implements different schemes depending on the objects. In addition there exists several functions based on regex (@find/@grep) to query for objects based on name and description fields.

In ColdCore for example, A flag has been added to objects called 'fertile which delineates which objects are used as prototypical objects and can be spawned for game use, the names of spawned objects generated by the parent object. Thus a $connection object spawns $connection_20101932811662 where the suffix is the timestamp when the user connected. $user spawns objects named $user_bob and $user_bubba or whatever the user wants to use as their account name.

Frankly having uniquely generated OIDs/DBREFS is essential in order to solve the next problem.

Quote
Number two
Organizational Structure in MOO is terrible. Imagine having a thousand characters in one .db file which is loaded into RAM the moment you boot the MOO. The most popular MOO, lambdaMOO, uses over 300mbs of ram to run. Now, my piddly moo uses less than 4, but if the database grows unchecked, it can be quite dangerous.

I'm planning to implement player purging systems to purge inactive players automatically to keep the organization down.


ColdC implements a simple LRU object cacheing scheme and stores objects in your typical hash database. That is it can use any of bdbm, gdbm, ndbm, or sdbm. Muds like The Eternal City have over 2 billion objects, obviously only those that fit into the configurable cache size could be in memory at any given time. Aside: I used Cold object cache as a model for TeensyMud.

DBRefs are used as the key datum and the rest of the object is pickled/unpickled into/from the value datum. MOO (and Mush) still has many object flags and properties held over from TinyMud design, but all object properties are part of COOL and Cold objects and none exist outside of "soft" code. Cool and ColdC support two way compilation and decompilation. What that means is in addition to storing all objects in a database one can produce a complete textdump of the entire core that looks and can be edited just like any typical program source source code.

There is an object called $reaper (in ColdCore) which does things like run routine every day to cycle through $user.children() that deletes accounts that haven't been used for some time or some other condition. ColdHell has number of objects that perform actions very similar to DikuMud update routines (deleting corpses, resets, etc.)

Quote
Number Three

Nothing in MOO is stored in files. I'd like to move parts of MOO into files. Ideally, I'd move players into files, but this seems unlikely to work, due to ownership issues. If a programmer is suddenly loaded out of the MOO I am unsure what would happen to all of their objects.


Both Cool and ColdC have file read and writing capability to a protected directory, but frankly I've never seen any core that makes any extensive use of it, probably because the server already acts as a full fledged database itself. So if you solved "number Two" this may be moot.

In ColdCore, there are properties on $root and all objects descended from $root (which is everything in the game) called owner and manager. Owner being the person who creates and "owns" the object, and manager being the id of the object that manages it in game. The notion being that one can easily find and delete, (or decompile to a file) all the objects owned by a certain user. Also those objects managed by another object other than the user are those that are essential to running the game. I think one of the differences between MOO and COOL/Cold is that security is hardcoded in MOO and security systems are created in the softcode in Cool and Cold.

Quote
Number Four
Number Five


These really aren't failings of MOO, for they'd be failings of LP, Mush, Cold too. They are really things that you have to build yourself that are dependent on the game you wish to construct. They might be considered failings of particular Core or MudLib. For instance you'll find a decent equipment combat system in ColdHell core, but not in ColdCore.
09 Jan, 2010, Sandi wrote in the 7th comment:
Votes: 0
Cool stuff, Tyche. You've been beating the drum for Cold for a long time. Pity it doesn't get more attention.
0.0/7