10 Aug, 2010, donky wrote in the 1st comment:
Votes: 0
I started a topic in general discussion which has meandered over related subjects. But I was reading another topic in this subforum, and I felt obliged to share some more thoughts for you to potentially ignore and discuss tangentially related subjects of.

The "another" topic touched on writing a parser. But what I did not see (although it was not necessarily being asked) was, "Oh, I see you are using Python, here are some nice and clean open source parser libraries that you should be able to import into your codebase with little coupling." I don't even think it is possible to say that, even if it were.

  • Are there any languages where there is a healthy ecosystem of MUD code sharing and reuse, without that code being embedded into a codebase?
  • Is it even possible to abstract and release a game system, like a parser, in such a way that people can just plug it in and immediately make use of it? For instance, as a Python library.
10 Aug, 2010, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
donky said:
Are there any languages where there is a healthy ecosystem of MUD code sharing and reuse, without that code being embedded into a codebase?


Except mobs IA that can be relatively well abstracted, most of code cannot be that easily shared because you often need to modify a lot of methods for a single functionality.
ie: the codebase is only a framework, and very few code can be easily shared between different framework.
10 Aug, 2010, David Haley wrote in the 3rd comment:
Votes: 0
I disagree that it's impossible to write decoupled code in general. Obviously not everything can be made independent - game logic is such a thing - but many things could be split apart.

Now, why doesn't that happen? The answer to that is relatively simple I think: it requires more skill and/or effort than people are willing to invest.
10 Aug, 2010, JohnnyStarr wrote in the 4th comment:
Votes: 0
Ideally, a project would be started with firm standards. For instance, if you were to have a mud platform intact it could be done.
Realistically this probably wont happen. At least not for hobbyists. If you had something comparable to the
.net framework for instance, you could package QuestSystem. This would allow someone to plug in the resource and go. Naturally you would have to make sure that your class lib was in strict standard with everything else.

I think the problem with that is everyone wants to make things so custom, they would be unhappy with
standards. LPC is a good example: Although two muds might use the same Driver, they will no doubt right
away start adding things to the MudLib (depending on their ability) and start losing standards previously
in play.

I love this idea though, it would be really fun to have a BIG collaborative project. Sort of a nerds of the world unite.
But alas, I just don't see it happening :cry:
10 Aug, 2010, Tyche wrote in the 5th comment:
Votes: 0
A few years back (2004) I started a project to write a modular mud inspired by similar posts on TMS. It was a mud where one could pick and choose modules through configuration files. I called it the Mesh project or MeshMud some such thing. It was ostensibly language neutral. Some C, C++, Ruby modules were produced by myself and another chap Ero/Muir that talked to each other via C interfaces and Swig. The repo is here. I still have the wiki and forums intact but they are currently offline. A few of the people who post here- KaVir, Scandum, Kaz are probably familiar with it.

A few years before that (1997-1998ish) there was a project called DevMud that I worked on briefly. The idea was to create a modular mud that dynamically loaded the modules at runtime. It's was a pure C. For a while we shared the Mud-Dev list using a [DevMud] tag in the subject then moved to a Dev-Mud mail list also hosted at kanga.nu. Some of the code is here. Later versions are laying around elsewhere.

Occasionally I like to write mini-tutorials on various subjects and share them. Usually they are written in C, C++, Ruby… sometimes multiple languages. I've got three tutorials I started but never posted/published as I could never see a good point of bringing them to a conclusion. That is I start writing and see an interesting alternative and start writing about that, and then it's quickly looking like each introduction of a new character in a Wheel of Time epic.

Anyway it's sort of like the contest idea, everybody wants to see other people writing and sharing code, but very few want to do it themselves.

Cratylus has ported a half dozen or more LP mudlibs to FluffOS, so there's a great potential for sharing there.

