21 Feb, 2012, Runter wrote in the 41st comment:
Votes: 0
Quote
It's possible for a fat person to be more agile than a slim one. It's just not the norm.


Isn't this just a platitude? I think your goal here was to dismiss anecdotal evidence, but that's not clear from this statement. One could postulate that illogically linked rooms create confusion for players. Then you would be able to easily disprove that this is always the case with anecdotes about a game where it's less confusing. Which is exactly what was done here. The correct reply in response to this is to dismiss anecdotal evidence if one doesn't believe it's a significant sample. And indeed it's not, but ultimately anecdotes are all that is needed to disprove an absolute. Unfortunately, I believe that all that is needed is to disprove the position since Crat never asked that existing games change, only suggested it may be positive for new designs. If it's possible to design a logically linked game in such a way that your reasoning doesn't hold true, then one can then make the argument that it should be designed that way. If you still disagree with it I feel it would require other axioms such as "Designing it this way is too onerous." But that doesn't really toss any more cold water on the benefits.
21 Feb, 2012, quixadhal wrote in the 42nd comment:
Votes: 0
Cratylus said:
plamzi said:
Are you enforcing non-collision across zones or only within zones? If only within zones, and if you make good use of the Z-axis,


I don't really know what this means. On the same contiguous planet you'd expect rational coordinates, so if you're talking about avoiding conflicts only within small parts of it, I'm not sure I get the point.


The concept of "zones" is a Dikuism. In a Dikurivative, a "zone" is a discrete chunk of space, often implemented as a unique file in newer versions. The "zone" of a Diku roughly maps to the "domain" or "realm" of an LpMUD, however the driver itself imposes restrictions on things based on the zone identity. For example, a wandering mob can be set to stay within its zone, and quite often builders are allocated a series of "virtual numbers" which are properly contained in a single zone's range.

Thus, to a DikuMUD builder, room #14010 and room #15010 might have some special realationship because they appear to be in two seperate zones. It may be perfectly acceptable to some administrators to allow overlap of these cross-zone entities, because the database itself doesn't care about coordinates or physical shape… it only sees that 14010 and 15010 are two different places.

That's why "only within zones" is seen as a distinct thing for Dikurivative people.
21 Feb, 2012, David Haley wrote in the 43rd comment:
Votes: 0
Folks, it doesn't make any sense to talk about rooms and overlapping and exits and all that stuff when all rooms are the same size. Fundamentally, that is the problem people have with "logical" exits. It's why you need the "portal" approach; you don't want to have to walk 20 rooms just to go by a house because that house has a bunch of very small rooms in it.

It just strikes me as odd that people want to impose spatial restrictions on their building but without actually having spatial properties like size. You want to have a grid of rooms that is inviolate and yet have some rooms be the size of a great hall and others the size of a broom closet?
21 Feb, 2012, Cratylus wrote in the 44th comment:
Votes: 0
David Haley said:
Folks, it doesn't make any sense to talk about rooms and overlapping and exits and all that stuff when all rooms are the same size.


Yes it does.

David Haley said:
You want to have a grid of rooms that is inviolate and yet have some rooms be the size of a great hall and others the size of a broom closet?


I'd file this one under "Letting the perfect be the enemy of the good."

-Crat
http://lpmuds.net
21 Feb, 2012, KaVir wrote in the 45th comment:
Votes: 0
plamzi said:
I have never played a chessboard-style MUD world with no room overlaps. But my guess is it would naturally have to have a lot more filler and travel time.

No, not overly. My old Diku mud assigned each room an x/y/z position, and in theory I could have inserted many stock areas into the world without very much modification. I would have needed to stretch many of them a little bit here and there (or adjust the exits slightly) to avoid overlap, but I doubt it would have required more than a few extra rooms per area.

In theory that might increase travel time slightly, but it's worth remembering that because each room was at a specific position, I had no need for the concept of "exits". You could walk in any direction that wasn't blocked, so if you were ethereal (or strong enough to smash through walls) you could take shortcuts that wouldn't be possible in an exit-based world. It also made it much easier to map out, so players spent less time trying to work out convoluted sequences of directions.

