24 Jan, 2013, Scandum wrote in the 141st comment:
Votes: 0
KaVir said:
arendjr said:
What makes you think so?

Experience. I spent a few years trying to implement similar functionality into a room-based model before scrapping the lot. It's possible, but it feels clunky and it's a lot more work.

Here's an example from Nathan Yospe's Physmud++. Imagine how you'd try to represent the same information with rooms:

Is there proof that physmud++ actually existed? The mixing of describing the environment and events at the same time is highly suspicious.

Most of this can be done using rooms and a breadth first algorithm. One advantage is that you won't have to parse potentially large lists of mobs and players, and automatically parse nearby objects first. Line of sight is also easier to handle for this reason as you can degrade vision as you crawl through surrounding rooms.
24 Jan, 2013, KaVir wrote in the 142nd comment:
Votes: 0
arendjr said:
The question is: If the vast majority of your world was confined and in-door, with many, many physical rooms and corridors, would you still believe roomless is the best way to go?

It's difficult to generalise, each approach has its pros and cons, so my answer would depend on the precise requirements of your mud. My response was based on the features you listed earlier (distances, line of sight, area-effect explosions, etc).

Scandum said:
Is there proof that physmud++ actually existed? The mixing of describing the environment and events at the same time is highly suspicious.

You know there's no proof, we've been over this topic, but the concept he describes is sound. I mix environment and events as well, although not to the same extent.

Scandum said:
Most of this can be done using rooms and a breadth first algorithm. One advantage is that you won't have to parse potentially large lists of mobs and players, and automatically parse nearby objects first.

There are various ways of distributing creatures and objects across the world to speed up searches, but that's not the same as a room-based system.

You really wouldn't want to use rooms for that, it would mean iterating though potentially hundreds or even thousands of rooms every time you performed an action, just to see who could see it or be affected by it.
24 Jan, 2013, arendjr wrote in the 143rd comment:
Votes: 0
KaVir said:
Scandum said:
Most of this can be done using rooms and a breadth first algorithm. One advantage is that you won't have to parse potentially large lists of mobs and players, and automatically parse nearby objects first.

There are various ways of distributing creatures and objects across the world to speed up searches, but that's not the same as a room-based system.

Why isn't that a room-based system? What Scandum describes is actually remarkebly close to the way I do it, and I really consider my world to be room-based :)

KaVir said:
You really wouldn't want to use rooms for that, it would mean iterating though potentially hundreds or even thousands of rooms every time you performed an action, just to see who could see it or be affected by it

Depends on the action, and the environment. In closed spaces, events will not propagate that far, and simple sounds or movement are typically only propagated to very nearby rooms. Still, that's part of the reason why I created a benchmark to see what the impact is if you actually do want to propagate a strong visual event in an open area to all 10,000 surrounding rooms. The cost was 13ms on a modest CPU, so I don't think there's a fundamental problem with that :)
24 Jan, 2013, Rarva.Riendf wrote in the 144th comment:
Votes: 0
Quote
Still, that's part of the reason why I created a benchmark to see what the impact is if you actually do want to propagate a strong visual event in an open area to all 10,000 surrounding rooms.

Now put something in your rooms that actually react to your events. Of course it is fast when the first visual event test is 'noone is looking, return'.
24 Jan, 2013, arendjr wrote in the 145th comment:
Votes: 0
Rarva.Riendf said:
Quote
Still, that's part of the reason why I created a benchmark to see what the impact is if you actually do want to propagate a strong visual event in an open area to all 10,000 surrounding rooms.

Now put something in your rooms that actually react to your events. Of course it is fast when the first visual event test is 'noone is looking, return'.

But that's not a cost of the propagation, is it? If you'd do a similar thing with a roomless environment and actors have to act, well, you get the same thing.
24 Jan, 2013, Runter wrote in the 146th comment:
Votes: 0
I developed a system that used both room and roomless at the same time. I just limited the roomless functionality to the dimensions of whatever the granularity and shape of the rooms. For tasks taht I wanted to propagate based on rooms, I traversed the graph of rooms. For things that I wanted to do in a roomless system, like walking around the rooms, looking down the hall, etc, etc, a roomless representation was available in parallel. I find that there's clear advantages to both and didn't see a compelling reason to limit myself to one or the other. Even in wide open spaces, or closed areas.
24 Jan, 2013, KaVir wrote in the 147th comment:
Votes: 0
arendjr said:
Why isn't that a room-based system?

Why aren't "various ways of distributing creatures and objects across the world to speed up searches" the same as a room-based system?

Because the first represents different ways of optimising data searches, while the second is a means of encapsulating creatures and objects into abstract containers with discreet player-visable boundaries.

Runter said:
I developed a system that used both room and roomless at the same time. I just limited the roomless functionality to the dimensions of whatever the granularity and shape of the rooms.

Was the transition between rooms seamless, or did players approach the edge and then hop over into the next room?
24 Jan, 2013, Runter wrote in the 148th comment:
Votes: 0
Quote
Was the transition between rooms seamless, or did players approach the edge and then hop over into the next room?


The only way that players could tell there was such a thing as rooms is that some mechanics were displayed as rooms. Like my mapper was based on the graph representation. So your location had a higher granularity on the mapper. It may take you a few seconds to walk across a big room, but your location on the map wouldn't move until you've entered the next node, but as far as other things were concerned (like interacting with the world around you) it was a roomless system. Each room did maintain lists of characters in that node, though. In that regard, it was a way to partition the room-less system and do certain types of searches.

