24 May, 2011, Mastermosley wrote in the 1st comment:
Votes: 0
I am in the process of programming a mud engine, and game from scratch using C# and Python. I already have an idea of what I want in it, but I don't want my mud engine to be another generic base. I no most of the people in this community are programmers, builders ect, and have a lot more experience in this field then I do. What kind of features would you expect to see from a modern mud? And if you have any other suggestions please feel free to throw that in as well.

Thanks a lot.
24 May, 2011, Igabod wrote in the 2nd comment:
Votes: 0
try giving us some more parameters to work with. what genera are you thinking of? Level or level-less? just a few details is all that we need and I'm sure you'll be overwhelmed with responses.
24 May, 2011, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
Mastermosley said:
I don't want my mud engine to be another generic base.

Make it too specific and you will be limiting yourself in the end.
You need a very strong framework before you can add specific stuff.
It is better to code most of the fun in the skills code than in the engine, it allows way more freedom.
Engine should be limited to:can two entities can fight, what happen when one die, can he move, generic update etc.
Everything specific in the engine should start by an if, and should be removable without breaking it.

Now what I expect from a mud as a bare minimum is:
-not piss me off by having to do stuff myself like sheating weapons at the end of fight or drawing them when a fight start. Every obvious action should be automatically done, because if I have to code triggers for every annoyance like this, I wil go elsewhere as it does not add anything interesting to the game.
-no 'spoken rules'. If I can do it in the game, it is legal. If I should not, fix it.
-limit grinding to the bare minimum. If I dont want to level and level and level there should still be a way to compete. (use whatever penalties you want to compensate)

The rest really is up to you.
24 May, 2011, plamzi wrote in the 4th comment:
Votes: 0
@Mastermosley

I believe that "a modern MUD" has to be able to run in a browser easily. A WebSockets communication layer would be great, thinking ahead to the time when all major browsers will support it. Some kind of easy HTML markup utility set to go with it would also be great.

As far as I'm concerned, all stored data has to be in a database. It can be a flat file database, but it has to be query-able and it has to allow you to modify individual records. Everything else, even xml, is dated. The database should also contain any info, such as class perks, skill trees, messages, etc. The more info you can abstract from the code into the database, the better.

A set of content creation tools (equivalent of OLC) that also run in a browser would be awesome. A 'modern MUD' has to make it very easy for devs, builders, and players, to contribute content. The success of a modern codebase could very well hinge upon how easy it is to add content - it should be trivial to build zones, and only a bit harder to script entities. If you can expose balancing tables, skill trees, etc. (all in the database) to these content-building tools then that's even better - even devs want things to be easier in 2011 than they were fifteen years ago.

A built-in advanced-client protocol and built-in data compression support (that can be switched on/off) would be great. The client protocol doesn't have to be an existing one but it should allow for easy, standardized client development, including visualizing maps/char location, etc. If you don't think you're up to the challenge of developing easy-to-use content creation tools, then the client protocol could include a standard for communicating with content creation functions so that other people can develop such tools.

@Rarva
I believe the OP was asking about codebase and not gameplay features. We all have a list of pet peeves that "we can't possibly stomach" in gameplay. It's important to remember that those lists are highly subjective. It's also important to remember that our pet peeves are based on the MUD we have finally chosen for ourselves, which also makes them highly relative. For instance, I hate sheathing my weapon if it means nothing but I can imagine a world where it has a profound effect (e. g. stops cityguards from attacking me, allows me to sneak into a place, etc). The bottom line is, there are no bad features, only bad implementations.
24 May, 2011, KaVir wrote in the 5th comment:
Votes: 0
plamzi said:
The bottom line is, there are no bad features, only bad implementations.

Oy, that's my line! :P

I provide 'draw' and 'sheathe' commands to let players switch weapons during combat. Not had any complaints about it.
24 May, 2011, Rarva.Riendf wrote in the 6th comment:
Votes: 0
Quote
I provide 'draw' and 'sheathe' commands to let players switch weapons during combat. Not had any complaints about it.

I provide switch….
24 May, 2011, Rarva.Riendf wrote in the 7th comment:
Votes: 0
Quote
For instance, I hate sheathing my weapon if it means nothing but I can imagine a world where it has a profound effect (e. g. stops cityguards from attacking me, allows me to sneak into a place, etc). The bottom line is, there are no bad features, only bad implementations.