When it comes to "illogical" exits, I prefer the descriptive approach - don't call them "north" and "south", but "bakery" and "blacksmith". You could also combine this with the x/y/z approach by assigning each room a specific position relative to its area, but then providing descriptive "exits" (ferry, train, aeroplane, etc) for traveling between areas. In this respect each area would represent an encalsulated area of interest within the game world, and exits would respresent the means of traveling between them.

Cratylus said:
"You need illogical building for a magical maze"

It's one way to do it, sure. It's not necessarily the only way, and it's easy enough to have rooms which magically exit to non-adjacent rooms while still being logically next to other rooms.

Agreed, but you don't even need "magical" exits to make the maze challenging. For example: People used to get lost in the GW2 dungeons all the time, before I simplified them, even with a simple ASCII map - and those are logically laid out too.
21 Feb, 2012, JohnnyStarr wrote in the 46th comment:
Votes: 0
David Haley said:
…people want to impose spatial restrictions on their building but without actually having spatial properties like size.


I think you are right about this. Size should be a factor when deciding your layout and thus could affect the logic
of your mapping. IMO, room systems are innately flawed with the imposition of "exits"; not that I see any way around
them. (pun intended) :lol:

On the other hand, I don't see anything wrong with short-cuts. I just view them as a "builder's sugar" and should be used
judiciously. If your zone requires them to function as intended, fine. At the end of the day, it seems to be more of an
administrator's preference than a builder's. As head coder / admin, I would expect contributors to build zones that are
manageable but not at the cost of zone continuity. Eg: Zones that are explicitly maze-like in nature.

Its just a matter of balance; a foreign concept to most anyone having anything to do with MUDs. :wink:
21 Feb, 2012, KaVir wrote in the 47th comment:
Votes: 0
JohnnyStarr said:
IMO, room systems are innately flawed with the imposition of "exits"; not that I see any way around them.

Other than the solution I just described, you mean?

If each room has a unique x/y/z position then you no longer need "exits", at least not in the Diku sense.
21 Feb, 2012, JohnnyStarr wrote in the 48th comment:
Votes: 0
KaVir said:
Other than the solution I just described, you mean?
If each room has a unique x/y/z position then you no longer need "exits", at least not in the Diku sense.


Yes, that is what I meant. :biggrin:
21 Feb, 2012, David Haley wrote in the 49th comment:
Votes: 0
Cratylus said:
I'd file this one under "Letting the perfect be the enemy of the good."

There are any number of reasons why a strictly enforced grid system with sizeless rooms is impractical and not "good". A simple example is that once you have your town's street map in place, you cannot expand any of the houses or places inside the town. This has nothing to do with purely academic concern about geographic projections and flux polarity.

As soon as one starts thinking about room sizes, it's really quite apparent that forcing coordinates onto them makes things extremely awkward for giving you the indoor layouts that you might want without stupid strings of placeholder rooms outside.

This all goes away if the restriction is not strictly enforced or you allow portals or whatever.
21 Feb, 2012, Cratylus wrote in the 50th comment:
Votes: 0
David Haley said:
Cratylus said:
I'd file this one under "Letting the perfect be the enemy of the good."

There are any number of reasons why a strictly enforced grid system with sizeless rooms is impractical and not "good". A simple example is that once you have your town's street map in place, you cannot expand any of the houses or places inside the town. This has nothing to do with purely academic concern about geographic projections and flux polarity.


The thing to keep in mind is "what goal is being achieved with room coordinates?"

The idea here, as with sword wounds that aren't mostly fatal due to blood loss and infection, and avatars that heal completely a few times per hour despite having been at death's door, is fun gameplay.

Fun gameplay can be had with illogical exits. Fun gameplay can be had with logical exits. I find that building with logical exits allows you to enhance your game with fun cross-room mechanics*. Directional teleporting, rangefinding, potential long range tank battles, etc. You can nitpick as to what extent each one makes compromises with realism. You can nitpick that a room system that uses coordinates makes too many compromises with realism. I would simply ask whether your mud lets you heal up from 1 hp to full heal in less than 4 weeks of intensive medical attention, with no lingering disabilities.