Interestingly, the system started roomless and I added rooms later.
24 Jan, 2013, Idealiad wrote in the 149th comment:
Votes: 0
You see that approach in roguelikes sometimes, it has advantages for map generation and things like that.
24 Jan, 2013, Rarva.Riendf wrote in the 150th comment:
Votes: 0
arendjr said:
But that's not a cost of the propagation, is it? If you'd do a similar thing with a roomless environment and actors have to act, well, you get the same thing.

What I was saying that all you did was basically to time an empty loop…
Of course it is fast.
24 Jan, 2013, arendjr wrote in the 151st comment:
Votes: 0
Rarva.Riendf said:
arendjr said:
But that's not a cost of the propagation, is it? If you'd do a similar thing with a roomless environment and actors have to act, well, you get the same thing.

What I was saying that all you did was basically to time an empty loop…
Of course it is fast.

Uhm, no I'm not. I'm timing the performance of propagation. I actually put four NPCs at the corners and make sure they receive the event. Also I verify that all 10,000 rooms have been visited by the algorithm. Calling that an empty loop is just baseless, or clueless…
24 Jan, 2013, Scandum wrote in the 152nd comment:
Votes: 0
Many room traversal algorithms are recursive and slow as hell. Breadth first algorithms have minimal overhead. So parsing 5000 mobs to find the ones nearby is about as fast as parsing 2000 rooms to find the mobs nearby, though in a realistic setting you'll only parse maybe 50 rooms.
24 Jan, 2013, quixadhal wrote in the 153rd comment:
Votes: 0
Scandum said:
Many room traversal algorithms are recursive and slow as hell. Breadth first algorithms have minimal overhead. So parsing 5000 mobs to find the ones nearby is about as fast as parsing 2000 rooms to find the mobs nearby, though in a realistic setting you'll only parse maybe 50 rooms.


You don't need to parse ALL the mobs to know which ones are close, provided you keep a data structure that maps them to coordinates. I'm sure you're familiar with the many linked lists or hash arrays in Dikurivatives, designed specifically to allow you to search for things by commonly used keys?

So, rather than searching through your 5000 mobs, you instead search through the 20 or 40 that are likely in the buckets that map to coordinates in your propogation range.
25 Jan, 2013, Scandum wrote in the 154th comment:
Votes: 0
quixadhal said:
You don't need to parse ALL the mobs to know which ones are close, provided you keep a data structure that maps them to coordinates.

I would call this an inefficient implementation of a room system, as you're using two tables/arrays, possibly more, where one would suffice.
25 Jan, 2013, quixadhal wrote in the 155th comment:
Votes: 0
I would call it a sensible way of coding things, since you ALWAYS have the choice of coding for space vs. coding for speed. RAM is cheap. CPU's are not so cheap. I'll happily store a few extra pointers to make an O(N) problem become an O(log(N)) one.
25 Jan, 2013, Runter wrote in the 156th comment:
Votes: 0
quixadhal said:
I would call it a sensible way of coding things, since you ALWAYS have the choice of coding for space vs. coding for speed. RAM is cheap. CPU's are not so cheap. I'll happily store a few extra pointers to make an O(N) problem become an O(log(N)) one.


Agreed. We're comparing a few bytes to potentially a lot of CPU usage depending on userbase.

Also, this is a problem well suited for quadtree/octree implementations. (Limiting a set based on spacial locality)
25 Jan, 2013, Scandum wrote in the 157th comment:
Votes: 0
quixadhal said:
I would call it a sensible way of coding things, since you ALWAYS have the choice of coding for space vs. coding for speed. RAM is cheap. CPU's are not so cheap. I'll happily store a few extra pointers to make an O(N) problem become an O(log(N)) one.

You're misunderstanding me as this has nothing to do with CPU usage. The moment you add a lookup table for objects you've effectively implemented a room system, and as such we could no longer speak of a roomless MUD.
25 Jan, 2013, Rarva.Riendf wrote in the 158th comment:
Votes: 0
arendjr said:
Rarva.Riendf said:
arendjr said:
But that's not a cost of the propagation, is it? If you'd do a similar thing with a roomless environment and actors have to act, well, you get the same thing.

What I was saying that all you did was basically to time an empty loop…
Of course it is fast.

Uhm, no I'm not. I'm timing the performance of propagation. I actually put four NPCs at the corners and make sure they receive the event. Also I verify that all 10,000 rooms have been visited by the algorithm. Calling that an empty loop is just baseless, or clueless…


Ok your four mpc received the visuel event…But that was not the point, if you coded your thing sensibly, a visual input is useless if there is no one to look at it. So if there is noone to look at your event, there is pretty much zero code needed to be run. Hence why I am saying that you just timed a basically emtpy loop.
25 Jan, 2013, Runter wrote in the 159th comment:
Votes: 0
Scandum said:
quixadhal said:
I would call it a sensible way of coding things, since you ALWAYS have the choice of coding for space vs. coding for speed. RAM is cheap. CPU's are not so cheap. I'll happily store a few extra pointers to make an O(N) problem become an O(log(N)) one.

You're misunderstanding me as this has nothing to do with CPU usage. The moment you add a lookup table for objects you've effectively implemented a room system, and as such we could no longer speak of a roomless MUD.


Rooms are a game concept. It has nothing to do with the underlying data structure. Do you think roomless muds must limit themselves to a single, global linked list for all calculations?
25 Jan, 2013, arendjr wrote in the 160th comment:
Votes: 0
I agree about rooms being a game concept. Typically the internal design of a room-based MUD also consists of Room objects with associated Exits and/or Portals. Various optimizations with spatial nodes don't automatically make a MUD room-based.

@KaVir: I see, you're emphasizing the technical difference between the algorithm and the data structure. But given the algorithm is heavily influenced by the data structure, it makes sense to mention them together. So yeah, a breadth-first algorithm works well with room-based systems :)

@Rarva: Do you understand the concept of a benchmark?
140.0/204