Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Builders and Areas
Click here to Register

Reply
 
Thread Tools
Old 07-20-2011, 09:55 PM   #1
epicureanideal
New Member
 
Join Date: Jul 2011
Posts: 4
epicureanideal is on a distinguished road
Question Need for a new MUD engine?

Is there a need for a new MUD engine? I'm aware of a few engines, but do they give you everything you want? Is there anything missing? I'm interested in building an engine that would make it pretty easy to get something up and running of similar quality to DragonRealms or GemStone IV. Is there some existing tool I'm not aware of that makes it relatively easy to do this?

If I do work on an engine (pretty sure I will), what kinds of things should I not forget to include?

Note: Electrical Engineering & Computer Science student at Cal with classes in Compilers and Operating Systems behind me, and some software work experience prior to going to Cal. (Just so you know I'm not just a random dude who can't possibly pull off such a thing.)
epicureanideal is offline   Reply With Quote
Old 07-20-2011, 11:59 PM   #2
melopene
Member
 
Join Date: Apr 2002
Location: Birmingham, AL
Posts: 118
melopene is on a distinguished road
Send a message via AIM to melopene
Re: Need for a new MUD engine?

Quote:
Originally Posted by epicureanideal View Post
Is there a need for a new MUD engine? I'm aware of a few engines, but do they give you everything you want? Is there anything missing? I'm interested in building an engine that would make it pretty easy to get something up and running of similar quality to DragonRealms or GemStone IV. Is there some existing tool I'm not aware of that makes it relatively easy to do this?

If I do work on an engine (pretty sure I will), what kinds of things should I not forget to include?

Note: Electrical Engineering & Computer Science student at Cal with classes in Compilers and Operating Systems behind me, and some software work experience prior to going to Cal. (Just so you know I'm not just a random dude who can't possibly pull off such a thing.)
I can't say that it would hurt anything, but I can't say that there is a need either.

Also, having first learned MUDs through Terris/GemStone/DragonRealms/ModusOperandi, I have to say that when the Terris code got leaked and I saw it, I laughed so hard that I cried. Dunno about the GS/DR codes, but wow, that was a mess.
melopene is offline   Reply With Quote
Old 07-21-2011, 12:43 AM   #3
Ide
Senior Member
 
Join Date: Feb 2006
Location: Seattle
Posts: 361
Ide will become famous soon enoughIde will become famous soon enough
Re: Need for a new MUD engine?

The engine is a relatively small part of a mud game. If your goal is to create something that can support a game such as the ones you mentioned, keep this in mind.
Ide is offline   Reply With Quote
Old 07-21-2011, 05:20 AM   #4
Orrin
Member
 
Orrin's Avatar
 
Join Date: Jul 2008
Name: Matt
Posts: 141
Orrin is on a distinguished road
Re: Need for a new MUD engine?

Develop an engine if you want to, but don't do it because of any perceived "need" for one and be prepared for the fact that nobody will use it. There have been codebases around for years that are capable of supporting professional quality games but most new muds tend to use the codebase the creator was most familiar with as a player.

As Ide said the engine itself has very little bearing on how the game actually plays, so if you were talking about creating a kind of stock codebase complete with a DR/GS-a-like canned game then you would probably find more people interested in using it.
Orrin is offline   Reply With Quote
Old 07-21-2011, 05:59 AM   #5
Vigud
New Member
 
Join Date: Jan 2011
Posts: 3
Vigud is on a distinguished road
Re: Need for a new MUD engine?

Yes, I think there really is a need for a new MUD engine. I've been looking for one for myself and haven't found an ideal one, although I must admit I have quite non-standard requirements. But I share some pain with other people I've seen asking for help in choosing the right codebase for them.

To answer your question as to what features should be included, I think this is a good start: MUDBytes Community - Viewing Topic: It looked good on paper!. But there are other important things that I feel I should mention here.

Permissive license... Because some people would like to at least have an option to make money on their MUDs. GNU GPL would suffice in that case, but some people distribute binaries in form of offline builders, offline testing environments, world editors and maybe more. Then, GNU GPL would force them to distribute the source code, which is unacceptable for most of MUD admins, if not all of them. Of course, if you're writing your code in Python, Ruby or the like, then that's a different story.

