Author Topic: Starting a mudlib. Which driver?  (Read 2687 times)

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Starting a mudlib. Which driver?
« on: January 19, 2013, 10:46:40 PM »
So I've been considering the possibility of starting a new mudlib for a while and recently decided that I had the time and energy to put into it. However, before I really get into anything code-wise it seems I still have some research and consideration in terms of drivers. Admittedly I'm not that well versed on them so I'm hoping that others will have input that can aid me in making a decision.

There is one basic goal I want to focus on. A message-based, composite-patterned, component-oriented architecture for the higher-level constructs. The will of course necessitate a much higher object count than most mudlibs as well as more overhead and processing to pass information around. It will probably also rely on more taboo LPC constructs like shadows or function binding.

So knowing that, I am left with the next step - picking the driver. The way I see it (and it is very limited I'll admit) the two big choices are FluffOS and DGD. Initially I was leaning towards Fluff because it is something I feel safe and comfortable with.  I'm used to it and I generally know what to expect. However, many people have been recommending DGD and I'm starting to take a liking to the idea. My biggest problem here is that DGD seems to offer features that are not found in other drivers. I usually like to go with the option that is more standards-compliant. Not surprisingly, as far as I can tell there really is no such thing for LPC. Not in any official capacity anyway. So perhaps the best metric is features rather than standards? Is that a fair assessment? If so are there any other drivers with interesting features I should consider?

The best features I see coming from DGD (if I understand them properly) are:
 
  • Light-weight objects - might be useful for composition?
  • Extension interface - can I do it with DLLs or do I need to edit the driver itself?
  • State dumps / persistence - not the most important thing to me but hey, I won't complain
  • Does not necessitate telnet communications - did I understand that one correctly?

 
« Last Edit: January 19, 2013, 10:49:40 PM by Sluggy »

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: Starting a mudlib. Which driver?
« Reply #1 on: January 20, 2013, 01:11:07 AM »
Don't forget LDMUD!

The one feature DGD doesn't fully support, which FluffOS and LDMUD do, is closures.  The reason it doesn't is a feature neither of the other drivers have, atomic functions. :)

In case you're not familiar with the ideas... closures are bits of code stuffed into places, which get evaluated at run-time, not compile time.  They're also called anonymous functions.  Atomic functions (really atomic code) are things which are run in a transaction, so that any failure results in a full rollback of everything they did.

Dworkin has added some limited support for anonymous functions to DGD, but he explains that they cause issues with persistence and atomic code.  Consider, you're upgrading an object (in a persistent game, you have to recompile and update existing objects -- no destruct/re-create cycle)... that object has several closures.  One of them fails to compile with the new version... how do you easily tell which one went where if the number of closures in the new code is different than in the old version?

Anyways... if either of those matters to you, pick the driver that has the one you care more about.

LDMUD is a very clean and well thought out driver, which is more like FluffOS but has a more centralized history and so has a lot less cruft than FluffOS has accumulated over the years.

I would say they're comparable in terms of performance.  The two biggest LPMUD's I can think of run on them... BatMUD runs on LDMUD, Discworld runs on FluffOS.  In theory, DGD outperforms them both, but I don't know in practice.

Oh, and none of them require you to use TELNET.  They all support opening raw sockets, in which case you can use whatever you want... and some mudlibs do the TELNET protocol in LPC anyways.

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Starting a mudlib. Which driver?
« Reply #2 on: January 20, 2013, 01:29:12 AM »
Ouch. I like mah closures. They are one of my favorite features. That and being able to do call outs for non-existing functions. I think I'd better do some more considering. Also, how does DGD stand up in terms of bidings and shadows?

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Starting a mudlib. Which driver?
« Reply #3 on: January 20, 2013, 03:02:14 PM »
I wouldn't use FluffOS for a new lib just because of the license issues.

