LPMuds.net

LPMuds.net Forums => Licensing => Topic started by: Sluggy on January 16, 2013, 08:39:47 PM

Title: Starting a new mudlib
Post by: Sluggy on January 16, 2013, 08:39:47 PM
Recently I've decided to start a new mudlib. It's mostly as an exercise of curiosity but I'd like to leave myself open to the option of releasing it to public domain. To that end I'd like to confirm a few things about licensing in relation to drivers and existing mudlibs.

1) Is the 'Lil' mudlib found on the downloads page considered PD? I can't seem to find any indication of its license.

2) What rights do I have when I use code from PDed mudlibs. As a specific example: Am I allowed to yank, say, the sefuns DeadSoulsII (the PDed version) and use them in my project with complete freedom - including freedom to modify or use any non-whole pieces as I see fit?

3) What about packaging a driver - specifically in the case of starting with a previously existing code base like Lil? Can I distribute the source from the latest build of FluffOS? What about the windows binary? Do I have to rebuild it myself of can I simply take a build from another PDed mudlib package.

I can probably take a guess at some of this stuff but I'd simply rather have it spelled out right to me just to be sure. I'll probably also have further questions based on what answers I get for this stuff.


Title: Re: Starting a new mudlib
Post by: Newt on January 18, 2013, 12:12:22 AM
Since there has been no response to this, I guess I'll give it a go and if I get it wrong then maybe someone will be kind enough to correct me.

1) I believe Lil to be under the same license as MudOS.

2) I believe that 'public domain,' as I've seen it used for code, means that you can do whatever you want with it.  **Giving 'credit where credit is due' is prolly still a good idea.

3) FluffOS follows the license of MudOS and MudOS follows the license of the original LPmud..which basically says two things...you can't make money using it, and all rights of the original authors are (p)reserved.


So, as I see it, a lib based on Lil would be restrained, at the minimum, to being non-commercial...you should be free to distribute it and the fluff source (and the windows binary, since Cratylus didn't add anything license-wise).
Title: Re: Starting a new mudlib
Post by: quixadhal on January 18, 2013, 08:14:25 AM
Remember, FluffOS is not the only driver out there.

If you're really starting a mudlib from scratch, DGD is GPL licensed (I think), and there's also LDMUD, which could really use a few more public mudlibs for it. :)
Title: Re: Starting a new mudlib
Post by: Sluggy on January 19, 2013, 12:18:20 AM
Newt: Hmm well, if Lil is not Public Domain then I suppose it makes no sense in starting a mudlib from it that I want to be fully Public Domain. Ah well, not like I'm loosing much really to just write the whole dang thing. As it is I've already changed the file structure enough you'd never know it started as Lil. What's a few hundred lines of code. As far as the executable, I'm actually using Crat's build of FluffOS from DS3.6. which just somehow seems rude to package up and distribute.

Quixadhal: Yeah, I've been giving lots of consideration to other driver options, especially DGD. But that's more of a technology concern than a licensing one. I'll probably start another thread for these concerns at some point once I've done some more research. Admittedly, I'm not too keen on my driver knowledge right now.
Title: Re: Starting a new mudlib
Post by: Camlorn on January 19, 2013, 02:45:14 PM
Well, they're kind of the same issue.

    My opinion is, for a mudlib intended to be public domain...well,n I was going to write a mudlib.  I came to the conclusion that just writing the mud in c++ would be best.  I never did get further in that decision, mostly because college is taking up time.  This wasn't because of licensing, it was because c++ is better documented, etc, and has a whole lot less overhead.  This is where people start chiming in and saying "lpc is good enough", and yes, it is.  But this was the conclusion I came to when I wanted to write a mudlib: there's a ton of undocumented stuff on that path, and you need to know about it all.  I have nothing against lpmuds, that's just my thought on new mudlibs. [1] And, my project ideas tend to be things that would eat ram like candy, and probably the cpu, too.

    That said, you should probably pick a driver first.  What you're probably looking for is a driver that allows code to be public domain.  I doubt you're going to find one that lets you distribute the driver with it, as that's basically declaring the driver public domain too, i.e. "Here's my public domain mudlib with driver bundle", and then people go off and start treating the driver like public domain too.  That said, maybe none of them forbid it.

    How much do you know about compiling?  That's another big question here.  Dgd compiles out of the box on windows and linux.  For windows, you just get visual studio and open the project, and that's it.  FluffOS will compile under cygwin, but it was a big deal for Cratylus to make the copy that comes with Dead Souls, which involved MinGW and stuff that I don't have full details on.  Cygwin has licensing issues for redistributing the dlls, i.e. everyone who wants to run it, iirc, needs to install Cygwin.  Ldmud may also build out of the box on windows; I am not sure about that one.

    1: Dgd offers a whole lot of stuff that's hard to do elsewhere, including automated disk swapping and persistence.  If you're going to use the features of dgd that make it dgd, then use dgd--I've not totally convinced myself that a mud shouldn't be written on top of dgd, because implementing full persistence and disk swapping is not really trivial.  In dgd, if you let go of some of the standard mud idiomes, i.e. area resets in the usual way, you can have a mud that, from the perspective of the mud if not the user, never ever shuts down.  You have to be smart to code that way, though, really, really smart (at least, in my opinion).
