15 Oct, 2012, khyldes wrote in the 21st comment:
Votes: 0
Biggest issue I see with bare bones codebases is that you're not going to attract a lot of attention when they feature list is so sparse. The majority of people looking to start a mud are former players, with limited coding experience that hope to learn as they go. That requires a platform that is feature rich. No matter how much you tell people that they can 'code' anything, they're more likely to turn to a base that gives them options to modify and add to, rather then have to worry about creating every single last detail.
16 Oct, 2012, arendjr wrote in the 22nd comment:
Votes: 0
Heh, I can understand that. Please understand that the current lack of features is not a deliberate design goal, but simply a product of the project's youth; I started it a little over 6 months ago. Still, I believe it's a rather impressive base for a MUD, given its age.

Current features:
- Multi-threaded design
- Scripting support using JavaScript
- Logging of sessions (including IPs) and player commands
- Statistics tracking
- Support for both telnet (including MCCP) and HTML5 (WebSockets)
- Graphical HTML5 room builder, with perspective view for designing 3D areas
- Basic MUD commands
- Scriptable NPCs
- Very basic combat
- Group support

Yesterday I started working on container items (still very basic gameplay material, I know), but my short to medium term plans include:
- Generic terrain generation
- Rolemaster-style combat
- Line of sight algorithms (seeing someone from another room)
- Crafting

All this I hope to do without compromising the lean design, maintaining the flexibility and extensibility. I don't want people saying a year from now I got a very nice engine, but there's so much cruft they have to remove first before it's useable :)

Cheers!
Arend jr.
16 Oct, 2012, quixadhal wrote in the 23rd comment:
Votes: 0
At the risk of tossing out a "wish list", but since you mentioned terrain…

One of the things I've wanted to do for a while now, is to have zones of the game world be generated either by algorithm, or by reading in one (or more) graphical files to use as terrain data. However, I want hand-edited rooms to override the "automatic" rooms. Let me use an LPMUD as an example.

Suppose you have a virtual room system, and some player attempts to walk into /domain/swamp/rooms/12,36,0.c. If a file of that pathname exists, the MUD will simply compile/load it and follow the usual rules. If no file exists, the virtual system will use some domain-specific generator (maybe loading a pixel from several graphic images, maybe running code), that will return a virtual room appropriate for that coordinate in /domain/swamp.

The benefit of doing it that way is you can map out your world in general types of terrain/climate (per domain), and wander around until you find somewhere that looks good to build, and then start hand-editing rooms to replace the "auto" rooms. Of course, it's up to you to keep the coordinate system sane, so if you want to plant a city at 12,36,0, and you make it 500 rooms wide, the other edge should be appropriate for the distance involved.

Obviously, your system doesn't work the same way, but I encourage you to keep the idea of a seamless auto-generated terrain that can be overridden by hand-editing.

As for the other things you mentioned… I haven't looked at your codebase in any detail yet, but the more things you can push into javascript rather than embedding them in the driver, the simpler it is to change on the fly. One of the reasons I advocate the use of LPMUD is that flexibility.

Example: In some old Dikurivatives, there exist a mini-scripting system called "mobprogs". It's basically a large set of simple statements to do various things in the event certain triggers fire. It seems pretty useful, until you decide you want something to happen that isn't already a trigger invoked by the driver. So, I decide I want to code orcs to roar and attack whenever an NPC runs up and licks them. The problem is, there are no triggers to hook into for emotes performed by NPC's, so I have to dig through the driver source and thread a new set of trigger events, modifying the "mobprog" langauge parser to add new tokens, etc, etc.

In an LPMUD, all game logic is at the mudlib level (in the scripting language), so you only need find how your mudlib handles emotes in general… and code your NPC to react. In some, an event is called in the player/npc objects like eventEmote(), which will specify the data and what object is doing it. In others, no event code exists, but you can have your NPC's watch the output of other things and parse for the expected text. The point being, the guy coding the new behavior into the orcs doesn't need to modify the driver *OR* the core mudlib code… he only needs to figure out how to recognize the thing happening and react to it.