The system I describe is not meant to be a reality simulator.

It is meant to be an enabler of mechanics that otherwise would be very difficult to implement.

If you really need to have a Tardis house, there are ways to implement that while keeping most of your mud in the grid. Your Manichaean paradigm compensator appears to need recalibration.

The idea, though, that unless you have sized rooms you can stop talking about grids, is like saying that unless you have size-restricted clothing and armor, you should stop talking about having player races.

-Crat
http://lpmuds.net

* Fun not guaranteed.
21 Feb, 2012, Cratylus wrote in the 51st comment:
Votes: 0
Last edit Today, 12:49 pm by David Haley said:
This all goes away if the restriction is not strictly enforced or you allow portals or whatever.


Ah, perhaps you just hadn't turned it on, then. Cheers.
21 Feb, 2012, Runter wrote in the 52nd comment:
Votes: 0
Crat is not a guarantor of fun.
21 Feb, 2012, David Haley wrote in the 53rd comment:
Votes: 0
Cratylus said:
Fun gameplay can be had with illogical exits.

Well it's a good thing I didn't quibble with illogical exits. :smile:

Approximating coordinates is all well and good. It's fine. I never said it wasn't. Combined with a "portal" to zones of different scale it's a very powerful approximation of "logical" spatial layout. In fact, if you read my posts on this topic, I talk a fair bit about solving the scale issue by having different levels of scale, with jump points between them ("portals" as we've been calling them in this thread). But it's important to remember that this is still not a "logical" system; there are plenty of issues that crop up. Whether or not those matter to you in your applications is a different story.

I think you're assuming that I'm saying things from a stupid perspective here, and are being a little flippant with my points. :wink:

Cratylus said:
The idea, though, that unless you have sized rooms you can stop talking about grids

A game that has "illogical" exits is not a grid system. It's something else. This is not a value statement. It's just definitional.

By the way, the entire context of this discussion, in case you've forgotten :wink: is a grid-based editor that imposes structure and that can make things difficult if your rooms don't have size.

My point is that if you are going to strictly enforce a sizeless grid system, you will run into some consequences, some of which are good, but some of which are not great. If you "cheat" with a portal system, a lot of issues go away, but then you need an editor that understands the portals.
21 Feb, 2012, Ssolvarain wrote in the 54th comment:
Votes: 0
David Haley said:
but then you need an editor that understands the portals.


I think we all know what happens in a situation with machines and portals.

21 Feb, 2012, Cratylus wrote in the 55th comment:
Votes: 0
David Haley said:
I think you're assuming that I'm saying things from a stupid perspective here


Oh?

David Haley said:
Folks, it doesn't make any sense to talk about rooms and overlapping and exits and all that stuff when all rooms are the same size.


Looks like a fair assumption to me.

-Crat
http://lpmuds.net
22 Feb, 2012, David Haley wrote in the 56th comment:
Votes: 0
I gave several reasons why it doesn't make sense to talk about all of that when you have a strictly enforced grid. If you want to talk about those reasons, please do so. Or if you'd like, I could also assume you're making awfully silly claims and we can all dance in the forests in revelry and libation. :smile:
22 Feb, 2012, plamzi wrote in the 57th comment:
Votes: 0
Runter said:
Quote
It's possible for a fat person to be more agile than a slim one. It's just not the norm.


Isn't this just a platitude? I think your goal here was to dismiss anecdotal evidence, but that's not clear from this statement… If you still disagree with it I feel it would require other axioms such as "Designing it this way is too onerous." But that doesn't really toss any more cold water on the benefits.


I think KaVir and DH are doing a great job of showing what I meant with my somewhat elliptical metaphor, and KaVir did so with specific examples drawn from his experience. I was being terse because I don't have direct experience with MUD worlds that do any collision detection at all. Plus, I can't say I'm deeply vested in the outcome of this discussion :)

