Author Topic: Starting a new mudlib  (Read 4921 times)

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: Starting a new mudlib
« Reply #15 on: January 21, 2013, 06:01:51 AM »
The key thing that you're forgetting here, is that the features the LPMUD community values most are not features of the langauge at all.

Namely, the ability to write and modify anything at run-time.

That has NOTHING to do with the language choice.  It has everything to do with the LPC driver being an interpreter, rather than a compiler.

If you want to roll your own system that can work the same way, you have to stop trying to find languages that let you muck with stuff after compilation, and write your OWN language interpreter.  You can implement an existing language, if you like... you can probably even reuse some of the code from an existing langauge implementation.  But you won't do it with a compiler, nor will you do it by sandboxing any kind of scripting.

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1020
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: Starting a new mudlib
« Reply #16 on: January 21, 2013, 09:18:35 AM »
and of course the awesomeness that is opening up a bunch of mudlibs and hunting down their driver interfaces and then comparing them.

I guess you're probably being sarcastic here, but believe it or not, this was actually a super fun thing for me. I felt like Indiana Jones, obtainer of rare antiquities, while hunting the libs and analyzing them...and then like Viktor Frankenstein, getting them to live again.

I agree with the vague semi-consensus here that for a brand new LP lib, DGD is a swell choice and probably the best choice. I have a substantial affection for Fluff and frankly I'd feel lost without some of its goodies...but for a shiny clean no-legacy lib, a shiny clean no-legacy driver seems proper.

Whichever driver you choose, and whatever the license, it doesn't hurt to send the maintainer a note, with a polite request for their blessing to distribute it. A "blessing" is how I term it, because "permission" may not always apply, and for all practical purposes we're all on the honor system here in terms on compliance...respectful recognition is the coin of the realm.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Starting a new mudlib
« Reply #17 on: January 21, 2013, 01:12:43 PM »
I understand the dynamic updating point.  My point is that it probably doesn't matter as much as all that.  I've seen a whole lot of lpmuds that have to reboot when a core system is changed.  If someone took full advantage of it--and I'm sure someone, somewhere, does--then yes, OK, cool, but a majority of mudlibs don't let you change, for example, the player inheritables without rebooting or making everyone relog.  Can this be done? Sure. But I have yet to see it in a running mud.  On account of that and that you should be running a testport anyway, dynamic updating is cool but not particularly necessary in my opinion.

    And then, you update something, think you're fine, only to find out 20 minutes later that, in fact, you were not.

    I haven't touched lpc in a while, maybe I've got some details of the above wrong, but in all honesty--something with fast compilation times is good enough for me.  Lpc is cool, and can do a lot, but you have to already know it--my feeling is that, for anything more complicated than building, you kind of have to have been in from the beginning--there's all sorts of undocumented corner cases and functions and stuff, and you have to know them all to write a mudlib.

    At least Moo, which is lesser than lpc in a lot of ways, has a complete manual.  But I'm going to be good and stop now--lpc as a technology is good enough, it just isn't the best for new mudlib projects in my opinion (excepting dgd, because full game persistence like that is really, really hard to do at all, let alone right.).

    There's probably no point to this argument.  Both sides are right, so far as I can tell: I dislike it because of poor documentation and not really being such a great language, you like it because of dynamic updating, and in the end we both have valid points.  That, and this thread was supposed to be about licensing and somehow left that territory.

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Starting a new mudlib
« Reply #18 on: January 21, 2013, 01:17:36 PM »
Quix: I agree with the first comment. Ultimately, the game itself is what matters not the technology. And being able to write and embed code on the fly is technology that aids in game play development. Especially on a central server that multiple creators can access at any time from anywhere.

However, compiled options are possible to a degree. Many managed languages come with support to compile themselves. I have a secret to admit. While I've been doing all this driver talk, just to be sure, I went ahead and tried out the idea of running C# within C#. Turns out there are quite a few hurdles to jump through and a serious bug in the .NET (and probably mono too) CLR makes it less than ideal but the end result is that with managed languages that use intermediate compilation you can sorta get the best of both worlds: The speed of JIT combined with the flexibility of updating code on the fly. Plus all the goodies that come with using a well-known and supported language like third-party libs and tools. The downside is of course that sandboxing is much harder and not just built in like with LPC.

Crat: I've spent a lot of time rummanging through DS due to the mods my mud required. And that was fun! But I like to work on the high-level systems - gameplay stuff. Working with the driver just doesn't appeal to me. The sooner I can get away from it and emerse myself in the mudlib itself the happier I will be.  ;D


Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: Starting a new mudlib
« Reply #19 on: January 21, 2013, 08:54:41 PM »
@Camlorn:  It's not that you don't have to reboot.. it's that you don't have to reboot for trivial changes.  You may need to reboot when you update a core system, however some muds don't need to do that.. it dependds how tightly coupled your player objects are to everything else.