That probably isn't possible in your design, but a good goal is to allow the scripting langauge to do as much as you can, and make the code to add/react to triggers as clean as possible.
16 Oct, 2012, arendjr wrote in the 24th comment:
Votes: 0
Quote
One of the things I've wanted to do for a while now, is to have zones of the game world be generated either by algorithm, or by reading in one (or more) graphical files to use as terrain data. However, I want hand-edited rooms to override the "automatic" rooms.


Spot on! That's exactly the kind of thing I want to do.

I found the L3DT (unfortunately Windows-only) is quite apt at generating height maps and seas and lakes and stuff. Those I want to import by automatically creating rooms on the X, Y, Z positions in the height map and then decorating them using generic, but varying descriptions that are applicable to the location. Some extra work will be in marking areas as swamp/desert/forest and mapping roads and such. The line of sight algorithms also plug in at this point, by calculating which rooms are visible from others. Once generated, the builders can go in and do the customizations they want, build villages, cities and whatever artifacts they want in the terrain. I think this is definitely doable, but I will need to do a bit more research before I will actually start implementing this. So if anyone has more suggestions regarding this, please speak up! :)

Quote
[…] the more things you can push into javascript rather than embedding them in the driver, the simpler it is to change on the fly


Yes, this is also the approach I've taken with the current combat system, and which I want to use wherever it makes sense.

Quote
Example: In some old Dikurivatives, there exist a mini-scripting system called "mobprogs". It's basically a large set of simple statements to do various things in the event certain triggers fire. It seems pretty useful, until you decide you want something to happen that isn't already a trigger invoked by the driver. So, I decide I want to code orcs to roar and attack whenever an NPC runs up and licks them. The problem is, there are no triggers to hook into for emotes performed by NPC's, so I have to dig through the driver source and thread a new set of trigger events, modifying the "mobprog" langauge parser to add new tokens, etc, etc.


Yup, that's pretty much how my trigger system works as well. But…

Quote
In an LPMUD, all game logic is at the mudlib level (in the scripting language), so you only need find how your mudlib handles emotes in general… and code your NPC to react. In some, an event is called in the player/npc objects like eventEmote(), which will specify the data and what object is doing it. In others, no event code exists, but you can have your NPC's watch the output of other things and parse for the expected text. The point being, the guy coding the new behavior into the orcs doesn't need to modify the driver *OR* the core mudlib code… he only needs to figure out how to recognize the thing happening and react to it.


While I cannot claim that all game logic is in JavaScript, increasingly large parts are, and I expect to continue along that path. The earlier mentioned triggers can also be triggered from other JavaScript code, and introducing a new trigger is as simple as thinking up a unique name for it. So customization should really be very easy there.