Some mud communities share code much more freely than any others, like the Mush community.
11 Aug, 2010, donky wrote in the 6th comment:
Votes: 0
Tyche said:
A few years back (2004) I started a project to write a modular mud inspired by similar posts on TMS. It was a mud where one could pick and choose modules through configuration files. I called it the Mesh project or MeshMud some such thing. It was ostensibly language neutral. Some C, C++, Ruby modules were produced by myself and another chap Ero/Muir that talked to each other via C interfaces and Swig. The repo is here. I still have the wiki and forums intact but they are currently offline. A few of the people who post here- KaVir, Scandum, Kaz are probably familiar with it.

A few years before that (1997-1998ish) there was a project called DevMud that I worked on briefly. The idea was to create a modular mud that dynamically loaded the modules at runtime. It's was a pure C. For a while we shared the Mud-Dev list using a [DevMud] tag in the subject then moved to a Dev-Mud mail list also hosted at kanga.nu. Some of the code is here. Later versions are laying around elsewhere.



Anyway it's sort of like the contest idea, everybody wants to see other people writing and sharing code, but very few want to do it themselves.

I think your post highlights a common theme in this topic. That people seem to consider modular code that is to a degree decoupled as being the standard achievable level of sharing.

Now the LP mudlibs for instance, may have code that could be shared and some indeed do, but each tends to have their own framework over which the code is coupled. Some have daemons, some have services. Some have stacked security systems, some do not. Nightmare's intermud daemon for instance, tends to be the base for other mudlibs to have adopted. And the same with Lima's stacked security system. But I guess the common factor is that these systems are generally set in stone how they would work, and the effort of reimplementing them pales compared to taking and adapting them to suit another mudlibs custom framework.

Similarly your DevMud and MeshMud projects sound like custom frameworks which the modular systems within them were coupled to.

Now, going back to the parser, even something like that has coupling to game logic. It needs to match grammar to reachable objects and containers, and that implies a need for an API so that it can interact with the world. Perhaps only things like embedded intermud clients, web servers, ftp servers and other naturally standalone systems can be easily adopted.
11 Aug, 2010, donky wrote in the 7th comment:
Votes: 0
JohnnyStarr said:
I think the problem with that is everyone wants to make things so custom, they would be unhappy with
standards.

Well, in terms of having things like libraries that any MUD framework of the same programming language could make use of, I am not sure standards are required. A library would have to be standalone to the extent where it could define an API that was not overly cumbersome, that the framework could make use of.

I think if standards were required for the libraries to be easier for the frameworks to make use of, then it would be doing it wrong. Personally, I have taken the approach of having a custom framework and systems that are coupled to it to the level where I avoid the library packaging system that comes with my language of choice up to this point. But now, I am seeing more and more advantage in adhering to the standard approaches as much as possible.
11 Aug, 2010, Kylotan wrote in the 8th comment:
Votes: 0
Here's a thought.

One reason why sharing code is often so difficult is because the structure of the game means you have to make a lot of different changes across multiple files. For the advanced, this usually means some sort of patch file, for the beginner, hand-editing each file in the relevant places hoping to get it right. eg. In a Diku a typical change of significant complexity might involve adding some fields to CHAR_DATA, some commands into the command list, functions to implement those commands, any support functions that the commands call upon, maybe some calls within the main loop pulse system, etc. It's quite complex - in fact, it could be said that the complexity of installing such a change is dwarfed by the complexity of extracting that change from the code in the first place.

A more modular way of structing the mud code would help in this regard. Imagine a system where the characters and the game engine are each comprised of basic components. Your component would specify a new set of data for each character, any new commands, and any per-pulse update code necessary for it to work.

eg. (excuse the lame half C++/half C abomination)

class SpeechComponent
{
class PlayerSpeechData
{
bool speechTurnedOn;
};

// All components implement this
void addDataToPlayer(CHAR_DATA* ch)
{
ch->add_component_data("PlayerSpeechData", (void*)new PlayerSpeechData));
}

void do_say(CHAR_DATA* ch, char* arguments)
{
char* message = strcpy(arguments);
PlayerSpeechData* ourData = (PlayerSpeechData*)ch->get_component_data("PlayerSpeechData");
assert(ourData);
if (ourData->speechTurnedOn)
echo_to_room(ch->in_room, message);
else
send_to_char(ch, "You have speech turned off.");
}

