[Alexei]

It seems to me that MMORPGs have one big advantage over MUDs. Players can see what is around their characters very easily. On most MUDs, you stand in a room (rooms can be the size of a cupboard, or a field) and you see the description of the room, any objects that might be lying around, and any players/mobs that are standing there.

If you want to see what's in adjacent rooms, you either have to go there, or type some command just to see what's around you. In a MMORPG however, you can see what's around you (players/objects/terrain) simply by looking at the screen, and that's a huge advantage.

Let's say you want to use a long bow in a MUD. In most MUDs that will mean you use it like a melee weapon, in the same room as your opponent. Some MUDs allow people to shoot arrows into adjacent rooms, but all that means is that your opponent can type 'north' and be able to engage you immediately in melee combat.

Using a long bow on a MMORPG is completely different. You can be as close or as far away as you like from your opponent, and the time it takes for them to close in on you is ample time to fire arrows.

Dont get me wrong, I'm not leaping on the MMORPG bandwagon just yet, I'm just wondering are there any MUDs out there that have implemented ranged combat (that doesnt involve just involve typing 'shoot arrow north' and then waiting one second for the opponent to come running in) and if not, are there any good ways to implement the things that MMORPG users take for granted?

[wedsaz]

Just change the map system to a coordinate-based system instead of a room-based system. From there ranged combat is a no-brainer, as is seeing things from a distance.
 
My mud's had ranged combat pretty much from the beginning.

[Alexei]

Originally Posted by Just change the map system to a coordinate-based system instead of a room-based system. From there ranged combat is a no-brainer, as is seeing things from a distance.

Could you expand more on that? How your coordinate-based system works/how Ranged Combat works within that?

I have heard of coordinate-based systems before, but am unsure as to exactly how they play/look. Does anyone have any information on them/links to websites?

[Sainos]

I don't think a text-based game would ever get to the point where a GUI game can be as far as distance attacks. They're restricted to a certain number of directions, for one: most use the four cardinal directions, up, and down. There's no sense of speed in most codebases: ie, you move as fast as you type a direction. There are some well-done (::nudge TI: implementations of character speed that make it very possible to play a fleet archer and outrun your opponents as you fill them full of projectiles. Other than these, though, the closing-on-the-archer concept is pretty hard to get away from, even when you extend range to greater than 1 room.

Automappers exist for some MUDs that show you the terrain of the area as you move, and creatures that exist near you. But this and character speed are just facets of what you enjoy about MMORPGs' range systems, and I'm of the opinion that duplicating it won't happen.

[KaVir]

The way we're handling this is that you can "target" any particular "thing" within your line of sight, and then move towards it, away from it, circle around it, etc. Thus in the case of a swordsman vs an archer, they would target each other and the swordsman would charge, while the archer retreated and fired. If the swordsman got too close the archer might instead target the nearby forest and start running as fast as he could.

[wedsaz]

Alexei:
I wrote this beast from scratch, so you can pretty much throw legacy code out the window.
.
There is no such thing as a 'room' in this system. I just keep a list of creatures, objects, etc. Each object or creature has an x, y and z variable with a number in it. Any time you move, look, or perform any kind of action where it's relevant, it goes through the list and picks out the ones whose coordinates are within the right range. The closest thing to a 'room' is when you happen to be within the radius of a tent, but you could be in a corner or in the center, etc.
.
Some advantages are that wide open spaces take up very little resources (few objects), ranged combat is easy to implement, as are self-generating environments and NPCs that actually go out there and DO something. Player-driven building (want a hut? just clear a spot, pile some straw and build it) would be easy too, but I'm still pondering the balance issues.
.
Some disadvantages are lookups to this big list take up a lot of processing (indexes help), seeing things at a distance makes an ugly spammy list (working on that), and inside areas are a bit problematic (still working on that).
.
Ranged combat, as I said, is fairly simple in this system. Let's say someone wants to throw a spear at an antelope. You look see if there's an antelope within his sight, then check see if it's close enough, easy so far. Then you have to remove the spear from the player and put it on the map near the antelope, and call some kind of damage function involving the hunter, the spear, the antelope and its skin. If the antelope dies, you have to take it out, put a corpse there and notify nearby creatures. Basically it's like a regular hit but allows a greater distance, maybe 10 instead of 3 tiles away. Some people managed to kill boars with nothing but a staff, some fancy footwork, and a lot of patience. Hit and run.
.
Trees growing by themselves, AI gatherers going out to pick apples and selling them to buy new clothes, people chopping them down (hey! I meant the trees, leave the gatherers alone! NO! *gatherer dies from axe wounds*) ... nothing is really static anymore.