As far as speed goes, I guess we need an LPC benchmark :)

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Starting a mudlib. Which driver?
« Reply #4 on: January 20, 2013, 03:12:29 PM »
Shadows can be implemented in dgd, if I recall correctly, but that implementation must happen in your lpc code.  I have not looked at this recently.  The main use I found for bindings, serialization, is already taken care of by dgd: you can ask the driver to make a state dump of everything at any time.  I'll come back to what can and can't be done in dgd in a moment.

    FluffOS provides, and this is a big one for me, a parser.  It is a complicated parser, and it is not well documented, but it is a good parser in my opinion.  You define verbs and what they do, and they work everywhere: typically, you define a set of verbs intended for quests, for example, such as push, pull, flip, etc, and rather than guess the syntax, players have some sort of starting point.  Get would be a verb, so would buy, and now you don't have to worry about add_action and how two builders might reimplement throw.  It will resolve objects for you, as well.

    Ldmud, in my opinion, is a bit better documented.  I have never booted up ldmud.  Are we sure batmud runs on top of ldmud?  I know Lost Souls does, and that's a really, really brilliant mud, and you should go look at it as it sounds like what you want to write, a bit.  They published the code for one of their guilds, I don't have a link atm, but google can probably find it--the guild is called traveler.

    I believe FluffOS provides telnet.  I believe ldmud provides telnet.  Dgd does not provide telnet, but the kernel lib does provide telnet, and if you're not going to code on top of the kernel lib, well, good luck with that.  I believe the kernel lib for dgd is public domain, but would have to check to be certain.

    Back to dgd for a moment, see this:
http://phantasmal.sourceforge.net/DGD/MudOS_vs_DGD.html
It's old, talking primarily about MudOS, but should give you some idea.

    You can, technically, do anything FluffOS can in dgd. Why.  Because the driver provides hooks that let you transform code before it is compiled.  Before the driver gets the code to the stage where it does *anything*, it gets passed to your precompilation hook.  This means, in essence, that you can change the lpc language from lpc itself.  If I liked, for example, objective-c's super-verbose syntax, for instance, I could compile it to lpc and then pass it on to the driver.  This isn't exactly simple.  To aid in this, dgd provides a parser--not a command parser, but the type of parser a compiler would use; commands are a special case, not a general case.  You provide a grammar and ask it to parse a string, and then interpret the ast as whatever you want it to be.

    I think, instead of shadows, use proxies.  Each object gets a special field called proxy and each function, before executing, calls proxy->should_funcname(some, arguments), which can do whatever, returning false if the function should return now.  Given that FluffOS has shadows, you don't need it; in dgd, however, you could implement the code transformation for that.

    Closures are a big one for me, too.  Dgd does not really have this, though it can be simulated with no small amount of work.

    A major question is how far from room are you going to go.  Dgd does not assume room-ness.  FluffOS does, to some extent--primarily the verb systems.  If your mud will always have well-defined rooms, you may get more out of FluffOS.  If your mud is going to be something like Godwars2, you may get more out of dgd.  FluffOS provides for easier building, at least in my opinion, though this does depend on what you implement on top of dgd to some extent.  Dgd provides for easier player modification, i.e. player houses, as you don't have to write any special saving code for anything.

    I'm sure I missed some points, but that's my comparison.  I'm obviously biased towards Dgd, but since I'm not really smart enough to use persistence (you have to throw out area resets and need an object manager), my projects got put on hold indefinitely--I need to be a better programmer first.  You can use dgd without persistence, but for me that's the big feature: my world never needs to reset, and if players get creative they could build entire cities which would exist, forever.

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: Starting a mudlib. Which driver?
« Reply #5 on: January 20, 2013, 05:29:40 PM »
Actually DGD has parse_string, which makes the parsers in FluffOS and LDMUD look like kids on the playground drawing with sticks. :)

parse_string() take some work to learn, but you provide a full grammar to it, and it parses strings based on that grammar (like flex or bison), rather than just a weak regexp system.

Here's a nice tutorial.

And yes, shadows SHOULD be done in the mudlib.. in fact, MOST things that FluffOS provides at the driver level end up being RE-DONE at the mudlib level once your mudlib gets very far away from what the original Nightmare/TMI muds used them for.  That's part of why I suggest LDMUD or DGD... not that Fluff is bad, but that it has a LOT of baggage which won't be useful to a new mudlib.

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Starting a mudlib. Which driver?
« Reply #6 on: January 20, 2013, 05:41:02 PM »
Dangit Camlorn! Every time I think I want to dismiss DGD you give me pause. That's ok though. I'd prefer it if everyone had a bias. It tends to bring out the best in their arguments. One thing that doc pointed out to me was the difference between the upgrade methods. I didn't realize that I could upgrade all live instances of an object. I have whole folders full of scripts dedicated to copying edited files of core systems, shutting down my test dev mud, rebooting it, and then logging back in and running various checks and it's one of the biggest bottlenecks in my work flow.