The code should make sense. It seems to be too obvious, but often it is a problem (for example, where two completely different programming languages are used to build one MUD codebase, it is problematic to choose where to add things you'd wish to have in your MUD). Try hard to avoid conceptual errors.

Don't be fooled into thinking that LPMUDs are for roleplay, Diku derivatives are for mindless killing and MUSHes are for story-telling. You can do anything, you can write a monolithic MUD engine in C enforcing story-telling, or a modular LPMUD-like creature written in Python, or an AberMUD-style game done the backend-frontend style (driver-mudlib, hardcode-softcode), or whatever else you can imagine.

Also, make the main repository public, so that people don't wait ages for an update or patches...
Vigud is offline   Reply With Quote
Old 07-21-2011, 09:18 AM   #6
Will
Member
 
Join Date: Aug 2007
Posts: 90
Will is on a distinguished road
Re: Need for a new MUD engine?

At the time David Whatley wrote GSL it was probably the best multi-player text engine out there, but it's nothing special in this day and age. (Some of its scripting syntax had/has a lot of similarities to assembly.) I can say without equivocation that LambdaMOO is MUCH more modern, extensible and easy to use. What made Simu's games so successful (other than timing) was game play and attention to detail. They were professionally engineered and implemented, and it showed.

As folks have pointed out, it's less about the language you use and more about what you do with it.
Will is offline   Reply With Quote
Old 07-21-2011, 04:07 PM   #7
plamzi
Senior Member
 
plamzi's Avatar
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: Need for a new MUD engine?

To be blunt, I don't think there's any need for a new MUD *.*

That doesn't mean you shouldn't enjoy writing a new MUD engine.
plamzi is offline   Reply With Quote
Old 07-21-2011, 07:00 PM   #8
epicureanideal
New Member
 
Join Date: Jul 2011
Posts: 4
epicureanideal is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by Orrin View Post
As Ide said the engine itself has very little bearing on how the game actually plays, so if you were talking about creating a kind of stock codebase complete with a DR/GS-a-like canned game then you would probably find more people interested in using it.
Yes, actually this is more like what I had in mind. Obviously the engine is pretty small without any scripts or other things in the game, no room descriptions, etc. I am interested in making a "canned game" but that is also heavily modifiable. Right out of the box/can it would be similar to DR/GS but could be further expanded. It would also have a good automatic room generator that could make tens of thousands of unique looking rooms for a variety of common environments.

Before I go and make a whole bunch of already implemented stuff, I should ask, what kinds of things do you find most important? What would you want to come with your engine/MUD building package?
epicureanideal is offline   Reply With Quote
Old 07-21-2011, 07:04 PM   #9
epicureanideal
New Member
 
Join Date: Jul 2011
Posts: 4
epicureanideal is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by Will View Post
At the time David Whatley wrote GSL it was probably the best multi-player text engine out there, but it's nothing special in this day and age. (Some of its scripting syntax had/has a lot of similarities to assembly.) I can say without equivocation that LambdaMOO is MUCH more modern, extensible and easy to use. What made Simu's games so successful (other than timing) was game play and attention to detail. They were professionally engineered and implemented, and it showed.

As folks have pointed out, it's less about the language you use and more about what you do with it.
Right. I think I need to emphasize this aspect of what I want to do more than I have been. I want to make a "MUD building package", including an engine, scripts and items ready to use, a room generator, and any other tools you all and I can think of. I'm particularly interested in creating a new, very good scripting engine for the MUD.
epicureanideal is offline   Reply With Quote
Old 07-21-2011, 07:34 PM   #10
epicureanideal
New Member
 
Join Date: Jul 2011
Posts: 4
epicureanideal is on a distinguished road
Re: Need for a new MUD engine?

There is a tool for creating compilers called ANTLR that has some interesting features. If you're wanting to build a new programming language you can just select "sure, I want strong typing" (like C) or "no, I want dynamic typing" (like Python), and various other things before you even start defining your language. I want to do something like that for a MUD, where there are a lot of major components already built and even multiple options for certain components. For example, does the administrator want to include a magic system at all? Yes or no. Does the administrator want to use combat system A or B? Does the class system work more like this or more like that? And so on. So the administrator would just spend 15 minutes selecting the basic options for their MUD and it would be up and running with high quality systems. If they want to further customize they can modify the scripts.
epicureanideal is offline   Reply With Quote
Old 08-19-2011, 07:47 AM   #11
Manitas
New Member
 
Join Date: Feb 2005
Posts: 10
Manitas is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by epicureanideal View Post
Is there a need for a new MUD engine?
There is,
under the condition it uses websockets. By the time you finish the standard will be well established.

Making yet another telnet server is a waste of time imho.
Manitas is offline   Reply With Quote
Old 08-19-2011, 08:45 AM   #12
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: Need for a new MUD engine?

Quote:
Originally Posted by Manitas View Post
There is,
under the condition it uses websockets. By the time you finish the standard will be well established.

Making yet another telnet server is a waste of time imho.
Websockets clients can already indirectly connect to any telnet-based mud. You don't need to throw away 20 years of mud client development just to support websockets.

Browser clients are a good way of lowering the entry barrier for new players, because you remove the need to download and install software before playing. But you'll alienate many established mudders if you force them to use a browser client - particularly if it doesn't offer the same features as their normal client.
KaVir is offline   Reply With Quote
Old 08-19-2011, 10:38 AM   #13
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Need for a new MUD engine?

Just thought I'd chime in here, to mention a couple things.
First, what KaVir says about mud clients is totally and completely correct; I just want to add that you'd also be alienating blind players, which aren't as rare as you'd think. Every mud seems to have one, and some of the larger muds get into the double digits; gw2 has or had, last time I played, quite a few; alter aeon has a large enough group that there's been a premade client package for them; and Miriani has like 30 blind players.

Also, documentation. I can't stress this enough. Current mud engines either are documented poorly or not at all. Lpc, for instance, has about as many variants as there's drivers for it, and most of those don't have online documentation, anymore. The best documented mudlib I've found so far is dead souls, which does a passable job, but not everything is documented, which is frustrating. On the other hand, we've got smaug. Smaug's not a bad engine, but there's next to no documentation on how it actually works. Given the coding environment for that, it'd be nice to know how stuff actually works, instead of just add these lines here.

Anyhow, just my two cents.
camlorn is offline   Reply With Quote
Old 08-19-2011, 11:54 AM   #14
Manitas
New Member
 
Join Date: Feb 2005
Posts: 10
Manitas is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by KaVir View Post
Websockets clients can already indirectly connect to any telnet-based mud. You don't need to throw away 20 years of mud client development just to support websockets.
To be honest, the results of the 20 years mud client development aren't very impressive at all. A web client written in no time can put to shame all of them.
Mud clients purpose is to address the shortcomings of raw telnet stream, there's no reason to keep them besides improving the experience of old telnet muds, and I remind you, the topic is about writing a new codebase from scratch.

Yes, we can throw away 20 years of mud client development, it was a dead end.
There are no rational reasons to stick to old technology, only nostalgia. Games are important, not technology.
It's time to move on.
Manitas is offline   Reply With Quote
Old 08-19-2011, 12:24 PM   #15
Manitas
New Member
 
Join Date: Feb 2005
Posts: 10
Manitas is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by camlorn View Post
Just thought I'd chime in here, to mention a couple things.
First, what KaVir says about mud clients is totally and completely correct; I just want to add that you'd also be alienating blind players, which aren't as rare as you'd think..
Not quite true, nothing prevents web clients from being accessible for blind users, it's a question of design.

The fact is, pure telnet interface is a pain, and i can imagine it is even worse for the blind, as they rely on screen readers, so they are limited to sequential reading and must have difficulties navigating the wall of text back n forth.

Now notice that browsers can play sounds stored on the server, and imagine the possibilities for the blind players.
Manitas is offline   Reply With Quote
Old 08-19-2011, 02:15 PM   #16
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: Need for a new MUD engine?

Quote:
Originally Posted by Manitas View Post
To be honest, the results of the 20 years mud client development aren't very impressive at all. A web client written in no time can put to shame all of them.
Web clients have been around for years now, yet even the most advanced of them are still a long way behind in terms of features. I've seen nothing suggesting that the situation will change - both types of client seem to be advancing at a similar pace.

Quote:
Originally Posted by Manitas View Post
Mud clients purpose is to address the shortcomings of raw telnet stream, there's no reason to keep them besides improving the experience of old telnet muds, and I remind you, the topic is about writing a new codebase from scratch.
Telnet is simply a network protocol, dropping support for it won't let you do anything you can't already do on existing muds; as I mentioned previously, you can already connect to telnet muds using a websockets client.

The only thing your proposal would achieve is to block the dozens of existing mud clients that have been developed over the last couple of decades - some of which are far more powerful than any web-based mud client, and many of which have a devoted following who will refuse to switch clients.

Don't get me wrong, web clients are a nice thing to have, particularly when drawing in new players - there's a good reason why so many commercial muds have invested in their own custom web client. However there's also an equally good reason why those same muds continue to support established clients.

Quote:
Originally Posted by Manitas View Post
There are no rational reasons to stick to old technology, only nostalgia. Games are important, not technology.
You say that games are important, not technology - yet you propose dropping support for a well-established and strongly-supported network protocol simply because it's old?

But let's say the OP were to follow your suggestion, and create a new mud engine which uses websockets. We know that websockets clients can already connect to any telnet mud, meaning that every mud can take advantage of their graphics, sound, etc. So what's the selling point of this new engine?


Quote:
Originally Posted by Manitas View Post
The fact is, pure telnet interface is a pain, and i can imagine it is even worse for the blind, as they rely on screen readers, so they are limited to sequential reading and must have difficulties navigating the wall of text back n forth.
Around 20-25% of my active players are blind or visually impaired, and they manage fine.

Quote:
Originally Posted by Manitas View Post
Now notice that browsers can play sounds stored on the server, and imagine the possibilities for the blind players.
Many mud clients already let you play sounds, and unlike browsers they don't have to deal with inconsistant caching.
KaVir is offline   Reply With Quote
Old 08-20-2011, 05:48 PM   #17
Manitas
New Member
 
Join Date: Feb 2005
Posts: 10
Manitas is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by KaVir View Post
Web clients have been around for years now, yet even the most advanced of them are still a long way behind in terms of features. I've seen nothing suggesting that the situation will change - both types of client seem to be advancing at a similar pace.
Up to now browsers had to rely on third party software coming with their own pros and cons, so putting much effort in web mud client development made little sense.

Now we are going to have native support for full duplex communication in browsers - standardized.
This indeed, is suggesting that the situation will change.

Quote:
Originally Posted by KaVir View Post
Telnet is simply a network protocol, dropping support for it won't let you do anything you can't already do on existing muds; as I mentioned previously, you can already connect to telnet muds using a websockets client.
This can be debated.
The thing is, why keep it if its not needed anymore. Is the overhead worth it just to sustain third party clients?
It's violation of the KISS principle, and simplicity does matter.

Quote:
Originally Posted by KaVir View Post
The only thing your proposal would achieve is to block the dozens of existing mud clients that have been developed over the last couple of decades - some of which are far more powerful than any web-based mud client, and many of which have a devoted following who will refuse to switch clients.
How so?
We re talkin about making a new codebase here, not about destroying existing muds and prohibition of old codebases.

Quote:
Originally Posted by KaVir View Post
You say that games are important, not technology - yet you propose dropping support for a well-established and strongly-supported network protocol simply because it's old?
No, because it's obsolete.

Telnet was good for its time because it was standard and available everywhere. Alas, its limitations created the need for all that mess, multitude of third party client software, some commercial, some platform dependent etc.

Now, hardly anyone knows what telnet is, HTML5 is becoming a standard, and webbrowsers are available everywhere.
And they allow creators to provide their own clients easily, and keep everything server side.

Quote:
Originally Posted by KaVir View Post
Many mud clients already let you play sounds, and unlike browsers they don't have to deal with inconsistant caching.
Cause they are client side, perhaps?
Manitas is offline   Reply With Quote
Old 08-20-2011, 07:37 PM   #18
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Need for a new MUD engine?

Ok, firstly, I am a blind player; when I say that mud clients are better, I know what I'm talking about. Web clients require a -lot- of effort to make accessible, and new text won't automatically be read as it appears (an essential feature, given that we can't see what the newest line is). As for sounds, I'm going to end that argument before it gits started: mud clients already have better support. To make a mud that's accessible only through sound is going to require 3d math, and you might as well just go ahead and make a full-blown mmorpg at that point. This, of course, isn't mentioning that you'd almost have to make it pay to play, as you now need professional sound artists and programmers for your web client who know accessibility programming. In order to make things accessible, you've got to learn a whole new set of classes and functions.

Secondly, web clients aren't going to rival any of the stand-alone clients anytime soon; the standalone clients aren't 20-minute projects, far from it. Have a look at the sheer number of options in mushclient sometime and the plugin lists, and you'll begin to realize the power of stand-alone clients. Web clients do have their place, however, as they can help to draw in new players.

Telnet isn't as popular as it used to be, I will say that much, but even windows still has a telnet client/server for command line access. SSH is basically encrypted telnet+, as well,, which is still used for advanced web administration. I could be wrong on this; someone like KaVir would probably be able to correct me if I am. Dropping the protocol seems kind of silly to me given that (a) you've got a large mud playerbase who uses it and (b) you can add more protocols if you want: there's about 5 or 6 major mud-specific ones now, and whatever you call your message function, it's still going to probably take a string, anyway.

Finally, we don't want this to go the way as the recent rpi thread. Keep that in mind and remember that these forums are publicly viewable by potential new players. That thread went on about 20 posts too many, let's not have a repeat. I'm not saying that there's not a place for argument, but it's not this thread, I don't think, anyway.
camlorn is offline   Reply With Quote
Old 08-20-2011, 08:29 PM   #19
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: Need for a new MUD engine?

Quote:
Originally Posted by Manitas View Post
Up to now browsers had to rely on third party software coming with their own pros and cons, so putting much effort in web mud client development made little sense.

Now we are going to have native support for full duplex communication in browsers - standardized.
This indeed, is suggesting that the situation will change.
Standardisation may make browser clients more appealing. But they're still many years behind in terms of features.

Should they somehow catch up, there's nothing preventing existing muds from offering their own customised browser clients.

Quote:
Originally Posted by Manitas View Post
The thing is, why keep it if its not needed anymore. Is the overhead worth it just to sustain third party clients?
The development overhead is obviously zero if the mud has telnet support already. As for the overhead of adding support, well, the value of that depends on who the engine is being marketed at.

A prospective mud owner looking to start up their own codebase will weigh up the pros and cons of each option, depending on their needs. If they plan to support a websockets client, they can already use any codebase, so that won't be a selling point. However if they wish to support established mud clients, and you've removed support from the engine, that's likely to be a deal breaker.

This isn't a choice between "X" and "Y". It's a choice between "X" and "both X and Y".

Quote:
Originally Posted by Manitas View Post
Quote:
The only thing your proposal would achieve is to block the dozens of existing mud clients that have been developed over the last couple of decades - some of which are far more powerful than any web-based mud client, and many of which have a devoted following who will refuse to switch clients.
How so?
We re talkin about making a new codebase here, not about destroying existing muds and prohibition of old codebases.
Where do you think those players are going to come from? The people most likely to try out a new mud already play muds, and most of them have a favourite client.

In fact the biggest road bump a new engine faces is one of familiarity. Unrestrictive licences, clean code, advanced features, etc, are all nice to have, but the main reason people pick a certain codebase is familiarity - it's what they're used to, either from playing, or from running previous muds. Drop support for established clients as well, and you make the situation even worse.

Quote:
Originally Posted by Manitas View Post
Quote:
You say that games are important, not technology - yet you propose dropping support for a well-established and strongly-supported network protocol simply because it's old?
No, because it's obsolete.
It is not obsolete, it's widely used and supported, and IMO it's well-suited to muds. It can already handle whatever you might want to do with websockets - including graphics and sound.

It sounds like you want to drop it because it's "not cool enough". If you wish to do that for your own game then fair enough - but recommending someone else drop support for advanced mud clients just because you think they're not cool, when the engine is already going to struggle to attract an audience, is really not very fair.

Quote:
Originally Posted by Manitas View Post
Now, hardly anyone knows what telnet is, HTML5 is becoming a standard, and webbrowsers are available everywhere.
And they allow creators to provide their own clients easily, and keep everything server side.
Mud owners can already provide their own websockets clients if they wish, they don't need to drop telnet for it.

Keeping everything server-side would be a killer for smartphone mudders though. It would also block people on older computers, and prevent players from customising their interfaces.

There are no benefits in dropping telnet support, only drawbacks.

Quote:
Originally Posted by Manitas View Post
Quote:
Many mud clients already let you play sounds, and unlike browsers they don't have to deal with inconsistant caching.
Cause they are client side, perhaps?
Sounds are always played client side. Your web browser is just another client.
KaVir is offline   Reply With Quote
Old 08-22-2011, 09:30 AM   #20
Manitas
New Member
 
Join Date: Feb 2005
Posts: 10
Manitas is on a distinguished road
Re: Need for a new MUD engine?

Quote:
Originally Posted by camlorn View Post
Ok, firstly, I am a blind player; when I say that mud clients are better, I know what I'm talking about. Web clients require a -lot- of effort to make accessible, and new text won't automatically be read as it appears (an essential feature, given that we can't see what the newest line is).
Actually, you can't compare standalone mud clients to websocket browser clients, because none of the latter exists (to my knowledge).

Your complaints about existing flash and java based clients are understandable, as they are infact external objects embedded in HTML, and one can't expect them to work with readers wery well.

Websockets allow to design the client as a normal, interactive website, just like these forums youre using.

Quote:
Originally Posted by camlorn View Post
Finally, we don't want this to go the way as the recent rpi thread. Keep that in mind and remember that these forums are publicly viewable by potential new players. That thread went on about 20 posts too many, let's not have a repeat. I'm not saying that there's not a place for argument, but it's not this thread, I don't think, anyway.
You don't have to worry, we're discussing some underlying mechanics of no concern to new players.
Manitas is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 11:53 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014