[thelenian]

The only problem with pure coordinate-based systems is that in order to actually achieve results that are noticeably superior to a room-based system is that your coordinate resolution would have to be in the neighborhood of <1m. Anything less and effectively all you have is a bunch of rooms labeled by coordinates. You'll also have to implement 3d visualization algorithms in order to calculate what each person is able to see (You would actually have to use many of the same algorithms used in raytracing, just at much lower resolutions and minus the graphical rendering). Not only that, but everything you make will have to be modelled in 3d space. If not, it becomes impossible to accurately model line-of-sight (i.e. buildings will need to specify the locations of vertices in 3d space). In other words, it's a massive PITA, and will bring your host machine to its knees if you achieve anything resembling a respectable pbase. Also, rendering a 3d scene through a text-based interface is going to present some very difficult challenges. In room-based systems, the builder has complete control over the player's perspective. In a 3d system, the builder must design his/her areas with absolutely no knowledge whatsoever about the player's perspective. What does this mean? It means that you need seperate descs for every seperately identifiable aspect of an object, which must be modelled in 3d space. Let's look at what this might mean for a building:

Room-based system:

A large wooden shack, worn with age, sits here on the grassy knoll.

examining the shack might yield:
The old shack, its wood bleached grey by the ravages of time, leans to one side as if cowering from the elements. Faded yellow curtains are visible through two windows that seem to be gazing mournfully out onto the prarie.

looking at a window might show you the inside of the shack.

Coordinate-based system:

What you'd see would have to depend on where you are in relation to the shack. In order for that to happen, the builder must specify a different desc for each part of the shack, your visualization system would need to calculate what parts of the shack are visible from your perspective, and an AI system would need to determine what parts of what you can see are important enough that you should see on a toplevel cursory glance.

Closer inspection would tell the AI filter system that more information should be passed onto the viewer, such as more details about each visible object.

Looking at the window, you would have to calculate, based on the coordinates of the windows' vertices (which your builder did specify, right?), what the viewer can see from where he/she is located.

Building a passable description based on the parts of an object that are visible given the relative orientation of the viewer in MUD-style text format is a nontrivial task. Actually, it's far harder than doing graphical 3d visualization. Instead of employing relatively simple 3d->2d transformation algorithms and other well-documented procedures, you'll need to build an extremely powerful AI system that is able to interpret spatial data and produce a dynamically generated description that could pass for something written by a person. I may be mistaken, but I doubt that current AI technology is anywhere near being able to accomplish something like that.

Although the second case does indeed model RL more accurately, I prefer the first. The thing I like about MUDs is that much is left up to your imagination. Just enough information is provided to maintain suspension of disbelief, while letting your mind "render" all the parts that (current) technology will never be able to get quite right. One trend I've been seeing in many new MUDs is the attempt to migrate more and more of the experience from player imagination to hardcode. While understandable, as, in moderation, it provides the consistency and structure needed for a cohesive themed RP environment, this tendency, at least in my opinion, largely defeats the draw of a text-based game. I play MUDs because I'd rather leave most of the details to my own imagination. If I wanted realistic modelling of 3d space in realtime, I'd play a graphical MMORPG.

[KaVir]

