I would consider an unmappable world not as complicated, but incoherent.

I think there's nothing wrong with doing something just to learn. But the road is long without companions. And why a MUD server? If you build a server specifically for a mobile or web-based game, you could not only learn stuff that makes you more marketable (speaking from experience), but you may also find adopters and players for it.

It's a natural progression which the graphical games are moving toward. Of course you'd need a simplified model for text.


VT100 interfaces have been around for two decades, and they have little added value other than giving players who use the interface an advantage, forcing other players to use them in order to compete. There may be some utility to it in highly detailed games, but that may lead to the IRE fiasco where too many small decisions result in heavy scripting.


If someone wrote a decent physics engine with a good dynamic description generator and a usable OLC engine it would be revolutionary enough to draw widespread attention.


You can navigate most muds without having to read the room description. I'm talking about a Prince of Persia SoT like world, in text, a simple map wouldn't suffice for navigation. Your average MUD rendered in 3d would look horribly dull.

Actually I doubt most players would even notice - I've been using generated dynamic descriptions for well over a decade, and while a few other mud developers have shown a passing interest (and a few builders have flamed me), the players don't seem to care. They're far more interested in the gameplay, I don't think most of them even read the descriptions.

I also simulate a few of the things you might expect from a simplified physics engine, and while a handful of players have said they think it's cool, they seem to view it as polish and attention to detail rather than a main selling point of the mud. It rarely gets mentioned directly, even in detailed reviews.

As a developer I'm very interested in such subjects, but most players are far more interested in fun gameplay and cool graphics.

This is my take on it as well. Furthermore, text based games don't lend themselves to physics based game play. Generally physics engines are used for two things. Trajectory calculations and explosion/graphical enhancements. I think trajectory calculations are rather worthless in a text environment, not very difficult to calculate, and not very interesting from a UI perspective. So I think it's quite the red herring. Additionally, doing physics calculations on the server is rather silly for most things, and something most muds would have to do since their client side support is very limited even in the best cases. Instead I would say the thing people are more interested in rather than "physics" is consequential gameplay. Like raining putting out fires. This sort of thing. Things that do no harm to immersion. Physics sandboxes really wouldn't even be fun without being able to see in a nice interface the cause/effect relationship. Even if someone made such an engine (open source physics engines already exist) without a nice interface (which also exists, kinda) we wouldn't be able to enjoy them. In other words, you wouldn't be dealing with a mud any more, because text wouldn't be a proper interface for a physics sandbox.

There is no pretentiousness intended, it was more of a jab at myself, as in "Wow, really, as if we don't have enough shitty MUD servers already, somebody is making ANOTHER one?" rather than trying to state "This won't be like the rest of the ordinary." Sorry you had to read into it the wrong way.


Because it's the hobby I enjoy. I'll be honest that I have less than 0 interest in mobile, web, or any other development. I specifically do not want to be paid for development type work. Once you accept pay it stops being a hobby. For me, once it stops being a hobby, it stops being fun. I'm not too worried about finding players; it's not a goal anymore. I ran a few games that had their ups and downs over the years but since I've been able to move within my professional career to the level of "not having to deal with shitty customers" I'm pretty happy to also be beyond it on the side of "not having to deal with shitty players" when trying to run a game.

I do IT work now as-is, but strictly with long haul carrier grade network gear. All the big pipes of a private network. I'm happy I don't even have to touch IP-layer stuff as despite knowing it, I don't find it enjoyable to play with. When I previously mentioned that parts of this hobby, learning various programming languages, have helped me at work it was true; but only as far as making my own life easier (automation FTW) and earning some nice kudos along the way. It was never something I did looking for a step-up or a new career direction, but I'm all about "smarter not harder" when it comes to real work and I took the opportunity to make my own life easier given the skills this hobby has taught me.

I assume you are talking about fairly meaningless physics here, stuff that players can safely ignore, and/or gimmicks that impact one location and are subsequently more quest-like. If there was a real impact players would read the descriptions or suck at the game, if reading descriptions is pointless players won't do it, this because it'd be like slapping yourself repeatedly in the forehead.

As real physics would heavily influence gameplay it should interest players, generating cool descriptions will be tricky.

I believe there is a thread-safe (mostly) version of curses, but it still operates on the principle of tying itself to STDIN/STDOUT/STDERR and keeping global (or in the thread-safe case, thread-local) state info. That's what makes it hard to use in a multiplexed environment (such as a typical mud server). You can dup() the stdin/stdout/stderr descriptors to your socket without too much fuss, if you're only doing it once… but trying to keep flipping them around is asking for trouble.

In the thread-safe version, I would imagine you would can curses_init() only in the child threads, and never in the main program.

