View Single Post
Old 04-07-2008, 08:06 PM   #10
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Re: What do you think happened to LPmuds?

Unix/linux vs. Windows - Well, I had the need, because I wanted to work with the code, so I could learn it and work on ideas, *before* coding for the mud I played at. Building a *nix machine to do that wasn't high on my list. But yeah, being able to run something one either one is nice. As for the "almost worked" issue they had with yours. Are you using ActiveScript? If so, you need to be aware that a) this only works on "some" WINE installs, the installers for the languages often don't work, and its usually easier to just drop the dll into the directory with your server. Second, ActiveScript has, for most languages, *huge* problems with reloading script. The client I play with used it initially to support scripting, but now uses Lua as its default. Since then we discovered that there is a bug in ActiveScript for some/all languages, where quick loading short segments of code over and over results in memory being used up, but not released fast enough. This might be the equivalent of loading the script for an npc 500 times in quick succession, or some such. And that is presuming you get the language to work at all, since some of the ActiveScript implementations for a few languages proved so flaky that they wouldn't load, crashed the client as soon as you loaded script into them, or just hung.

In any case, I think relying on Windows scripting to do anything that may require a lot of switching in/out of code, is "not" a good idea.

Simple example world - Doesn't need to be that big, I think, but it you support grid systems, it should show it, and work right, same with any other "features" of the library. And, document the hell out of it. The ones for LPC I have seen are a) badly documented, b) incomplete, and c) if they did work on Linux, it was almost *always* broken on Windows.

Difficulting of teaching new people - This is a problem only if the library is badly made. You "can" make code so that it could be generated by GUI and is easy to code, and *still* get a lot of function in the scripting. OOP style stuff is good for that, since you can handle things that happen as events, and simply have it execute the code "if" you supply it. If you don't, default to ignoring the event, or using the standard library behavior. Its only if you force people to code "everything" that you run into a problem. Fact is, for most cases, the fill in the blanks method of Diku is quite reasonable, it just goes to far, by not providing a way to override the original behavior, without overriding the entire core server's combat, room handlers, etc.

Licensing - ... Good luck with that. The problem you have here is you presume you have control over the client (or will for the foreseeable future). The reality is, unless you add overhead via encryption, to add a "DMCA" style protection to those features, people *will* crack the communications and replicate the features in other clients. Heck, I have been pushing for years to redesign parts of the client I use to add true object support to the script system it uses. With that, nearly "anything" could be duplicated with it. The only reason it hasn't happened yet is that it was written with MFC, and that set of libraries and macros doesn't allow events to be registered and passed back to the script system. Otherwise, I doubt there is much you could think of that someone wouldn't already be producing for existing games, by parsing the data already available. Figuring out how to create interoperability with your server's features wouldn't even get a yawn at that point.

Frankly, I am not sure how long the "if you want to use these features in my client, pay me!", model will keep working. The only model that I think, imho, *does* work is to turn on/off the features on the server end, and let who ever wants to implement the support of it (if they opt to create support for it for their clients). The only thing that keeps it from happening more already is that no one has made a client which is that flexible yet. When they do.. All bets are off.

Basically, you might be able to give away the client, and the server, then charge for a "library" which implements the features. The people running the servers are likely to buy it, because the client supports it. You players though... They are either going to ignore the game, try to break the protocol, ignore the features, or *maybe* pay for it. I don't give good odds on the later being *at all* significantly larger than the first three groups. And, once people start breaking the protocols, you have to release new clients with patches, to prevent the breach, changes to the server to have it work, etc. The server users are not likely to comply (you already told them they don't need to by giving it out free) and.. Well, I think you get my point.
shadowfyr is offline   Reply With Quote