However, where lpmuds shine is the ability of a BUILDER to create rooms, npcs, and objects which have live code in them, and have all THOSE things be mutable on the fly.

I ran an original DikuMUD.  I remember having to bounce the server to fix a typo in a room description.  I remember having to submit areas in batches.  OLC and horrible mini-languages like mobprogs go a long way towards avoiding this, but there are still things you need to write custom code to do, and there you have to reboot... not because of a major system change, because a builder wanted his sword to do something cool, but only when an elf held it and was fighting a dragon.

THAT is why LPMUD's are cool.  You can write code to do that, yourself, as a builder, and test it live in your area without having to disrupt anything else.

@Sluggy:  The problem with embedding one language in another, compiled or not, isn't so much the updating.. it's the control.  When you embed ruby, for example, you have to have ways to ensure that you can limit the resources the sandboxed ruby code can consume.

How long do you let a thread run before deciding it's stuck?  How much CPU can it use?  Can one thread hog the CPU, or do you enforce an upper bound to ensure other threads can still get stuff done?  How much local memory can they have?  What about file I/O, or network I/O?

If you're an interpreter, you can easily control all of that in the interpreter's loop.  You're the one evaluating the stack code and handling state, so the ball is in your court.

If you're a compiled language (JIT) being run from another language, you have to hope the sandbox has hooks to let you put all those limits in place (and relax them where actually needed), or someday a bad bit of code will make life miserable.

I'm not saying it can't be done... of course it can (and has).  But, as you said, it's a lot more work than you might think.  And for a MUD, the speed gain is just not needed.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Starting a new mudlib
« Reply #20 on: January 21, 2013, 09:36:07 PM »
Well, yes. But if builders is the issue only, a lot of that can be handled simply by designing for it in the first place.  If I give my builders lua (I use lua here because it's well-known and fast), and a hook that lets them make custom commands for their room (really, really not a good idea in my opinion), I've solved sandboxing because you only get what I want to give you, and you don't have to reboot the server for any minor area changes.  Going even further and making class spells and skills, for example, lua scripts is feasible too.  Lpc is not outdated, not really, but I do think that new mudlibs should, perhaps, be new mud codebases that use modern technologies.  The problems with LPC as I perceive them are above, I'm not going to repeat them here, though I will add that modern scripting languages, at least some of them, have optimizing implementations that go beyond what lpc typically does.

    Using reflection to dynamically load code into the running codebase is not a good idea: sandboxing is the big one here, yes, but also most of the systems that use such techniques optimize code as it runs.  Take java for example.  Java can approach native speed after a few hours of running.  Imbed some new code, which is actually a bit tricky, and even the machinery that would normally optimize your code starts having trouble, even before code is loaded: you're computing method names, basically, and therefore it can't make asumptions.  On top of that: it's typically easy to load new code, it's typically harder to get it unloaded, typically involving wrappers wherein you implement the functionality to let go of the old code.  I looked once, out of curiosity, into methods of doing this properly in java while it is running--ie without reboot--but it's been a while and the answer was always yes, but.  The conclusion was that getting a new class into the system is easy, getting an old class out is hard to impossible.

    There are programming languages that make this possible and somewhat easy to do, i.e. Python, but those have their own issues: even PyPy, for example, takes 40mb to hold 1 million objects with three fields; if these are objects with 3 32-bit int fields, it should only be taking half that.  The default cpython is even worse.  The languages that make these techniques possible have overhead, and lots of it, most of it having to do with being dynamically typed.  It is possible in python to add, not to a class but an individual variable, a new method at runtime that is only valid for that variable and will not work on any others of the same class (saying same class is also misleading, to be honest), but thhat means in the default implementation, most variables start carrieing around a map of methods and their implementations.

    What I think LPC provides, since I've been only negative so far: for the standpoint of new muds, not new mudlibs (codebase, as far as I'm concerned, really), you can get basic rooms and objects, and you can pretty much code anything without having to look at the javadoc, for example--it's a small enough environment not to overwhelm a newbie builder who hasn't seen code before, or for that matter a veteran programmer who has, it's specialized for strings, and it hides a lot of stuff like pointers.  There's a lot of mud-specific support.  It can be secured, if you know what you're doing.  The power of builders isn't limited, which is both a good and a bad thing, depending on how much standards you have in place that you rigidly make everyone adhere to (see old lpmuds, and the typical example of throw rock that gets thrown around when add_action is bad comes up).  It offers, for new mudlibs, preimplemented telnet, but in the grand scheme of things implementing telnet is a very, very small amount of work, anyway.