Title: Re: Starting a new mudlib
Post by: Sluggy on January 19, 2013, 03:35:04 PM
Well I'm pretty sure most of the drivers (like most open software in general) require their licenses to be distributed with them for exactly the reason you suggest. As far as compiling. I know how to do it. But yeah, the most I know about the legal issues involved is mostly based on what Crat wrote about his own experiences. That doesn't mean I can't read up and ask question later though ;)

Without getting too off-topic here I can say that I've read many of your posts about the technology for mudlibs and generally speaking I agree. But LPC is just such a great little language. I mean, it's really great. I actually *enjoy* writing code for it and it's never let me down in terms of language features.  Just as an aside, I actually briefly considered making a mudlib using Unity for a while. However, the idea that creators can write, upload, and activate code while the mud is running is really just too great of a feature to give up.
Title: Re: Starting a new mudlib
Post by: quixadhal on January 19, 2013, 05:38:53 PM
Coding a diku-alike mudlib in LPC is an idea I've toyed with in the past as well.  I have an antique DikuMUD from 1993 that I've always wanted to port to something else, but it's a daunting task... since the two systems work quite a bit differently under the hood.

I would probably use DGD, for the simple reason that you're starting from (almost) scratch anyways... and DGD offers driver-level state dumps and restoration, as well as being a very fast and clean LPC interpreter.  Many of the well-known paradigms of an LPMUD don't apply to a Dikurivative... so places where FluffOS has evolved to support them will be wasted on coding something that works more like a Diku.

What I'm thinking of here is the centralized nature of Diku.. combat would be handled by a daemon, rather than by individual heartbeat actions of each combatant.  Area resets would likewise be handled by a daemon, rather than letting each room do it independantly.

DGD is GPL, but there's nothing saying you can't write a Dikurivative mudlib for it... you just can't distribute the driver with it as a bundle.
Title: Re: Starting a new mudlib
Post by: Camlorn on January 19, 2013, 10:51:24 PM
Well, lpc is great, sorta.  I like it in theory.  I would like it a lot more if there was an official specification, as I learn better from documentation than examples, but this perhaps says more about me than about lpc, and my programming skills in particular.  And, no, I don't mean tutorials, I mean "An identifier consists of alphanumeric characters" specs...

    You can imbed lua in your c/c++ codebase without a problem.  There might be security issues, but there's nothing stopping you moving code to lua.  If the concern is being able to upload and instantly test code, you can't use dgd persistence, not easily.  You should still have a testport anyway.  Writing a mudlib in lua, though, is just you writing the driver which increases the work anyhow.

    But I digress.  LPC is fine as a technology, it just isn't the one I prefer, anymore.

    As for public domain, are you sure you really want to do public domain?  This implies that you do not mind getting credit, ever.  I am going to assume that you know this.  Gpl may be good enough for what you want, or any of the other open source licenses, which will save you from having to go completely from scratch.  I am by no means an expert on licenses either.

    Quixadhal, we do not need yet another dikurivitave.  Really, let's not have another diku clone.  Lpmuds are one of the few places where muds tend to still be not carbon copies of one another.  Technologically, that might work well--especially on something like dgd, if written correctly,  that only brings objects into memory that are being used--but from a gameplay perspective, idk.  Moving all combat code into one place and all magic code into one place and etc, would help understanding, though, yes.
