27 Nov, 2010, jurdendurden wrote in the 1st comment:
I'm backtracking a bit in development now, and taking a look at a coordinates based system. This will make certain things a lot easier for me to implement, and others work better. I want to use x,y, and z for depth (-1 or more being underground, +1 or more being above ground).

Does anyone know of a mud that has done this? It's a fairly major undertaking and I'd like to take a peek at other implementations to get a feel for possible pitfalls and caveats.
27 Nov, 2010, quixadhal wrote in the 2nd comment:
First question… are you talking about a coordinate based MUD, or a room based MUD with coordinates? They are very different.

Many MUDs come with coordinates out of the box. It's fairly trivial to add them to your existing rooms. Just add the x,y,z structures to your rooms (and whatever load/save code you need), and decide where coordinate 0,0,0 is going to be. Write a flood fill routine to go populate the coordinates from that point.

Now, there are two things that will make it slightly tricky. One is non-connected areas…. anything you have which isn't directly accessible via an exit isn't going to get coordinates. So, you either have to go to those by hand and fudge some that make sense, or accept that parts of the world are outside your normal geography and have whatever code you write that uses coordinates deal with the fact.

The other, and the one that will halt you in your tracks, is that many MUD areas are non-euclidean. A coordinate system expects the world to make sense, and if you make areas where NESW doesn't always return you to your starting point, those coordinates are going to blow up on you. So, you probably first need to audit your world and correct these kinds of issues, or isolate them so they are purposely cut out of the geography (and thus the coordinate system).

Now, if you were talking about going coordinate based, THAT is not trivial and will require you to rewrite a large chunk of your game code. Everything from combat to visibility and aggro to local chat (say, shout, etc), will all need to be redesigned to work with coordinate ranges instead of rooms.
27 Nov, 2010, David Haley wrote in the 3rd comment:
You can mix rooms and coordinates by imposing sizes upon your rooms, with some smallest unit being the single coordinate unit. For example, a broom closet might be of size one, and a bedroom of size 10x10 (or whatever). This gives you several problems, of course, like:
- if you have a larger room connected to a smaller room, where in the larger room is the exit?
- conversely, if you go from a smaller room to a larger room, where in the larger room do you end up?
- can you have several exits in the same direction? Surely a great hall of size 30x100 might have many exits on its sides…
- your minimal unit is truly your minimal unit, and you can't fudge it away unless you change the minimal unit or leave the coordinate system.

etc.

As Quix said, this is not an easy task, and you should be careful in deciding what exactly it is you want out of this. If all you want is a map, you can do that without coordinates, by stretching exits as necessary (although criss-crossing exits will always confound you). If you want some kind of detailed tactical interface, well, then you don't have too much of a choice. (Of course, you also need to decide how you're going to represent that to players…) Anyhow, the single most important point I have to make is that you need to be sure you have laid out clearly what your goals are, so that you don't go off doing a lot of very hard work that is unnecessary.
27 Nov, 2010, Cratylus wrote in the 4th comment:
jurdendurden said:
Does anyone know of a mud that has done this? It's a fairly major undertaking and I'd like to take a peek at other implementations to get a feel for possible pitfalls and caveats.

It's not exactly what you're looking for, I suspect, since you're likely
mostly interested in input from Dikurivative people.

I did this thing with the codebase I maintain, Dead Souls. It is LP, and
therefore perhaps not the most directly useful example for you to
study. The process I followed involved making the coordinate system
as generic as possible since it is a codebase, and not a mud. It needed
to be flexible enough to accommodate people building rooms, areas,
etc, that I would not know about. This required a system for accumulating
new-room data in a persistent way, as well as subsystems for calculating
relationships between rooms.

As suggested in previous posts, this is not a trivial piece of rework for
an existing codebase. You should expect to have to touch almost everything
in the your code and update it to work with the new system. It's most definitely
not just adding a hunk of new code, but integrating a new *way* of
establishing relationships between rooms, objects, and livings.

I had fun though, so maybe you will too.

