[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.

Originally Posted by xotl wrote: 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.

Try reading the post pinned to the top of this forum, entitled "Pinned: Posting Guidelines, IMPORTANT: Please read".

Icons and sigs are generic, so it doesn't really matter what you place in them, but each post is written individually - so (in order to try and keep a decent signal/noise ratio) I ask people not to post adverts in this forum.

Originally Posted by Thelenian wrote: 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.

Not so - even without giving things volume, you still gain a number of major advantages from the coordinate-based approach. In particular, you'd be able to calculate distances, allowing you to easily implement a decent ranged combat system (which was, after all, the subject of the original post).

It would also allow you some excellent opportunities for melee combat, including tactical positioning (eg attacking someone from behind), weapon lengths, and best of all a reasonable approach to fleeing from a fight. You wouldn't have to worry about someone typing "flee" and suddenly vanishing into another room, because you'd actually be able to SEE them running off - and give chase, if you so wished. Furthermore because the world is logically layed out, and you can see beyond the constraints of an artificial "room" entity, you'd be able to take short-cuts rather than having to follow their exact route.

In addition you'd be able to implement one of my favourite features, which is ranged sound. A "whisper" wouldn't be a private channel, but instead would be a very short-range channel. Equally a "shout" would travel a lot further, particularly if you were standing on a hill at the time. The "sneak" skill might allow you to move a lot quieter, but you'd still make SOME sound as you walked around - so a very perceptive person might hear you creeping up on them (or possibly even hear you draw your weapon). The sound of battle would also travel, and you might well hear the sound of steel striking steel as two people fight nearby. You could even spawn sounds as events, to realistically simulate sound moving slower than light - useful when trying to determine how far away the lightning is (personally I think that's going a bit OTT for most muds, but it would be fun to code).

[cronel]

Are there any published examples of a coordinate based system? Any codebase, or anything? I would love to see an actual implementation.
--cronel

[KaVir]

Telford's entry in the 16K mud competition is coordinate based.

If you're interested in design approaches, you may want to search the MUD-DEV archives, as this topic has been discussed extensively there.

Originally Posted by (wedsaz @ July 11 2002,05:54 am) 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.

Could you elaborate on your user interface?
How do you handle facing?  Or player motion?  
Can players be set in motion towards some landmark?

[wedsaz]

Originally Posted by Could you elaborate on your user interface?

.
Still working on that. Mostly it's just an ugly list of what's around you, in what direction and how far. If you see a bunch of trees you can call it a forest (same as in RL), but the engine just sees a bunch of trees.
.
"some distance to the north, a white rabbit sits."
.

Originally Posted by How do you handle facing?

.
I don't worry about it. If it's right behind you, you can swing at it. It wouldn't be that complicated to add, but it would just be tedious for everyone and I don't think it makes much difference. Realism should only be pursued so long as it adds to the game, rather than substract from it.
.

Originally Posted by How do you handle player motion?

.
From the player's perspective, it's the usual orthogonal and diagonal movement commands. From my perspective I change their X/Y coordinates, lower their breath and movement points (a staff and some footwear reduce movement cost), and call up the look command. Also if any nearby creatures are targetting or tracking that creature, they will be notified of the movement. Simple.
.

Originally Posted by Can players be set in motion towards some landmark?

.
Not yet. For now, movement is done one step at a time. I do plan on doing that eventually though, since walking north a hundred tiles involves a lot of Ns and enters.

[KaVir]

Originally Posted by wedsaz wrote: I don't worry about [facing]. If it's right behind you, you can swing at it. It wouldn't be that complicated to add, but it would just be tedious for everyone and I don't think it makes much difference. Realism should only be pursued so long as it adds to the game, rather than substract from it.

You could calculate their facing though, depending on what direction they're moving. You could then work out whether or not they can see the person creeping towards then.

I think it's fair enough to say that the "look" command shows everything (you could even describe the character turning around and viewing their surroundings), but I think it could add a lot to have a more limited arc of vision for other times. If someone is running up behind me I'd rather see "You hear footsteps approaching you from behind" and have to type "look", then automatically see them as if I had eyes in the back of my head.