Title: Re: Starting a new mudlib
Post by: Sluggy on January 19, 2013, 11:23:36 PM
Yes, I understand that Public Domain means I give up everything. Period. That's fine with me.

Well most of my basic questions were already answered so I think the license issues have been worked out. From here it seems to be more of a technology argument which I have moved to this thread: http://lpmuds.net/smf/index.php?topic=1417.msg7429;topicseen#msg7429 (http://lpmuds.net/smf/index.php?topic=1417.msg7429;topicseen#msg7429)

As far as your Lua argument I had already considered it albeit using Lua in C#. I mean really, if I'm going to use some big league tech let's go with something NOT C++ ;)  I've also considered running C# as the scripting language in a C# driver. Not too bad since there is already such a project and it seems to work well with the built-in sand boxing library. All I'd need then would be a command buffer/processor/parser, object life manager, and networking connection state/protocol. Actually... that's still a lot of work.  :-X
Title: Re: Starting a new mudlib
Post by: quixadhal on January 20, 2013, 12:59:24 AM
Well, lpc is great, sorta.  I like it in theory.  I would like it a lot more if there was an official specification

Perl doesn't have an "official" spec, and it works just fine. :)

You can imbed lua in your c/c++ codebase without a problem.  There might be security issues, but there's nothing stopping you moving code to lua.

That's a different paradigm.

An LPMUD is a very different beast than some other MUD with a scripting language embedded, because the majority of those other MUD's I've seen still keep core elements of the game hard-coded in C (or whatever the host language is), exposing various events, objects, and triggers to the scripting system.

Part of what makes an LPMUD so flexible is that the entire game is written in LPC.  The only things kept in the driver are I/O events (typically callbacks for socket events and file I/O), and functions to mess with object states (recompile, find, destruct, etc).  The majority of other driver-supplied functions are for performance or convenience, but could be done in LPC itself (and often are overridden in LPC, as sefuns).

While you COULD do the same with Lua/Ruby/Python, most of the examples I've seen available leave a great deal more processing in the driver itself, and tend to expose things at a more game-functionality level... the concepts of "room", "object", and "mobile" are still somewhat hard-coded... you get an event when someone enters the room... which means, for example, if you wanted a coordinate based game, you have to hack the driver.

Quixadhal, we do not need yet another dikurivitave.  Really, let's not have another diku clone.

I'm not sure that's true.  If you remember your history, LPMUD's used to have quite a bit of carbon copying going on... hence the humpback bridge, and Descartes' original decision to revoke Nightmare.  It's just that DikuMUD's are more popular than LPMUD's, and have a much easier learning curve to set up and get running.

If you set aside the prejudice, the biggest legitimate complaint most people have with Dikurivatives is their instability, and that's caused by sloppy string handling code in C (most of the time).  Rewriting such a game in a language without pointers is NOT a bad idea.

Remember, it's the content that makes your game unique, not the technology.  The players neither see nor care how cool your code is.

In any case, I pointed out DikuMUD not so much because it's great, but because it works in a way that's very different than most LPMUD's do, and thus illustrating that many of the features of a heavy driver like FluffOS would go unused in it.
Title: Re: Starting a new mudlib
Post by: Camlorn on January 20, 2013, 02:46:00 PM
See the rest of the bit about lua: increases the work for the same functionality.

    I don't like perl, either, but that's for different reasons which I won't go into here.  Perl is better documented, or at least appeared to be last time I looked at it.  I don't need, I don't even really want, a tutorial, but some sort of official *complete* language reference would make lpc a lot more appealing than it otherwise would be.

    C# isn't a bad choice, if you were to ditch lpc, though it has certain hosting issues, namely, that mono is kind of threatened in a way, and people smarter than me have told me that it isn't nearly as good as the microsoft one.  But you moved that to a different thread.  The upshot, of course, is that you may be stuck hosting on windows, and that tends to be more expensive.

    As for diku and uniqueness.  I know that once upon a time they were different, moreso than now.  I don't know enough about the early lpmuds to comment on that.  But, looking at it now, diku muds tend to be all the same while lpmuds tend to all be different.  I agree with the technological point, however, in that centralizing stuff is a good idea and different from 95% of lpmuds (maybe 100%--I can't think of anything that does this).