In addition, I have a generic "send" method that is defined on every game object and which is used for sending text output to it. The only objects that actually do something useful with this output are Player (which sends it to the output of the current user's session, if there is one) and Group (which delegates it to all players in the group). But if necessary, NPCs could indeed parse (or simply scan) all text sent to them to achieve the same result as you're describing.

Now in truth, in the current design I actually skip sending text to objects I know not be players in many cases, as I do not really expect NPCs to respond to it. But I think your suggestion here makes sense and for sure the current design would allow such flexibility.

Cheers!
Arend jr.
18 Oct, 2012, Nathan wrote in the 25th comment:
Votes: 0
Nifty notion there, why not just generate the world based on something and then edit it. Sort of Minecraft style. That way you can avoid worrying about wilderness specifics and focus on cities and roads. Really nice if you could have a picture of your world drawn up and then just plop that in. Now you have the whole world in minus people and civilization. Just put cities and roads where you want them.
18 Oct, 2012, Nathan wrote in the 26th comment:
Votes: 0
Qqwy said:


Indeed, the main criteria I was referring to was your point 6: currently active and being maintaned.
Another critera was that it should be easy to change how things work around. That means:
-No codebases which implement their own obscure scripting language.
-The more high-level the code the better.
-Newer means that some things where a few years ago we only saw one possibility, now has many more possibilities.


I've looked in CoffeeMUD for a few days now, and the main problem I'm having with it is that it seems that there is so much implemented already, that it gets very hard to 'remove' parts(without breaking things) and change them with your own.

Davion, I want to thank you for noting Everia. That looks like a very interesting project, and I'll give it a go.

Thank you all for your comments!

~Qqwy


Any scripting language is somewhat obscure until you know it. Quality of documentation is crucial and good naming conventions in the code don't hurt. High level, as in object-oriented vs. functional? I would think that the documentation (in code) and outside is what determines how understandable it, not whether it's high-level or not (even if that helps).

In terms of up-to-dateness, I think it's very important whether or not someone maintains/uses it anymore, since getting help from someone who knows will be easier than figuring it yourself most of the time. So I agree with 6. An abandoned codebase or badly documented one will present more problems than one that is merely old. Better to have known limits than bugs everywhere.
18 Oct, 2012, quixadhal wrote in the 27th comment:
Votes: 0
Nathan said:
Nifty notion there, why not just generate the world based on something and then edit it. Sort of Minecraft style. That way you can avoid worrying about wilderness specifics and focus on cities and roads. Really nice if you could have a picture of your world drawn up and then just plop that in. Now you have the whole world in minus people and civilization. Just put cities and roads where you want them.


That's certainly one way to do it. An advantage of procedurally generated worlds is that you don't need to waste disk/memory space on parts of the world that have never been visited yet. Another is that you can modify the procedure as you go, so new parts of the world might be different than existing parts, and might vary based on which direction you go, or how far.

It's interesting that you use Minecraft as an example, as that *IS* fully generated at run time, and not created ahead of time. The only thing you do when you "make" a new world in Minecraft is pick a random seed value and then pre-generate the first X chunks around the origin, so there's no delay when entering the game and exploring right around the spawn point.

Minecraft's world generation algorithm would be (IMHO) perfectly suitable for generating the wilderness area of a MUD. The only difficulty there is generating text descriptions from that kind of spatial data.

For the sake of amusement, let's pretend you define a wilderness room as a chunk of 20x20 minecraft blocks. We'll assume surface level and ignore height beyond the slope of the surroundings. How would you turn said chunks into text descriptions?

First, obviously, is figuring out the average terrain/vegatation/climate of the chunk you're standing on. Are there more than N trees? Does the slope change gradually? Sharply? From N->S or E->W? Then look at the chunks around you and figure out how to merge that data in.

Now… how far out do you want to look for exceptional features? If you're standing on a hillside, you might be able to see quite a ways off and a large mountain or lake would be worth noting.

Finally, has anyone considered actually parsing the minecraft world data files? Having minecraft as a visualization system for your MUD would be kinda neat… Of course, hand-edited descriptions wouldn't show up, and unless you let your MUD write back into the data files, the game edges would be however far you've explored in minecraft… but it would be pretty neat to be able to share between the two.
19 Oct, 2012, Barrons wrote in the 28th comment:
Votes: 0
After reading this thread – and making my initial response – I have wanted to toss something else out there but keep finding myself without the time to make a nice post. So, here I am on lunch at work, and deciding to finally put my two-cents in.. That's my caveat for the complete lack of structure to the following post.

(In no particular order) things I consider qualify a MUD as being "Up to date":

garbage collection, runtime reflection, concurrency, (generative programming) higher levels of modularization, component based software and domain-specific languages, template metaprogramming, database integration (and with modularization, interfaces to multiple types of databases) and here is something I would really like to see…

Technical documentation

I am toying with the idea of developing a MUD where the primary goal is to have an in-depth, technical documentation of the code. The idea is that aspiring programmers, MUD developers, and other poor souls would be able to grab the code, run it, look at the code, and never have to guess what something does, or go to a forum to ask. Why was function foo () written that way instead of this way? Is this component really faster/less-expensive(overhead wise)/more optimized than if I did it this way? Oh look, in the technical documentation, there are already alternatives provided with benchmarks so I don't have to wonder.

I have a couple terrabytes of solid-state memory in my home systems. Where, in times past, things were written to avoid expensive read/writes to hard-discs, we could now refactor code to take advantage of newer hardware technologies. I can't think of a good example off the top of my head, but when I do, I'll post that too.
20 Oct, 2012, Nathan wrote in the 29th comment:
Votes: 0
Would you mind defining loosely what you mean by those qualifiers for up-to-dateness? Maybe you could provide simple examples of what kinds of things you think would meet those criteria? I'm not sure exactly what you mean.

I'm not sure that's a hundred percent possible. How much and what kind of documentation would be sufficient, in your opinion? As interesting as it would be to see documents considering alternatives to solutions chosen, seems like those would be hard to write while doing the code since you have to make decisions which lead to other decisions as you code. How do you get the code down if you are documenting a chunk of the alternative choices at each step?!

You might want to look at the circle mud documentation, that for dead souls (lpc mudlib) and the like, addressing any deficiencies you think exist in them.
24 Oct, 2012, Qqwy wrote in the 30th comment:
Votes: 0
Nathan said:
Would you mind defining loosely what you mean by those qualifiers for up-to-dateness? Maybe you could provide simple examples of what kinds of things you think would meet those criteria? I'm not sure exactly what you mean.

I'm not sure that's a hundred percent possible. How much and what kind of documentation would be sufficient, in your opinion? As interesting as it would be to see documents considering alternatives to solutions chosen, seems like those would be hard to write while doing the code since you have to make decisions which lead to other decisions as you code. How do you get the code down if you are documenting a chunk of the alternative choices at each step?!

You might want to look at the circle mud documentation, that for dead souls (lpc mudlib) and the like, addressing any deficiencies you think exist in them.


Hmm… Right now I'm trying out stuff with Evennia, because it seems to fit my criteria quite nicely.

To loosely define them a bit more:

-No codebases which implement their own obscure scripting language.
There has been some discussion about this. Basically, it means that I like using some broadly-used language over a scripting language that is created specially for this certain program, for two reasons:
a)Albeit it might be 'easy', it takes time to learn, is often badly documented and when you can write in that scripting language, you cannot use that knowledge to program anything else.
b)Because it's created for one single purpose only, it's often inflexible to do things not directly thought of by the original creator. If it isn't outrightly impossible.