Then make a config flag that allow automatic sheating of weapons at the end of fight. Up to the player to activate it or not.
Unless you control the client and you are sure that people can do triggers themselves, do not rely on the player to be able to automatize this.
If they cannot automatize these kind of annoyance, I doubt they stay. (I would not…)

Code wise I agree with what you say, content creation must be easy for coder, buidler, and player.
A very simple test is to build..if you have to read your code to know how to edit something when you know the value you want to insert…it probably means it is coded wrong.
24 May, 2011, KaVir wrote in the 8th comment:
Votes: 0
Rarva.Riendf said:
Quote
I provide 'draw' and 'sheathe' commands to let players switch weapons during combat. Not had any complaints about it.

I provide switch….

To switch between weapon sets?

What if someone just wants to sheathe one of their weapons but continue using the other? Or what if they want to sheathe both weapons and fight unarmed for a while?
24 May, 2011, quixadhal wrote in the 9th comment:
Votes: 0
Features in a moderm MUD engine… Hmmm…

1. Dynamic coding for all in-game objects/systems. I'm thinking like an LpMUD here, one should be able to change almost any game-related system without having to reboot/recompile/kick players off.
2. Decoupled presentation/data layers. By that, I mean the game itself shouldn't make assumptions about connection type or how the data ends up being presented to the end user. If I'm connecting via crufty old TELNET, I need a stream of text with color tags embedded. If I'm using a fancier client, maybe I want tags by purpose, so I can do the coloring/sizing/placement on my end. If I'm using a really modern client, I want everything packaged in something like JSON, so presentation is entirely done on the client end.
3. Sane licensing which doesn't require me to beat round the bush to accept donations or make a buck, but which also doesn't limit me from keeping parts of my content private and unavailable. Of course, credit should be given where it's due.
4. Documentation! I'd really like to know exactly what everything in the driver API does, what it expects, and how it can be used. A way to modify or expand the driver itself should also be documented, so nobody needs to stumble upon hidden landmines.

All the other stuff is game-specific, so I'm not going to comment on it. IMO, that stuff shouldn't be part of the driver anyways.
24 May, 2011, Kline wrote in the 10th comment:
Votes: 0
quixadhal said:
3. Sane licensing which doesn't require me to beat round the bush to accept donations or make a buck, but which also doesn't limit me from keeping parts of my content private and unavailable. Of course, credit should be given where it's due.


Not saying that it would be a bad thing to "roll your own" license wise, but perhaps utilizing one of the more popular, less ambiguous, and "been fully debated" licences would be nice. Please don't create an awesome stock base that ends up gaining traction to the point of Diku/Merc and then (still, to this day!) has licensing debates about "what you really meant."
24 May, 2011, Mastermosley wrote in the 11th comment:
Votes: 0
Quote
1. Dynamic coding for all in-game objects/systems. I'm thinking like an LpMUD here, one should be able to change almost any game-related system without having to reboot/recompile/kick players off.


I am integrating my app with IronPython for all in-game objects/systems which uses .NET's DLR

Quote
2. Decoupled presentation/data layers. By that, I mean the game itself shouldn't make assumptions about connection type or how the data ends up being presented to the end user. If I'm connecting via crufty old TELNET, I need a stream of text with color tags embedded. If I'm using a fancier client, maybe I want tags by purpose, so I can do the coloring/sizing/placement on my end. If I'm using a really modern client, I want everything packaged in something like JSON, so presentation is entirely done on the client end.


Definitely agree with this. The system should not care which protocol it is using after that layer of abstraction and I plan on that. Making it easier to add future protocols as well. So far my app has support for the old stock windows/linux ansi/nonansi clients (that support echo). As well as 256 Color Xterm in the newer clients. I am planning on adding MXP support as well.

Quote
3. Sane licensing which doesn't require me to beat round the bush to accept donations or make a buck, but which also doesn't limit me from keeping parts of my content private and unavailable. Of course, credit should be given where it's due.


I really have no idea about licensing or any legal issues, I'll have to look into that. This is all a learning experience for me so I really won't care how people use it as long as they don't download the source, change the name and re-release it.

Quote
4. Documentation! I'd really like to know exactly what everything in the driver API does, what it expects, and how it can be used. A way to modify or expand the driver itself should also be documented, so nobody needs to stumble upon hidden landmines.