Title: Re: Starting a new mudlib
Post by: Newt on January 20, 2013, 03:41:48 PM
Hey, Camlorn, have you come across the basic and intermediate LPC manuals by Descartes?
Title: Re: Starting a new mudlib
Post by: Sluggy on January 20, 2013, 05:39:18 PM
I'm sure he has. He's probably referring to the fact that there is a) no official standard for LPC constructs b) no official standard for how it interfaces with the driver and c) just about no information on how to actually write a lib from scratch - in other words interface with the driver.

The best I've found is a few creator references that mention standard functions like create() and reset() and of course the awesomeness that is opening up a bunch of mudlibs and hunting down their driver interfaces and then comparing them. That last one really sucks because its hard to know if the person writing it really knew something I didn't or if they just had a different way of looking at the problem or if they just hacked together code until something popped up on the console.
Title: Re: Starting a new mudlib
Post by: chaos on January 20, 2013, 06:16:21 PM
On the centralization point, Lost Souls has been trending over time toward centralization of functionality in the mudlib -- I've increasingly come to consider that LPMuds' greatest strength, that any developer can essentially write any behavior they like, is also their greatest weakness.  This is a gradual tendency rather than anything that readily compares to the centralization of a server where you can't do anything but centralize, though.
Title: Re: Starting a new mudlib
Post by: Camlorn on January 20, 2013, 07:23:24 PM
I have seen the lpc manuals.  They have the following problems.
1: They assume you're using a specific mudlib.
2: They aren't actually complete, in that they don't seem to cover all the constructs of the language.
3: more constructs have been added since they were written and
4: No info on mudlib from scratch, indeed.  There's some documentation on this, but a lot of it is todo: document foo.

    They also assume only that you are wanting to build and are written for someone who has never programmed before.  I'm not the most advanced programmer, but I know what a variable is, thanks, and I can explain c++ templates (as well as have an interest in template metaprogramming).  I'm not necessarily good at large projects, but I already know how to write a function, and over half the available documentation assumes that I don't, letting go of the complex topics in favour of being accessible to newbie programmers.

    This may have been fixed, but the latest copies of FluffOS don't seem to come with documentation, anymore, too.

    So, my obvious choice is...why learn lpc, when I can just go pick up c++ or java or any number of other perfectly good languages, and when I have a problem someone else has probably had the same problem?  I mean, I can get the specification, there is a standard, etc.

    I would consider dgd for my projects.  I would not consider another lpc driver.  Dgd has functionality that is extremely, extremely difficult to duplicate outside of Dgd, and therefore utilizing it is beneficial if I wanted that functionality.  In other languages, I can get dynamic code updating, if I really want, though it is hackish in other places, and major changes to the mudlib typically require reboots anyway.  Tbh, atm, I'm seriously looking at Go, which is supposed to have short compile times, has sane multiple inheritance, and reflection capabilities, without the large memory overhead of python or the slowness that is java until the server's been up for a few hours.  Unfortunately, college and (in the future) work will probably get in the way of me actually doing anything--I should have done it while I had time to do it, but didn't so my loss.
Title: Re: Starting a new mudlib
Post by: quixadhal 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.
Title: Re: Starting a new mudlib
Post by: cratylus 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.
Title: Re: Starting a new mudlib
Post by: Camlorn 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.
Title: Re: Starting a new mudlib
Post by: Sluggy 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

Title: Re: Starting a new mudlib
Post by: quixadhal 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.
Title: Re: Starting a new mudlib
Post by: Camlorn 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.