When implementing eating and drinking in a mud, you don't have to develop a full simulation of the human digestion system. Equally, when creating a coordinate-based world you don't need to represent it with 100% accuracy - there is simply no need. All you need to do is create a close enough approximation, and most players won't even be able to tell. The additional overhead is fairly minimal (even if you're using a resource-intensive language such as LPC) and it can really add a great deal to the game. Most of us are creating games, after all, rather than simulations.

Here is a cut&paste from Nathan Yospe's "Physmud++" - it's a good example of how effective a coordinate-based system can be:

> look

The flat green plain stretches away into a distant ridge of hills to your right. Sixty meters to your left, a crop of trees springs up, thick and forbidingly twisted. The strange, flat grass crunches under your feet, releasing a pungent scent. Ahead, thirty meters off, a twisting blue stream makes its slow, twisting way out of the small dark forest. Sparse clouds drift by overhead. Something streaks by overhead with a roar. A cluster bomb explodes ten meters off ahead to your right! A piece of turf flies by, but misses you.

> run

You start running toward the stream.

> run forest

You turn toward the forest, running as fast as you can. A roaring sound reaches your ears. The forest is thirty meters away. Something roars by overhead, leaving the impression of a silver streak in your eyes. A whistling sound reaches your ears. An impulse makes you dodge left, and a reddish object streaks by your right ear. The missile starts to climb, but impacts into the forest. You keep running. The forest is ten meters away. You dodge as branch as you reach the edge of the forest. You stop, winded, to catch your breath. You are just within the edge of a small, gnarled forest. Ahead and to each side, crooked black branches tangle together, making it impossible to pass without considerable effort. Mushrooms grow out of the mulch and rot at your feet, and there is a damp smell to the air. The sun filters through the treetops, almost entirely gone by the time it reaches you.

> look plain

You turn around and stare out through the edge of the forest. The plain stretches out into the distance. Far ahead, the flat green plain stretches away into a distant ridge of hills. Thirty meters ahead and to the left, a twisting blue stream makes its slow, twisting way out of the small dark forest. Far off to the right, a fence surrounds a complex of buildings.

> hold rifle

You pull your plasma rifle out of the leather holster across your back and cradle it in your arms.

> reload rifle

The current bolt has a full charge. You don't need to reload.

> hold grenade

Shifting your plasma rifle into one hand, you detatch a sonic grenade from the strap across your chest and prime it. A pack of about twelve Logran drones is approaching from the direction of the complex of buildings. They are about 300 meters away.

> focus logran

You adjust your optical cybernetics to focus on the pack of Logran drones. There are fourteen of them. Magnification is at x300. The pack is led by a class three hunter. The Logran drones are carrying laser rods. The Logran hunter c3 is carrying a rail cannon. They are heading in your direction. They are about 250 meters away.

[xotl]

I implemented a system on Accursed Lands where each object in a room has an x,y,z coordinate.

Movement takes time, so the archer could easily shoot someone and slip away to the next room, finding a place to hide before the pursuer got there.

You also can't attack someone out of your weapon's attack range, ie: If they are flying far above you in the room, and you have a club.

Feel free to drop by and check it out, if you want to see one such text based system in effect.

Xotl

[wedsaz]

Well said KaVir, one can afford to be lazy when making a game. Room-based muds usually don't take these things into account, so why would a coordinate-based one have to do so?
.
Nice ad, xotl, but wouldn't it look better in the advertising for players forum?

[Robbert]

A limited-coordinate system can be overlayed into an existing room system. While this does not give the full functionality of a true coordinate system, it does allow for most, if not all, of the true features such a system provides. Consider:

