I am currently trying to add coordinate planes to rooms so that pcs, npcs, and objects all have their own places with-in space. This mainly would be used for battling, i.e. A player who is at (9, 10) could only use ranged skills to attack the player at (6,5), etc. Kinda set up like the SWR's space coord planes, I would suppose.
I don't know how much you know the codebase, or C, but this is no simple task. First step, of course, would be to setup x/y vars in char_data, obj_data, room_index_data, and possibly even exits. Make defaults for all (the room one would probably be the dimensions of the room) the new variables. You'll have to modify your movement code so that instead of moving you from room to room it adjusts your coordinate in the room, check that against the exit x/y and see if they do exit the room, then actually extract them from the room, and start them off in another and a set x/y. You'll have to fine tune it a lot. Test out flee, so you don't just wind up randomly on the other side of an adjacent room. Check out -every- command that would possibly change the room you're in (check for, I think, char_from_room) and change them accordingly.
Once you have movement done, you'll have to add all the checks for range on weapons. Every weapon object will have to have a set range. Next you'll have to move onto things like displaying these things to the people in the room, either by clever text generating, or an ascii map. I'm sure it doesn't stop there, but atm, it's all I can think of.
How detailed are you planning on making the coordinate plane? If it's just to calculate the distance between rooms, then you can get away with allowing the room to have a coordinate. Characters are almost always in a room, and a recursive search can handle objects.
I actually was planning on having most major factors based upon this, and also having exits based upon their relation to the coord plane, i.e. I could have two exits south, one at (0, 9) and one at (0, 4). Yeah, I imagined it would be a biotch to do, but as such, it is demanded and I figured it'd be easier to add it to a fresh codebase than one thats been moddified alot already, hence why I'm not using my older one. The if checks to weapons would need to be based upon geometric functions, would they not, i.e. the distance formula.
So, you're using the coordinates inside of a room as well? Looks like you've got alot of work ahead of you. What I'd suggest doing then is to focus on adding the coordinates to the rooms, characters, and objects first, and get the inter-room movement worked out. Then you can work on the in-room movement. For the exits, you can probably get away with simply adding coordinates on those as well, and having your movement code check for the closest one. SMAUG already supports multiple exits of the same direction, so that shouldn't be an issue.
For the "ranged systems" which use the coordinate plane… you will need to find some algorithms to determine both line of sight and distance. I've submitted a ranged search snippet that implements some algorithms using the exits as a navigation mesh, but Kavir posted a link to an article you may find more useful in the "Ranged Systems" thread under "Code Design".
i did a system like this for my mud, and there are some things you need to plan out before implementing:
1.) how will the system be viewed, every time a player looks, whenever a player moves, whenever someone else in the room moves, etc. also, how will you display this coordinate system to the player, do not, i repeat do not try make it look perfect, as how it will look is entirely dependent on the players font choice. on my system i went with a basic approach. X O X X X X N X X E X X X O X X X P X X The P is the player in the room, the O is an object in the room, the E is an exit in the room, the N is a mob in the room. I have seen another persons system that drew a boarder around the room, and an empty space in the border meant it was an exit. Its really how you want to do it. On my system when the person types look the grid is displayed underneath the rooms description. The grid is also redisplayed when the player moves via the direction commands, but only the grid when its intra-room movement. 2.) another thing to consider is this, when i implemented this system, i found that i had less and less new players staying on, as they did not like an in room coordinate system. the players that did stay loved it. Granted, the theme of my mud was generally more liked by adolescents, and those that were older were the ones that tended to like the system, where as the little kiddies took it as a bother, just something to consider.
if you would like to see my system in action my address is thedragonball.wolfpaw.net:1202
Yeah, presentation is important. I'm personally, not a fan of "in-room" coordinates, preferring a true coordinate plane or placing the rooms themselves in coordinates. Most codebases support a tunneling feature which could be used to restrict the # of people in any given room.
The PK mud I used to play was coordinate based. It had 2 forms of maps you could use. The battlemap would be similar to yours. Each room was a single character, with rows and columns representing the coordinate. The letter would give an idea of what was in the room, but was often misleading (as it could only provide 1 piece of information). The satellite was a map which did not have any information about the contents of a room, but was a detailed map of the top level's exits.
It's an unfortunate circumstance that most people don't like to try new things. I've found that with any system you implement in a mud, you need to take the background of your players into account. They will judge anything you add based on what they're familiar with.
For example, I once added the ability to rent a hotel room for improved regenerations. After posting about it on the MOTD to let players know what it did and that it was NOT required for equipment, I had someone flame me on the mortal board about how he'd never play a mud with rent. Apparently he thought that if he didn't "rent" he would lose his eq (as some muds do).
Definitely an eye opener, since the issue had nothing to do with what the feature did, or how it was used. It had entirely to do with the use of 1 word.