Starting a new mudlib

[Sluggy]

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.

[Newt]

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).

[quixadhal]

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.

[Sluggy]

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.

[Camlorn]

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).

[Sluggy]

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.

[quixadhal]

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.

[Camlorn]

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.

[Sluggy]

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

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. 

[quixadhal]

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.

[Camlorn]

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).

[Newt]

Hey, Camlorn, have you come across the basic and intermediate LPC manuals by Descartes?

[Sluggy]

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.

[chaos]

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.

[Camlorn]

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.