I've only used curses with fork/exec, so I don't know the details offhand. :(

'As real physics would heavily influence gameplay it should interest players, generating cool descriptions will be tricky. '

More than tricky. A building is burning, so will collapse proressively, affecting surrounding etc.
Descripion will become longer and longer to reflect it.
Up to the point it would make no sense at all unless you start to make a resume, then what would be the point of a physics engine to begin with.
Will you be able to pick each stone left individually or not etc etc etc.
I think this is impossible to make into a text game without taking any fun from it.

You'll need abstraction layers based on player skill and ability, and there will likely be a difference based on the player using look or examine, as well as the availability of light. A carpenter might see a metal sword, while a blacksmith would see an elven titanium longsword. A warrior would have to trust the blacksmith not to sell him a low quality sword, instant fun/drama. A burned down building is a bit of a challenge, but unless a player examines it they would see 'a burned down building'. As they would only see the side they are facing this will keep the need to describe to a minimum.


The wall would eventually collapse into a pile of rubble, and the rest of the house might come down on top of you while at it.


And a house that's just a generic room object with the 'inside' flag and a fancy description is fun? The main reason MUDs are failing might be because they are the equivalent of poorly written books with gameplay that is barely beyond farm ville, and at best make an alright background setting for mediocre roleplay. As virtual worlds they're way behind graphical games.

The main reason is the same why soundless and black and white movie were left behind. More complexity and more Matrix' like environment will not change anything to that. Not to mention game have gone to mobile where you dont have a decent keyboard to play with in the first place.
Would the wall collapse on you and kill you btw….or some bystander…If not, it means you are strong enough to sustain a whole house falling on your head ? Then what would be the point to deal with a house collapsing realisticly anyway. Having material for crafting ? Quite poor explanation don't you think ?

I gutted and re-did things with thread-per-socket. It was an interesting realization that you can only unlock a mutex from within the thread that originally locked it (makes sense I 'spose). Care to give any feedback on the design? I've been pushing Doxygen pages to here too, if you want to see how it stacks up against a call graph. The basics right now are Server -> spawns a SocketServer thread that loops on accept(). On a successful accept(), a new SocketClient() thread is spawned and loops on recv (buffer) / send (buffer) while the Server object loops the overall SocketClient list to tell each when to process any pending commands.

Still need to do locks involving command processing and some other cleanup. So far I've only got locking going on creation and destruction for each socket to ensure nothing wonky happens when they are setting up or tearing down (as I did have wonky things happen :). Trying to get all the Doxygen stuff done then I'll get back to the parts I started to move into a separate class of Thread stuff to be inherited. Easier to write docs and see call graphs when things are small, and to then keep up with them later :)

I don't think WoW will die off because games have gone mobile.

Movies and books both tell stories, except movies do this audiovisual, and books through narrative. You can't compare MUDs to silent movies, it'd make more sense to compare the first simple 2d graphical games to silent movies. MUDs will never be obsolete as they cannot be replaced by graphical games, though technologically they're at a standstill, and the narrative is typically of very poor quality.


This depends on whether it collapses inward, outward, or both, and whether someone is standing next to the wall. I've discussed the representation of a describable world in in a previous topic: http://www.mudbytes.net/index.php?a=topi... As is common the collapsing wall would cause damage based on height, material, rubble size, and a dice roll. Falling trees will be far more interesting as it's reasonable to add an incentive to cut them down.


Danger is a natural consequence of realism, which makes the world that much more interesting.

At some point, if you add enough features, your MUD will begin to vaguely resemble an MMO backend….

One of the unfortunate problems muds is the fact that building takes a lot of time and effort, no small part of which is dealing with a room based system. While coordinate systems are more flexible, they are exponentially more complicated, at least in theory. It's much easier to have something IN a room than to have it AT a coordinate IN a room/room-less space. Then you might have to consider pathfinding for AI too.

I think a in-room coordinate system could prove interesting, since you could place things on top of a elevation, so you'd have to go up there to get it (a practical use for a climb skill). My thinking on navigation would include some kind of conical "view" (what the player can see) and a 'lookat <?>'/'go <?>' and the ability to look a cardinal direction, some numbers of degree or to the left, right, up, down, etc. With some effort to simplify it and reduce the number of command necessary to achieve it, it would be interesting.

A possible example of this would be if there was a bird in the room, you could say 'lookat bird' and the game would basically "look" around and then focus you on the first thing like that it found and show you the dynamic description generated for your current "view". Ideally, there would be varying possible degrees of specifity, such that you could look for someone by name, and somehow based on data stored by the game about things you've seen/know about, if they were nearby, the game would find them and show them to you. The game's algorithm would probably depend on visibility, nearness, etc to decide if they were "there" to see.

Obviously there are plenty of sticky problems associated with implementing such.

** Anyway, off-topic, but I do think that there are some purely technical aspects of mud world-building that interfere with the ability to produce the best possible
worlds which would ultimately be of interest to players. A lot of muds, I suspect, lose, or could lose, potential players just to the learning curve and all the bloody commands, not to mention somewhat non-intuitive navigation among other things. – I mean to play GW II, Aardwolf someday, I just don't have as much time as I'd like. **

The point of "modeling" a house collapsing realistically would likely be to make it possible for someone to deliberately cause a house to collapse. Convienent demolition + crafting materials + realism that doesn't exist when a "destroyed" house disappears is a small reason. Logically though, you'd need a game reason for houses to be destructible anyway.

I don't know about other people, but part of the fun of a "game" is to escape reality. A game that tries too hard to focus on being "realistic" isn't fun to me.

Eating, drinking, movement points, need for lights, equipment degradation etc. are all "realistic" game mechanics that I don't find particularly appealing in a MUD.

I prefer to judge the appeal of specific implementations rather than general feature concepts. I don't like the way Diku handles a lot of features, including eating and drinking, movement, etc (and even things like combat, magic, and classes) but that doesn't mean I dislike all implementations of those features.

Also: I like the idea of letting people destroy buildings, but I'd rather focus on making it "fun" than "realistic". I actually have certain mobs cosmetically described as buildings, and it works out fine.

That's always a good distiction. Any feature can be made fun if implemented well. It can also be simplified or partly automated if the goal is a casual game. When people say they don't like certain features, they usually mean they haven't come across good/fun implementations in their experience.

Fact is when you go towards realism, you open a can of worms. Why is this realism, but not this etc etc etc.
It is a game, not a simulation of life. Life is not fun, especially since you can lose it very very easily.
And if you have a magical worlds…if you do not put any limitations (that are in themselves, not very coherent either) all hell break lose.