I'd also like the opportunity to perform Tenchu-style assassinations by creeping up behind my opponent. Quite difficult to do that if they can see me

Originally Posted by For now, movement is done one step at a time. I do plan on doing that eventually though, since walking north a hundred tiles involves a lot of Ns and enters.

The approach I've currently got working is that each creature has a desired destination, which is either a fixed coordinate location, or another "thing". Typing "north" sets your desired location as 1 coordinate location ahead of your current desired location (so you can stack them). You can also type "north X", where X is the number of positions you'd like to move. This means the interface shouldn't be too difficult for those who are used to the standard compass-movement system.

I have literally only got this working in the last couple of days though, so there's still a lot more work to do on it. I've got the "speed" half done (walk, jog, run, etc), and am also considering "stacking" targets. For example if you're targetting Bob and he climbs into a car, you should start chasing the car instead. If he drives the car into a garage, you should start running towards the garage - once you get there, you should then approach the car, or Bob (if he's got out).

Because you can target a "thing", and everything in the world is a type of "thing", it means that you can walk towards anything you can see.

I'm still trying to decide how this should be combined with the combat, though. Combat consists of "targetting" someone (or something) then advancing, retreating, circling, punching, etc.

[Robbert]

Originally Posted by You can also type "north X", where X is the number of positions you'd like to move. This means the interface shouldn't be too difficult for those who are used to the standard compass-movement system.

Add a 'head' command, allowing you to continue to move in a particular direction until you no longer can (or azimuth, such as head northeast or head 270 degrees).

Originally Posted by I have literally only got this working in the last couple of days though, so there's still a lot more work to do on it. I've got the "speed" half done (walk, jog, run, etc), and am also considering "stacking" targets. For example if you're targetting Bob and he climbs into a car, you should start chasing the car instead. If he drives the car into a garage, you should start running towards the garage - once you get there, you should then approach the car, or Bob (if he's got out).

I'd suggest, for intuitivity, that you have commands for the paces as well as a pace-setting command, so someone could do "run north" or "pace north" and then "run".

With our new engine, we are creating an analogous command interpreter - it will attempt to determine the command(s) you wish to do based on the construct of your sentence, rather than require you input your command in a specific format. One of the things this does is recognize the paces and change to them automatically. You may want to consider a similar approach, if you're not already.

Movement should be intricately linked with combat, in my opinion - all current paradigms restrict combat to the room or area in which it began, and this is not how it should be. Allow for the participants to set specifics about themselves (if the pressed, retreat or stand ground? If opponent retreats, do we press the advantage or hold back?), and then let combat meander as needed. If done properly, one could use objects and terrain in the area to ones advantage. I don't know if this is putting too much depth into it, but it would be great to fight in the dark and have your opponent trip over the caltrops you've strewn through the area.

With ranged combat, allow for misses to possibly strike others in the surrounding area. If someone passes through the trajectory of an object, perhaps it will hit them, or they will deflect it enough to where it misses its target.

[KaVir]

Originally Posted by Add a 'head' command, allowing you to continue to move in a particular direction until you no longer can (or azimuth, such as head northeast or head 270 degrees).

Good idea - thanks.

Originally Posted by I'd suggest, for intuitivity, that you have commands for the paces as well as a pace-setting command, so someone could do "run north" or "pace north" and then "run".

Well that's what I had been planning to do, but I've actually ended up doing it differently so as to combine it with the combat system. If you're familiar with the Glad2 combat system you'll know about the stacking of moves (and combo moves, etc) - well I've used the same approach for calculating speed. Your "feet" location allow you to move forwards, backwards, circle left/right, jump, duck or kick, and various combo moves allow for variations on that. If you move forward twice you'll start jogging, forward again and it becomes a run, a fourth time and you start sprinting.

This means that you can chase after someone and then do a flying kick when you reach them - or perhaps grapple them to the ground. There is no such thing as a "fighting" state - you just perform moves. You can throw punches and kicks at midair if you like (you can even practice your fighting techniques that way - sort of like performing katas). You can also target anything you like, so you could practice fighting against a dummy if you wanted to (or - my favourite - you could pick up your enemy and use them as a weapon to attack a nearby building )

I may add some commands like "run"/etc and just have them as aliases for feet actions. That should give me the best of both worlds.

Originally Posted by With our new engine, we are creating an analogous command interpreter - it will attempt to determine the command(s) you wish to do based on the construct of your sentence, rather than require you input your command in a specific format. One of the things this does is recognize the paces and change to them automatically. You may want to consider a similar approach, if you're not already.

Nice, although complicated to implement. I'll probably stick with simple commands for the time being though - people in a pure-PK mud don't tend to like verbose parsers so much.

Originally Posted by With ranged combat, allow for misses to possibly strike others in the surrounding area. If someone passes through the trajectory of an object, perhaps it will hit them, or they will deflect it enough to where it misses its target.

I'm not sure if I'll bother calculating the trajectory (once again it's nice, but it's also a lot of effort for something you wouldn't really see). However a "miss" will certainly have a chance of hitting someone else - if you fail your attack roll, the missile will land somewhere else (just how close to the target depends on how badly you missed). So yes, you could fire at one target, miss, and hit something else instead ("Sorry - are you okay? I only meant to shoot your hat off!")

[mhc]

It would appear that the question 'Can MUDs implement range/distance?' has been answered, and the answer is 'Yes'.

In order to find out what items are 'near' you in the coordinate system, you would in the most simple case have to compute the distance to every other object you have. This then becomes an O(n*n) algorithm, which does not scale well. A common trick in simulations is to use a cell structure:

You partition your simulation into cells, and keeps lists of what is in each cell. When checking distances, you only check the neighbour cells and their content. The cell size is determined by the interaction range, which in this case would be the visibility range.

Another popular method is to use lists at each object of near neighbours. For most objects, which do not move, the lists will be static, and you'll be doing little work updating the lists.

Yet another method, popular in raytracing, is to use an oct-tree. Run that in google.com

[Robbert]

Additionally, if you track locations of *thing relative to other *things in the area, little work is necessary to extrapolate the information for the player(s) - work recursively based on the closest thing to them, and continue until they can no longer see based on other things in the area.

(Edit) - This works for sound as well as sight, and the theory is the same. Working from a known reference otuward makes much more sense, in terms of intensity, than taking a mass of things and checking each one to see if it is visible/audible to the character. And it allows for neat additions such as poor eyesight or hearing, and their reverse. (/edit)

Our system of location is based upon inheritance; you can be literally be in a forest and see the trees, or move to a particular copse/meadow/field that has been created within it. This allows for the world creators to give as much or as little detail as necessary. So a City could be visible from the forest, but the individual buildings of it need not be apparent until one is outside a gate of that city, or within it itself.

[Kastagaar]

Originally Posted by In order to find out what items are 'near' you in the coordinate system, you would in the most simple case have to compute the distance to every other object you have. This then becomes an O(n*n) algorithm, which does not scale well.

Surely the simple case would be to determine what distance is considered "near" and list all items that space, which is O(n).

Kas.

[mhc]

Originally Posted by Surely the simple case would be to determine what distance is considered "near" and list all items that space, which is O(n).

Only of you only have one player.

[Loriel]

Originally Posted by In order to find out what items are 'near' you in the coordinate system, you would in the most simple case have to compute the distance to every other object you have. This then becomes an O(n*n) algorithm, which does not scale well.

Originally Posted by Surely the simple case would be to determine what distance is considered "near" and list all items that space, which is O (n).

Originally Posted by Only of you only have one player.

If the problem is 'finding items near a specified player', I believe it is O(n) where n is number of items.

If the problem is 'finding items near each player' I believe it is O(p*n), where p is number of players and n is number of items.
In that sense, it might be roughly O(n*n) where n is number of players.

Finding players near each player would be O(n*n), where n is number of players.