A room based system is really just a metaphor (albeit the most common) used to depict a singular-axis coordinate system. Just as in space various portions are further broken into quadrants, so too can rooms. Within Room 3701 (vnum 3701), allow for a 100x100x20 subgrid. As persons enter this quadrant from adjoining ones (ie, they move), place them in a reasonable location based upon their axis of entry. This can easily be achieved by taking the converse of their exit trajectory - if their last point in the previous 'room' was 0, 10, 0 (assuming '0, 0, 0' is at the intersection of X, Y and Z, although some benefits can be attained by using 0, 0, 0 as lower left corner or some other arbitrary location (most specifically, no need to work with negative numbers!!), then they enter at 0, -10, 0 into the new room. An easy overlay system could be called via the following system flow (assuming ROM function, adjust as appropriate for your codebase):

[code]
char_from_room(ch)
--log their x,y,z coordinates within this function
char_to_room(ch)
--call place() or something similar, which puts them in their appropriate location - if they leave east, they should be on the western edge of the room
-- call fix() or something similar to adjust for someone/something else being in that location already
[/quote]

Modify other functions as necessary. Ideally, allow for some means of moving within the subgrid itself, eithr via battleship-like coordinates, directional commands, etc.

Alter the major functions for interaction with others, such as get, give, put, kill, open, close, etc.

Once you have the basic structure in place, it is a simple matter to add on to it, exanding the system to accomodate other features. This eliminates the need for costly CPU-iterations by allowing you to only cycle thru the existing room-structure information, if you are using a derivative.

On the other hand, when taking a custom approach, you are much better optimizing the system for coordinates from the get-go, as KaVir and others suggested in their posts.

[xotl]

Wedsaz,

I would think that if someone asks if there are any muds that implement something, you can answer them with a specific name so they can see a working example.

KaVir has an icon that advertises his mud. The fact that he was praised and I was asked to move an answer to another thread seems... inconsistent, unless I missed some specific policy statement somewhere.

Everyone,

Is there a statement of policy for what is acceptable on these forums? I looked around, and didn't see anything posted in a visible location.

It would seem to me that the policy would also encourage constructive, helpful input instead of the alternatives, but I could be wrong.

Thanks

Xotl

[thelenian]

Originally Posted by Room-based muds usually don't take these things into account, so why would a coordinate-based one have to do so?

Because that's the whole point of having a coordinate-based system--if you don't, you basically lose all the important functionality a coordinate-based system offers that can't be done in a room-based system. The rest of the functionality described here could more easily be implemented in either a room-based system, or a hybrid system. If all locations in your coordinate system are point objects, and do not have volume, all you've really done is masked a room-based system by replacing each room with a bunch of autogenerated rooms for each point on the grid.

[wedsaz]

thelenian:
The world I'm building is mostly flat open spaces, so the requirements for a few scattered objects are nothing compared to making rooms out of all that. Meanwhile, IMO room-based systems were designed for inside areas, taking into account what's open instead of what's closed, and are very efficient at it. Outside areas, where there are few obstacles, are another matter entirely.
.
xotl:
It used to be against policy, so I was careful not to mention UrMud. I suppose if it's no longer the case I can stop being so careful about it. Oh wait, I just did.
.
As for KaVir's icon, it doesn't show up in lynx so I didn't see it. I don't see the reply button either, since it's an image with an empty alt tag. Would be nice if someone could put the word 'Reply' there or something, thanks.

[thelenian]

Ahh, yes, coordinate-based system for pure wilderness is much more feasible. You start to run into most of the problems designing the heuristics for an AI interpreter that does raw spatial data->human-readable text on man-made objects and environments.

As for mentioning the name of a specific MUD, it's generally considered bad form unless it's either:

A) absolutely necessary to make your point clear

or

B) explicitly asked for (as is the case when someone asks where they can see a working implementation of X)

[wedsaz]

thelenian:
How about the problems of trying to make AIs that go out to gather apples but *don't* get stuck in player-built mazes?
.
As for naming names, Alexei asked if there were any such implementations, and not where they were, so I wasn't sure. It's not like I can't use more players, though.

[thelenian]

Pathfinding is incredibly trivial compared to the kind of interpretive AI I mentioned earlier.

I had a bit of useful discussion on the subject (pathfinding) on TMC a while back.

[KaVir]

Originally Posted by Robbert wrote: A limited-coordinate system can be overlayed into an existing room system.

It can, yes - and I've done it in the past - but generally I found the results to be a bit disappointing compared to a true coordinate-based system, as the "rooms" still create artificial boundries which interfere with combat.

Quote: