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

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

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.

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.

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

Kas.

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.

I think I failed to make my point clear - I was supporting your (Robbert's) proposition that the basic algorithm would be O(n), before further improvements.

The only circumstance I can see where the O(n*n) would apply is the one I quote above, finding number of players near each player.

You could look at one 'game loop' in this context, where you might need to construct n 'player views', each of O(n) approx, so the complete game loop computation is O(n*n), though even in this case I think O(n*p) is a better value.

As you said, there are various improvements that would reduce this in practice.
For example, if we have found when constructing Frank's view that Frank is near Ruprecht, we know when constructing Ruprecht's view that Ruprecht is near Frank and don't need to calculate it again .
Similarly if Frank is near Ruprecht, and Ruprecht is near Wilhelmina, we know that Wilhelmina is at least 'fairly near' to Frank, though we may need to refine that.

TopMudSites.

Hello boys I'm doing some very hard and complex simulation and I found this topic very interesting. Basicaly I simplified seeking of targets to something like 3D room and I wanna know if there is better and FASTER way to do this. I do probably have two problems big list for seeking and considering of what data I would need.
Could you post some links?

It's strange I do RPG Strategy Simulation and I found lots of interesting problems here, and not on the graphical/ game servers. Probably becose I have similar problems like muds but for different reasons. At least most of them are different.

Re: Can MUDs implement range/distance?
 

This game is a recent browser/C# remake of a MUD that had a coordinate system/text map, and a sandbox style (players make everything) back before anything else did in the 90s.

Re: Can MUDs implement range/distance?
 

You necro'd a 10-year-old discussion thread so that you could post a random promotion, on a board that explicitly asks you not to post promotions?

And no, your game was not the first to implement those features.

Re: Can MUDs implement range/distance?
 

At least he necro'd an interesting thread.

Re: Can MUDs implement range/distance?
 

Ok, so a few thoughts on this.

Firstly, godwars2 does this. Go look at it for a good example which is running still.

Secondly, there's a harder, but less processor intensive way of finding near objects. I forget what this is called--I'm not smart enough to have come up with it--and a lot of 3d engines use it:

The world is a quadrant forming the first node of a tree.
Divide the world into some number of quadrants--9 works well--and make them the next set of nodes in the tree.
Keep dividing until you get to the desired resolution.

To find an object in the same area as a player, you simply walk up the tree to the desired resolution and get the list from that. You can do that by finding all leaf nodes below the desired resolutional node (new term!), or you can sacrifice memory and store each object in all nodes containing it...so, the world node gets all objects.

If someone can remember what this is called, it'd be a help--I'm bad at explaining it.

Also, you can divide up the world into "regions" or "maps" or what-have-you, making the two lists in the o(p*n) algorithm smaller--p is the limit in each map and n the number of objects in that map. Should help anyway.

Re: Can MUDs implement range/distance?
 

I'm guessing quad trees camlorn, but I think there use is more typically for representing very large worlds than line of sight calculations.

Re: Can MUDs implement range/distance?
 

Heh, well, it doesn't much matter. I didn't realize this topic spanned two pages and was replying to the old part from however long ago. Only just now realized that this was necroed for a random promotion and that I wasn't reading the latest post.

Oopse.

I think oct-trees are what I was talking about--might also be called quad-trees, I really don't know.