-The more high-level the code the better.
High level coded languages usually have a smaller 'overhead' of code. You can get straight to the point of defining what you want. Of course, this is kind of my personal opinion. Also, I 've had more experience with high-level languages before (Java, PHP, Ruby).

-Newer means that some things where a few years ago we only saw one possibility, now has many more possibilities.
This has kind of a confusing wording… I was very tired when I wrote that. Basically I like engines that are 'bare bones' without too much 'pre-defined' structures over codebases that are already ten years old and, for instance, only support one kind of attack system that you'll have to suit yourself to, or risk to reprogram big parts of the engine.
03 Nov, 2012, Kelvin wrote in the 31st comment:
Votes: 0
I may be biased, as I was the original Evennia developer, but the current maintainer (Griatch) is doing a fantastic job with it. I can't recommend it enough, if you like or think you may like Python. Stop by #evennia on FreeNode IRC if you haven't already.

The best feature: Documentation

The landing page might look sparse, but click around and I think you'll find things very well documented. If not, file a bug on there and Griatch will crank out more for you.
03 Nov, 2012, quixadhal wrote in the 32nd comment:
Votes: 0
Qqwy said:
-No codebases which implement their own obscure scripting language.
There has been some discussion about this. Basically, it means that I like using some broadly-used language over a scripting language that is created specially for this certain program, for two reasons:
a)Albeit it might be 'easy', it takes time to learn, is often badly documented and when you can write in that scripting language, you cannot use that knowledge to program anything else.


Just because this bugs me, let me say that I think this is a non-point.

Every language you've ever heard of has been an "obscure" language at one point or another. Every language that's considered mainstream now will become "obscure" eventually. When I was in college, C was something the geeks used, C++ was unheard of, the Computer Science program used Pascal in general, and pushed FORTRAN and COBOL for engineering and business applications.