-Crat
http://lpmuds.net
27 Nov, 2010, jurdendurden wrote in the 5th comment:
Thanks for the insight from all, it's much appreciated. As I began working out the details of things like ranged/ship/aerial combat, an underworld continent, and other things, I felt it would be necessary to facilitate the inner trappings of these ideas with a coordinate system. Quixadhal mentioned channels being affected, and I thought, "Hmm that's right… yell wouldn't be area based then.. it'd be radius based or something like that." I've been thinking of spells that produce cones of whatever energy type, and how they'd not just be "room affect" spells anymore… they could have an actual cone of influence. You have all echoed my thought that if I decide to fully convert to roomless, it will be a daunting task.

I had previously considered what Quix said about just kind of tacking it all into the existing system, with a COORDINATES_DATA struct in each CHAR_DATA & ROOM_INDEX_DATA, and just working around it in the code… but this seems hackish, though it could certainly get the job done to some extent. Maps are definately a portion of the priority for this project, as I want to accurately portray the world visually for players in a euclidean sense. The portion of newplayers that have tested with me so far have basically all said the same thing. You need maps, and areas need to make sense. My only issue is in fact preserving the work that has been done so far.

David you touched on some points that I had been pondering as well, the size of the 'rooms' or 'tiles' or whatever we'll call them in the end. I had kind of landed on a generic solution to try making all inside flagged rooms 10x10, and all outdoors rooms 100x100. Multiple doors per direction is not something I had planned, though I may go ahead and implement ordinal exits, to allow diagonal moving into an adjacent roomtilething, assuming it's 'walkable'. As for your question with where in the room will you end up… it might be workable to have them start on the north side of the room if they entered from the north (that is, going from a small to big room).
27 Nov, 2010, Tonitrus wrote in the 6th comment:
jurdendurden said:
As I began working out the details of things like ranged/ship/aerial combat, an underworld continent, and other things, I felt it would be necessary to facilitate the inner trappings of these ideas with a coordinate system. […] You have all echoed my thought that if I decide to fully convert to roomless, it will be a daunting task.

You could also upgrade to a full coordinates later. There's no real reason to switch to such a system all at once. You could start with adding the coordinate information to the rooms, making sure they all make sense. Then, if you never need more, don't bother with anything else. If it turns out you need more, you've already done half the work (by making sure the layout is sane).
27 Nov, 2010, jurdendurden wrote in the 7th comment:
That's a very good point heh. That's probably the route I'll take now that you mention it. :D
28 Nov, 2010, David Haley wrote in the 8th comment:
Quote
David you touched on some points that I had been pondering as well, the size of the 'rooms' or 'tiles' or whatever we'll call them in the end. I had kind of landed on a generic solution to try making all inside flagged rooms 10x10, and all outdoors rooms 100x100. Multiple doors per direction is not something I had planned, though I may go ahead and implement ordinal exits, to allow diagonal moving into an adjacent roomtilething, assuming it's 'walkable'.

Well, let's say you have a street, which is outdoors, along which you have houses, which are marked as inside. How many houses can you have along a single given street road? If you only have one exit allowed in a given direction, then per large street you get just one small house. If you have multiple exits, things are more reasonable but you need to worry about how to present those exits (it no longer suffices to just have "west", for example).

Quote
As for your question with where in the room will you end up… it might be workable to have them start on the north side of the room if they entered from the north (that is, going from a small to big room).

That would be workable, yes. But what about their east-west position when they enter from the north? If the room is 100x100 then you have 100 places into which to put them.

Here's an interesting little thing to think about with coordinates-and-rooms systems.
Imagine you have a 100x100 room. It has two exits to the north, each at the far sides, say coordinates 1/1 and 100/1.
Each of those exits leads to different rooms on opposite ends of a long hallway, comprised of a series of small rooms. It looks something like this:
`+_++_++_++_++_++_++_++_++_++_+|                            |+ ++ ++ ++ ++ ++ ++ ++ ++ ++ +|                            ||                            ||                            ||                            |+—————————-+`

If you're not careful when placing people into the room, you can end up with a teleportation system: you go from the left-most small room into the big room, end up in the middle of the big room on the north, and then have a much shorter distance to walk from there to the right-most room.

Also, by the way, once you have the notion of room size, I'm not sure it saves you much work to only have particular sizes, if you're going to be implementing sizes anyhow. In fact, it might be better to just have full sizes rather than try to shoehorn your room layout into just two room sizes.
Random Picks

0.0/8