I am commenting the SH*T out of everything right now but I will definitely get around to documentation when need be.

Everyone else I like the comments, and appreciate them so please keep on with the suggestions.

Cheers
24 May, 2011, quixadhal wrote in the 12th comment:
Votes: 0
There are plenty of open source licenses out there. My personal preference is the BSD license, as it keeps things simple and doesn't impose any real limitations on either the user or developer. The GPL is popular as well, but it has a few points that make it difficult to use with already existing code that is NOT GPL.

At the end of the day, it's your project so use whatever you feel comfortable with. :)
24 May, 2011, Mastermosley wrote in the 13th comment:
Votes: 0
quixadhal said:
There are plenty of open source licenses out there. My personal preference is the BSD license, as it keeps things simple and doesn't impose any real limitations on either the user or developer. The GPL is popular as well, but it has a few points that make it difficult to use with already existing code that is NOT GPL.

At the end of the day, it's your project so use whatever you feel comfortable with. :)


Thanks, I will look into those.
24 May, 2011, Runter wrote in the 14th comment:
Votes: 0
I typically use the MIT license.
25 May, 2011, Rarva.Riendf wrote in the 15th comment:
Votes: 0
Quote
What if someone just wants to sheathe one of their weapons but continue using the other? Or what if they want to sheathe both weapons and fight unarmed for a while?

That is called remove/unequip/whatever…no need for another specific command…. switch is to put main hand in offhand, and vice versa, works with one or two weapon.
anyway…that was not the subject..seems like it was about code the internal workings, not about what a player expect.

Oh and +1 for bsd license..the only one that is headache free.
25 May, 2011, KaVir wrote in the 16th comment:
Votes: 0
Rarva.Riendf said:
That is called remove/unequip/whatever…no need for another specific command….

Ah, well that's one of my pet hates - allowing players to freely wear and remove equipment during combat.

Rarva.Riendf said:
switch is to put main hand in offhand, and vice versa, works with one or two weapon.

Oh I have that too. Doesn't address the wearing/removing issue though.

Rarva.Riendf said:
anyway…that was not the subject..

The original poster has said he's interested in basic command structure and a combat system, so this will be something he'll be dealing with. However more importantly than that, it serves as an example of what plamzi mentioned earlier - pet peeves are highly subjective. What you "expect from a mud as a bare minimum" might be a deal-breaker that causes someone else to turn the game down flat, and vice versa.
25 May, 2011, donky wrote in the 17th comment:
Votes: 0
I would expect a fully 3D world, approximated into a text interface. Physics and other procedural content and behaviours. Accessible via a web interface that does not suffer from the hit backspace and get logged out problem. Marked up with maps and links and other ease of play mechanics that do not detract from the text as imagination facilitation thingamy that makes MUDs special in everyone's eyes except quixadhal's ;-)
25 May, 2011, Runter wrote in the 18th comment:
Votes: 0
A web interface preventing the backspace, or even the back button, from functioning in a way that's unappealing is actually pretty simple.
25 May, 2011, Rarva.Riendf wrote in the 19th comment:
Votes: 0
Quote
pet hates - allowing players to freely wear and remove equipment during combat.

Unrelated, that are gameplay choices, not convenience for the player. They cannot remove their armor during fights either in my mud.

Quote
'would expect a fully 3D world, ……ease of play mechanics that do not detract from the text as imagination facilitation

That seems completely impossible, either you have text leaving you imaginate how it looks, or a picture…cannot have both.
25 May, 2011, KaVir wrote in the 20th comment:
Votes: 0
Rarva.Riendf said:
Quote
pet hates - allowing players to freely wear and remove equipment during combat.

Unrelated, that are gameplay choices, not convenience for the player.

It's absolutely related to the subject of drawing/sheathing. I allow players to draw and sheathe weapons during combat, but not wear and remove equipment. This is indeed more convenient for the player, as it provides a clear indication of which items are available for use during a fight, and a clear set of commands for accessing those items.

Rarva.Riendf said:
Quote
'would expect a fully 3D world, ……ease of play mechanics that do not detract from the text as imagination facilitation

That seems completely impossible, either you have text leaving you imaginate how it looks, or a picture…cannot have both.

He didn't say anything about pictures. In fact, he explicitly said "I would expect a fully 3D world, approximated into a text interface."

Having said that, there's absolutely no reason why you can't combine graphics and text.
0.0/80