How "limiting" the "single-purpose" language is depends entirely on what level of events the driver exposes to the mudlib. In a Dikurivative, where the scripting language is a set of simple scripts that run when various in-game events fire, it's very limited. In an LP Mud, where the events that fire are at the level of "sockect connect" or "input received on socket", there's not much limitation there. I highly doubt Lars designed LPC to allow you to code web servers and use SQL databases with it, yet both have been done without having to modify the game driver itself.

As for they myth about learning a real language so you can use it elsewhere… it doesn't matter. First, you'll be learning new stuff at any job, and learning a complex toolkit is much harder than learning a new programming language. Second, any scripting language you'd pick is not goign to help you unless you happen to fall into a specialized role that uses it. I know. I have 6 years of solid Perl experience sitting on my resume that does me NO good at all, because Perl isn't a mainstream language… even though it's very widely used. It's a specialists tool, and Ruby/Python/Lua/whatever are in the same boat. They're great languages, but unless you get lucky and find a startup that really wants to use them, don't pretend learning them will help you elsewhere.
03 Nov, 2012, donky wrote in the 33rd comment:
Votes: 0
quixadhal said:
Qqwy said:
-No codebases which implement their own obscure scripting language.
There has been some discussion about this. Basically, it means that I like using some broadly-used language over a scripting language that is created specially for this certain program, for two reasons:
a)Albeit it might be 'easy', it takes time to learn, is often badly documented and when you can write in that scripting language, you cannot use that knowledge to program anything else.


Just because this bugs me, let me say that I think this is a non-point.
For the reasons given perhaps, but I think in general it is a worthwhile point to pay attention to when choosing a code base.

If a code base uses a non-obscure scripting language, you can have a fair idea of its capabilities and limitations. You can likely find solutions to problems encountered using it, in posts unrelated to the code base via search engine. If it is a custom scripting language, then you might not realise a limitation or problem until much later on when you have invested time in it. The burden is on you to extend it, or fix any problems with it. And if the code base is still being developed and you are hoping to ameliorate your own need to work on the language by merging in updates, you have to either accept wacky custom modifications or fork and increase maintenance burden.

A non-obscure scripting language is a safer bet, and is a good sign you can disregard that aspect of a code base as a potential time waster or risk.
04 Nov, 2012, quixadhal wrote in the 34th comment:
Votes: 0
Sorry, but I totally disagree. Using a "well known" scripting language in no way gives you any clue about the limitations or capabilities of your codebase. There are numerous examples of people who have pushed Lua and Ruby interpreters into a Dikurivative, because they didn't like the mobprogram system they had… and they STILL rely on the same driver-produced hooks to trigger the new scripts. They STILL can't do anything you could code in the scripting language unless they expose 100% of the C dataspace to the script engine. If you do that, so much for any security you might have had.

A system that was designed, from the ground up, to have a scripting language (obscure or not), will have taken the time to work out security issues, and have protection from any one script overrunning the CPU, or eating up all the machine's memory, or just having a plain old while(1); loop.

As for wasting your time…. anyone outside this community would say you're automatically wasting your time by working on a MUD in the first place. I don't think entertainment is a waste of time.. if you enjoy doing it, you're getting the enjoyment as a return on the time invested. If you don't, then find some other way to spend your time. :)

Just as a final thought…. if you REALLY want a MUD that's been designed to be fully extendable in script, that has a large community to help you, and that isn't considered "obscure" by THIS community… LP MUD is the obvious choice. It's not easy. You won't be using your mad LPC skills anywhere else. But, there are still plenty of them out there running… they're all different… and despite that, knowing LPC on one lets you at least work on another without having to totally forget everything you did before. If you can show me a codebase that uses Python/Ruby/Perl/etc at as low a level as LPC, I'll suggest using that if you just can't stand the idea of using a tool specifically designed for the task at hand.

Personally, I hate flat-head screws. Phillips are a little better, but they still tend to strip too easily and then you dig out the flat-head driver to force them to turn. Hex-head screws work really well, don't strip easily, and hex drivers don't sliip… but you can't as easily just whip out the old flat-head driver to turn them. You need the right size to fit the screw.
05 Nov, 2012, arendjr wrote in the 35th comment:
Votes: 0
I don't think donky was arguing what you think he was arguing :)

