11 Apr, 2015, Negasi wrote in the 1st comment:
Votes: 0
So I'm trying to design a in-room coordinate system, where a room would contain "room tiles" that make up the move-able area within a room. For instance, a room may be 4x4 in size or a hallway may be 2x4 in size. My idea is you would navigate through rooms with the same cardinal directions in your classic SMAUG MUD. An unfortunate side effect is slowing travel within an area, but not one I think will be extremely detrimental to the type of game I'm creating. The reason I want to use such a system is that I am creating an RPI MUD (which means having well-written descriptions is critical), but the in-room coordinate system makes combat with ranged weapons much more robust allowing for true line of sight and cover systems. Objects will be placed on appropriate tiles and interacting with them will automatically move your character to where their at (after running a function to insure you can get to the object). Where I always get tripped up is when I imagine a room with a balcony over-looking it with an exit underneath. My idea is not to make movement convoluted, but I still want to design a system to give builders the ability to create great settings for characters. One idea I had was creating an object that represents the balcony inside the room and a room that the balcony object represents. When creating the room tiles for the balcony room, you can set tiles outside the actual structure of the balcony that will allow you to see/shoot/hear/etc. with the parent room. I was just wondering if anyone has ideas for this type of system or has seen a similar system implemented and how they accomplished it. Thanks!
11 Apr, 2015, quixadhal wrote in the 2nd comment:
Votes: 0
If you really want LOS combat and effects, why not ditch the room model and make a coordinate based MUD. You can always "hang" descriptions across a range of coordinates (bounding box) and default your movement commands to a fixed distance (IE: "north" is an alias for "move north 10 feet" or whatever).

If you didn't care so much about the combat aspect, many LPMUD mudlibs allow you to reflect what's happening in one room to another, so you could have your balcony just be a different room, but looking over the balcony shows you what's happening in the room below.

Trying to mix the two will always end up giving you problems, either via a clunky UI, or via edge cases "Why can I shoot someone 2 feet away to the east (into the room), but not 2 feet away to the west (through a doorway into the next room)?"
12 Apr, 2015, Negasi wrote in the 3rd comment:
Votes: 0
A fully coordinate system wouldn't be a terrible idea, although I would probably be stepping completely outside my comfort zone. I could make a room represent a single coordinate point and create a way for a description to describe upon look all of the points within it's list. Just a little background on the game I'm creating. It will be a Star Wars MUD based after Episode IV: A New Hope. I've got C++ base (AspenMUD) that I'm helping develop and will eventually base my game on once it's at a point where I feel I can start truly branching off. I would like to avoid a bunch of refactoring, but it already supports having a room represent a point (x,y,z coords). I think doing it this way will allow for flight from orbit into a planet (or zone) and an eventual large scale combat system. I guess my next question is how I display this to players as they move about ? So a player enters a new "room" (I will refer to room as a set of coordinates) and sees the description. How do I display objects, npcs, other characters ? Also, How do I work exits/entrances ? Do I use a 'wall object' to close in locations that are inside ?
12 Apr, 2015, quixadhal wrote in the 4th comment:
Votes: 0
If you were using a full coordinate system, one method is to "hang" the descriptions over ranges of coordinates and then check for intersections.

This might be helpful: http://stackoverflow.com/questions/11716...

The problem is much simpler if you ensure the polygons don't overlap (IE: either it's inside the polygon, or it isn't… no worries about it being inside more than one at a time).

It's also simpler if you just use rectangular regions. If that's the case, you'd define each region with data like:

('Kitchen', 340,400,0,50,30,10, 'You stand in a filthy kitchen.')
('Hallway', 360,430,0,5,20,10, 'You are in a narrow hallway.')
('Bathroom', 340,450,0,10,20,10, 'You are in a gleaming bathroom.')

Then, if the player were at coordinate 370, 410, 0, you'd call the algorithm with those coordinates and it would spit back the room data for Kitchen.

Walls are the edges of your polygons (rectangles in the simple case). When moving the player, you need to ray-cast from their current location to the edge and stop movement when it intersects… thus they move until they hit the wall.

"Exits" are simply the overlapping line segments of two polygons. You may treat those as open, or put doors or other things in there as you like. It *IS* quite a bit of work, because I don't know of any existing codebases (public ones) that use coordinates. That's probably why people keep trying to shoehorn fake coordinates into rooms… nobody wants to do the work, and once they do, they feel like they shoudln't share it or something.

Anyways, you'll also want to look up line-of-sight and ray-casting if you want to explore this further. :)
15 Apr, 2015, Nathan wrote in the 5th comment:
Votes: 0
It's probably possible to retrofit a room-based system by adding coordinate data, size data to your rooms, reworking descriptions so they don't use static data from the rooms (you'd basically add your infinite map and pull data from that, and then reworking exits to be less finite (i.e. don't take strict direction commands but simply treat the exit data as an edge you should cross if you travel far enough in that direction). It's obviously not as clean as a system designed from the ground up, but it's probably doable.

Such an approach might actually be less difficult, if a bit more tedious, on a C based system because the functions aren't intrinsically tied with the objects. So something that pulls description data from a room struct could just ignore the room's description data and pull from a global variable. The same being true of anything else really, although using data that isn't passed around can make your program's code/flow/logic/? confusing.
16 Apr, 2015, floyd wrote in the 6th comment:
Votes: 0
Hi Negasi,

I recently relaunched & started development anew on a MUD, Arantha, that uses an in-room coordinate system. You can check it out at arantha.net port 4000.

The essential nuts & bolts is all PCs, mobs & objects have a coordinate in the given room. The player uses the 'tactical' command to switch into the tactical movement system (this is done automatically when under threat from aggro), and has a small double map the size of the room to walk (N, E, S, W) around in. One map shows PCs/mobs, the other objects, in a manner similar to ASCII adventure games. Certain interactions cannot take place (get, give, touching socials, melee attacks) when you are not adjacent to the target. When the PC moves out of the room through any exit, they are revert to the normal, room-by-room movement.

In combat the movement allows a competent group to have warriors engage first, given the time and distance, while the less-powerful classes stay back to ward off the hits. There is some addition of area-of-effect involving spells, where an errant fireball or lightning bolt might catch your party. Range combat is unfortunately unfinished, though there is considerable promise with the positioning system.

Feel free to log in and send me a tell, if I'm not busy I'd be glad to answer any questions you have regarding the coding aspects. Our rooms are currently rectangular only (X, Y, Z dimensions), and while I think it would be neat to expand to custom shapes, given the relative linear-ness of the N E W S one-door-per-wall direction system, it would be a TON of work and more input to building each room, and I think there are so many other things that are more deserving of the coding time.
0.0/6