// All components implement this
void registerCommands(CMD_TABLE* tbl)
{
tbl->addCommand(&do_say, "say");
}
};


A code file like this could just be dropped into any mud that supported the basic protocol for registering lumps of data and commands. Yeah, this is modular, but you'll notice it's not a thousand miles away from the capabilities of a stock Smaug or Rom. It just takes a little refactoring to set it up.
11 Aug, 2010, quixadhal wrote in the 9th comment:
Votes: 0
The problem with this is that everyone has their own idea of what a "standard" should be, and we all come from very different environments. The pseudo-code Kylotan posted would be all well and good for someone coming from a DikuMUD background, but it makes many assumptions about how things work that simply aren't true elsewhere.

Many LpMUD mudlibs don't use simple "commands", but have a verb system that uses standardized verbs and asks game objects if they support them. That is, the parser takes "open door", and calls the can_open() function in the "door" object in question, if true, it then calls do_open() in the same door object, if not it moves on to other matches for "door". This is backwards from the typical Diku, which makes the commands self-contained. do_open() is called with the argument door, and then the command itself pokes around to find the right door, having to do the checks inside the open command itself.

As it stands, you could probably say there are modular frameworks out there. Anyone using the LIMA mudlib as a base can probably share a good deal of code with other LIMA mudlib adopters. Likewise for Dead Souls, Discworld, etc. Their mudlibs provide a framework, and their drivers provide a common language. But, a battle axe coded on Dead Souls is unlikely to work on LIMA. DikuMUD is a step further down the food chain, as code from one Smaug MUD can't directly be used in another Smaug MUD unless they're both in lockstep, although a competant coder can generally work foreign snippets into their own codebase without TOO much effort.

What I'm trying to get at here is that you'd almost have to design your games from the ground up to support any real amount of modularity that's cross-compatible. If you were going to do that, especially in this age of splintered developer and player bases, you'd probably be better served just collaborting on the same game, IMHO anyways.
11 Aug, 2010, David Haley wrote in the 10th comment:
Votes: 0
I don't think people are proposing that the exact same code could be used to implement game logic equally on Dikus and LPMUDs and any conceivable MUD implementation. Clearly, any piece of code that needs to be aware of the rest of the framework (such as what a command even means) must be aware of at least a little of that framework.

But there is an awful lot of code that can be shared without any notion of the game framework whatsoever. Utility libraries like a bit-vector implementation in C can be used as-is by any C MUD.
11 Aug, 2010, Kylotan wrote in the 11th comment:
Votes: 0
quixadhal said:
The problem with this is that everyone has their own idea of what a "standard" should be, and we all come from very different environments. The pseudo-code Kylotan posted would be all well and good for someone coming from a DikuMUD background, but it makes many assumptions about how things work that simply aren't true elsewhere.

Of course. But I think it would be a positive step just to get better interaction between the various strands of Diku code.

I don't think we can come up with a complete modularity solution for text games in general. But if we come up with one that works for 40% of them, wouldn't that be a good start?

Quote
DikuMUD is a step further down the food chain, as code from one Smaug MUD can't directly be used in another Smaug MUD unless they're both in lockstep, although a competant coder can generally work foreign snippets into their own codebase without TOO much effort.

I used to spend a fair bit of time porting Rom, Rot, and Envy snippets to Smaug. Yeah, it's a bit awkward, but it doesn't require the whole game to be reworked. It's definitely the sort of thing a simple system like the one I described above would start to address.
11 Aug, 2010, quixadhal wrote in the 12th comment:
Votes: 0
A while back, I actually was proposing the idea of merging many of the Dikurivatives. Not merging their respective projects, but making a new derivative which would import and export data between the various formats well enough to become a rosetta stone. That is, while their interfaces are quite different, and their combat systems vary quite a bit as well, the underlying structures of Circle/Rom/Smaug/etc. are not all THAT different.