What KaVir described is exactly what I had in mind when I said that 'illogical' simply goes away if you think of a room as a location, and not as a grid cell. DH is on point, also, when he talks about the grid concept begging for a room size concept. What you define as the properties of a single room lies at the crux of the matter.

Regardless of implementation details, to me, the rule of thumb would be pretty simple in practice. If at any point a builder has to add a room just to appease the gods of collision detection, you have bloat. You can call it architecture, and you can make the room useful after the fact, but the bottom line is you were forced to put it there. If any world enforces a strict grid without ever forcing a builder to pad, and without "fudging" or "cheating" on its own spatial exam, then I'd be very surprised. If a superbly-designed world respecting collision (no portal cheating at all) is as dense and efficient as a superbly-designed world that doesn't, then I'd be shocked.

Again, there is absolutely nothing wrong with having a world in which every room is a same-size cube within a 3D grid and where this is painstakingly observed. I'm sure there are mudders who expect, and even want, to have to walk around a huge house they know is there. It adds realism for those who have a taste for it.

Speaking of 3D, I'm curious how the Excel Builder would handle going up and down.
22 Feb, 2012, JohnnyStarr wrote in the 58th comment:
Votes: 0
plamzi said:
Speaking of 3D, I'm curious how the Excel Builder would handle going up and down.


This can be dealt with a number of ways. If you were to do it manually, you could just add a sheet to the
workbook that clones the functionality of the "Rooms" sheet. Just name the sheet "zone (level 2)" or what
have you. I'm not planning on sharing one large grid for upstairs rooms for the entire zone.

I'm sure this functionality could be automated. I really don't plan on spending too much time on it though*.

It's not that hard to cut & paste a worksheet and start editing your upper/lower levels. If you want to link
to a downstairs level, just double click the cell, and add a link to the vnum.

* perhaps some future contributor will take a crack at it
23 Feb, 2012, quixadhal wrote in the 59th comment:
Votes: 0
plamzi said:
Regardless of implementation details, to me, the rule of thumb would be pretty simple in practice. If at any point a builder has to add a room just to appease the gods of collision detection, you have bloat.


I agree. You should never feel compelled to have a 100% solid world where every coordinate is a valid location. However, it is usually a good idea for every location to have distinct and unique coordinates, unless there's a Good Reason(TM) for making it non-euclidean.

In the case of this world building tool, I don't imagine it would impose the need for all cells to have rooms in them, however it would have issues with collisions where two rooms would end up in the same cell. In that case, the tool needs to decide if it should reject such input as invalid, or come up with some kludge to display both rooms and indicate they really end up in the same place.

I would probably suggesting an error condition, since it is fairly ugly to try to handle non-euclidean layouts, and if you have some good reason for making one, you can probably do it by hand.
23 Feb, 2012, plamzi wrote in the 60th comment:
Votes: 0
JohnnyStarr said:
plamzi said:
Speaking of 3D, I'm curious how the Excel Builder would handle going up and down.


This can be dealt with a number of ways. If you were to do it manually, you could just add a sheet to the
workbook that clones the functionality of the "Rooms" sheet. Just name the sheet "zone (level 2)" or what
have you. I'm not planning on sharing one large grid for upstairs rooms for the entire zone.

I'm sure this functionality could be automated. I really don't plan on spending too much time on it though*.

It's not that hard to cut & paste a worksheet and start editing your upper/lower levels. If you want to link
to a downstairs level, just double click the cell, and add a link to the vnum.

* perhaps some future contributor will take a crack at it


Starting another worksheet is certainly fine for starters, especially since you can easily have two of them open side by side.

The way I automated it in my editor was through right-click on a cell and selecting an option to dig, or move, up or down. Performing that action moves the grid to that level, and all cells on the same level are drawn, with icons marking cells that contain other up/down exits. I imagine that in your case a right-click action can be set to start a new worksheet, or jump to an existing one, since you're obviously using VBS.

Another challenge that applies to even strictly Euclidean areas would be visualizing "walls". E. g. two rooms are neighbors on the grid but there is no actual link between them. Of course, this is another nice-to-have. Just wondering if you've thought about it yet.
40.0/84