Quote
Quote
If a code base uses a non-obscure scripting language, you can have a fair idea of its capabilities and limitations.

Using a "well known" scripting language in no way gives you any clue about the limitations or capabilities of your codebase.


No, but it does give an idea about the capabilities and capabilities of the scripting language. Designing languages is hard, and inventing your own one is going to bite you 99% of the cases, even if it is better in some regards and does have some advantages for the specific case at hand.

No matter what language you're using (be it an established one, an obscure one, or even your own homebrew), at some point you're going to have to work around its quirks. And at this point it becomes an advantage if you can search StackOverflow or Google, or even draw from past experience when you have to find a solution to some language limitation.

You're pulling a strawman when it comes to time wasting. It doesn't matter what other people think is a waste of time, but if I want to create a MUD game, but instead spend time figuring out some obscurity of its scripting language, then I would consider that time wasted.

I'm not going to argue against LPC, as many games use it, and people get stuff done with it, so it must be a capable language. But it would be silly to just disregard the appeal of other languages to those already well-versed in those languages. You seem to want to disregard Python and Ruby as specialists tools, but if so, then there are an aweful lot of those specialists out there, and it definitely isn't confined to a few hipster upstarts. Personally I use JavaScript as a scripting language in my engine, I hope you're not going to argue that JavaScript is a specialists tool too? If I got a load of experience with JavaScript, got a lot of code written in JavaScript – totally unrelated to MUDs, but some of which might still be reused anyway – then who's to tell me I'm using the wrong tool for the job by using JavaScript? Not to mention I'm writing frontend code too, and I'm naturally using JavaScript for that. So I need to know JavaScript anyway, would I really be better off learning yet another language for the server-side MUD code, with no ability to share code between frontend and backend?

I may be diverting a little bit from Qqwy's original argument, but I can understand his preference perfectly well, and I wouldn't consider it a non-point at all :)

PS.: Booking.com is really fond of Perl programmers ;)
05 Nov, 2012, quixadhal wrote in the 36th comment:
Votes: 0
Hmmmm, how to phrase this… I'm not so much arguing for or against any particular langauge (obscure or not), but I'm instead saying the language choice doesn't really matter much. Any experience programmer can pick up a new language without much trouble, and an inexperienced one will have the same problems in any language, regardless of how well known it is.

I don't think the language is usually the thing people have trouble with, when learning any new system. The API of the toolkit is usually much more involved and specialized, and that's the part you need to know to get stuff done. Sure, you can google for how to do a foreach loop in python/perl/etc much easier than LPC/Cool/MOBprogs, but how often do you DO that?

OTOH, as a simple example, let's say I want to code a necromancer NPC who wanders the lands, looking for corpses to reanimate, and once he has a large enough army of undead followers, he will open a portal to town and launch an assault. So, the reanimated followers need to be passive while he's building the army, and then aggressive once they are sent to town.

So, some things you need to know to code that in any given MUD….

How do you find specific types of objects?
How do you navigate to them?
I'll assume you already have a "raise dead" spell whose code can be used.
How do you set them to follow you and be passive or defensive?
I'll also assume code for a portal/teleport is easy to find.
How do you then reset them to be aggressive?

None of these things depend on the language used, but they all depend on the API exposed and/or methods inherited.

I submit that figuring out how to use find_object (in LPC), traverse the object list (in a DikuMUD), or whatever else a different MUD type would need, is going to be dependent on how well documented your particular chosen codebase is, AND how active of a community there is already using it. Google wont' help much. Neither will knowing C (in the case of a DikuMUD). Knowing LPC would only help if your particular mudlib experience has the same find_object API as the one you're using now. I don't think switching in perl or javascript or anything else will change that picture.
06 Nov, 2012, Shaitan wrote in the 37th comment:
Votes: 0
arendjr your mud looks like it has some MajorMUD influence in your color scheme. You also mentioned that you're going to have Rolemaster-like combat.

I just thought that was cool because I'm working on a mud in Ruby / Rails that is more or less a marriage of my two favorite muds: MajorMUD, and Darkemud (which uses a Rolemaster-like critical hit system in its combat).
20.0/37