Another thing is that I like the idea of the driver having absolutely no assumptions about how my mudlib is going to work. I mean, I might perform objects composition by placing objects inside of other objects - then the traditional relationship between rooms/environment/inventory breaks down. I'm actually willing to write my own verb parser for that price. I've even have code that already does a lot of it.

So it seems to whole LDMUD angle stems from the idea that if I would use FluffOS then I might as well use LDMUD? Are the features more-or-less then same?


Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Starting a mudlib. Which driver?
« Reply #7 on: January 20, 2013, 06:19:48 PM »
Shadows being a mudlib-level feature makes me sigh wistfully.  Since shadows are an unparallelled horror of a feature, I eliminated all my usage of them in favor of a hooks mechanism, then went to look for the driver compile flag to remove them from the LDMud driver entirely, thereby discovering that there is no such flag -- shadows are compulsory.  Gah.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Starting a mudlib. Which driver?
« Reply #8 on: January 20, 2013, 07:39:53 PM »
Well, yes, parse_string was mentioned in my post.  There's one issue, though: commands are a special case.  FluffOS will get you a parser very, very quickly for commands, but the horror of writing a parser for a scripting language (there are good reasons to have a scripting language--consider simplification of delay, i.e. a delay(5) function, and using code transformations to make that work[1]) is really, really insanely hard.  Dgd will let you do that easily, but you have to work out resolution of objects yourself.  Dgd will, end up with a nicer parser, but getting there is a long road.

    I agree with Chaos.  Shadows are bad.  I don't even know how to use them.  I am happy that I don't know how to use them.  Dgd provides the functionality to implement body swapping, which is the only use case I've ever heard of.  Any mudlib anywhere can implement body swapping without them, by abstracting the idea of connection out of the idea of player, i.e. connections have associated bodies.  I have not heard of any programming language besides Lpc that offers similar functionality, save argueably objective-c--even in that case, though, the object to be shadowed has to consent to the shadowing and forward the messages to the shadow.  They call this proxying, if I recall correctly, but 99% of programmers will never use it so I never learned details.

    Go read through the objective-c runtime programming guide--I'm currently learning objective-c--for ideas about how you can do messages in any programming language; given the ability to transform code, it is possible in theory to write an objective-lpc.   This would probably slow things down by an order of magnitude if not hand optimized a whole lot.  If you use something besides the brackets for the message delimiters, it wouldn't even conflict with lpc (even with brackets, I don't think it does).  Apple moves their documents around so much that me providing a link is useless (no, really, links seem to invalidate a week after being posted, and they seem to be in the middle of a document restructuring thing).

    Any mudlib that takes connection handling into its own hands, and 95% of all mudlibs that don't, don't need snoop.  If you are already handling the input/output connections yourself, i.e. telnet on top of lpc, you just implement the functionality to show a wizard the output going to the player of interest.  It's not even that hard.  If you don't handle all of telnet, just put said code in a sefun and designate it to be the lowest level output handler. I.e., nothing should ever call anything except your special output function--calling things that ultimately use it is fine, but never go around it.  Then, the sefun just forwards you the output of the snooped player.

1: The normal method of delay is to have foo, foo2, foo3, etc. and then to call_out to the next one in the list.  Having a scripting language that compiles to lpc makes this transparent to your builders, and you could probably even work out how to get continuations working.  Actually performing the same transformations on lpc is...well, it's beyond this post, and now that I'm thinking about it, would probably involve flowcharts.  Or thought, lots and lots of thought.  What happens if I delay inside an if-block, for example--you'd have to have foo, foo2a and foo2b, and so on...

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Starting a mudlib. Which driver?
« Reply #9 on: January 22, 2013, 06:04:56 PM »
Well it appears that the general consensus is that DGD is the way to go if I'm going to write a new LPC-based mudlib. To that end I'll try to wrap up this topic with a link to the other thread so that anyone in the future can try to follow the line of reasoning. http://lpmuds.net/smf/index.php?topic=1415.msg7451;topicseen#msg7451

That being said, I might play the devil's advocate for Camlorn here. It sees that DGD is mostly just a sandboxed scripting engine for LPC so taking it just a step further entails using newer technologies to create basically the same thing but with a different language for the scripts. My curiosity has been piqued and I might go off the trail a bit here. I think I'll spend the next couple weeks investigating this angle just to see what I can come up with.

Sluggy puts on a dirty, well-worn, brown crush fedora.