You'd still have to map custom code and flags on the way in and out, and anything outside of "stock" wouldn't be a 100% conversion, but it would give people a chance to switch codebases without having to lose/rewrite/convert their world data. While that won't directly buy you anything, it would make the Diku community a little closer knit since they could more easily share stuff.
11 Aug, 2010, JohnnyStarr wrote in the 13th comment:
Votes: 0
Would it be plausible to provide any MUD with some sort of service running parallel with the MudServer? Sort of like a web-service?
What if you had some sort of MudBox interpreter that you could access from any mud with the right configuration? Obviously if you
were using the same platform this would just be a package or DLL. If this MudBox so to speak provided string libraries, combat systems, and anything else.

This would allow multiple MUD bases to use resources across the board. The draw back might be the interface, that I'm not sure of.
At the end of the day, you probably would want to embed Lua or something similar.
11 Aug, 2010, Kylotan wrote in the 14th comment:
Votes: 0
JohnnyStarr said:
Would it be plausible to provide any MUD with some sort of service running parallel with the MudServer? Sort of like a web-service?

In the MMO world, there are engines that basically handle all the commands that don't require low latency via this sort of system. Chat, trade, quests… all easy to farm off to another server. Some of these can use 3rd party libraries. Of course, you still need to come up with or choose the protocols to communicate with them, and design the data structures that are going to be shared across the services. It's probably not worth the effort unless you need the extra scalability this confers. I'd say it's easier to start with in-process modularity because at least then you can easily break the rules in the cases where you need to.
11 Aug, 2010, Runter wrote in the 15th comment:
Votes: 0
Instance servers, etc. But the truth is this probably is complexity not useful for virtually any mud in existence.
11 Aug, 2010, Kylotan wrote in the 16th comment:
Votes: 0
Instance servers are pretty much a whole game server though; I was thinking more of processes that handle a much more limited set of commands. You're probably right that they're too complex for muds, but I think it's worth thinking about.
11 Aug, 2010, KaVir wrote in the 17th comment:
Votes: 0
Kylotan said:
In the MMO world, there are engines that basically handle all the commands that don't require low latency via this sort of system. Chat, trade, quests…

Might be interesting to have something like Intermud Chat as a standalone application that you can run on your server - have it connect to your mud as if it were a player, and track requests from other people in-game. This wouldn't be as nice as an integrated solution, but it would work out-of-the-box on any mud.

As an aside, I've released several codebase-independent snippets. You can't do everything this way, but quite a few features can be implemented and tested in isolation.
12 Aug, 2010, Scandum wrote in the 18th comment:
Votes: 0
KaVir said:
Might be interesting to have something like Intermud Chat as a standalone application that you can run on your server - have it connect to your mud as if it were a player, and track requests from other people in-game.

Could be done pretty transparently using MSDP, and in theory it wouldn't require the tracker to login, just connect and negotiate MSDP and a set of communication variables.

Not sure if this would be easier for MUDs to add than the current system in place.
12 Aug, 2010, Tyche wrote in the 19th comment:
Votes: 0
KaVir said:
Might be interesting to have something like Intermud Chat as a standalone application that you can run on your server - have it connect to your mud as if it were a player, and track requests from other people in-game. This wouldn't be as nice as an integrated solution, but it would work out-of-the-box on any mud.


I think Mudtape does something similar.
12 Aug, 2010, donky wrote in the 20th comment:
Votes: 0
David Haley said:
I don't think people are proposing that the exact same code could be used to implement game logic equally on Dikus and LPMUDs and any conceivable MUD implementation. Clearly, any piece of code that needs to be aware of the rest of the framework (such as what a command even means) must be aware of at least a little of that framework.

But there is an awful lot of code that can be shared without any notion of the game framework whatsoever. Utility libraries like a bit-vector implementation in C can be used as-is by any C MUD.

Indeed. There comes a point where the cost of standardisation or abstraction, is at the cost of the value of using the thing in question.
0.0/28