Author Topic: Rooms revisited  (Read 2025 times)

Offline quixadhal

  • BFF
  • ***
  • Posts: 631
    • View Profile
    • WileyMUD
Rooms revisited
« on: February 16, 2013, 06:54:14 PM »
So, I was thinking this morning, about rooms.

The vast majority of MUDs are room based.  Each room exists as a unique object, but most rooms are more-or-less identical in nature.  They have different descriptions, details, inventories, exit links.. but for the most part, they act pretty much like every other room out there.

Some MUDs have the concept of virtual rooms, where the room is generated on the fly, usually drawing data from a graphical map file, or an algorithm.  Sometimes these are fixed, in that if you revisit the same "room" again, it will look the same.  Other times they are more randomized.

As players (and NPCs) wander around the world, each of these rooms acts as an empty container, showing them information about the world around them, but basically not doing anything until the player (or NPC) encounters another player (or NPC).  At that point, they are able to interact.

So, anyways, I was thinking... why not turn the situation around.  Instead of having thousands (or millions) of empty rooms for our entities to wander through, why not let the world move around them?

Simply create a room for each player/NPC and paint it with the details you'd find at the point in the world they're at.  When they "move", just reload the room they're in with the new data.  When a player or NPC walks into the same location as another player/NPC, move them into the same room and let the normal room containment code do its job.  When they move again, if nobody is at that spot, create a new room for them again.

Note that "spot" doesn't have to mean coordinates.  Your world could be a directed graph, just like a room-based MUD is now, you just don't need to actually instantiate all the empty room objects.

What's the advantage?

Well, you could store all the room data in a more compact format that doesn't need to be fully loaded all the time.  Path-finding algorithms don't need to walk all the rooms (forcing them to load), as they could simply use a smaller subset of the data for connectivity.

Just a thought... any comments?

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Rooms revisited
« Reply #1 on: February 16, 2013, 07:37:19 PM »
This is a topic near and dear to my heart.

Basically, if you're going to go that way, there's no point in actually putting people "in" a "room" rather than just having some more abstract concept of their environment, because you can't use the standard LPmud environment mechanics anyway, since you would have to have things bi- and multiply-located and you can't.  Simple and intractable examples include two players who are each far enough away from each other that they aren't in each others' "rooms", but both close enough to a third object that it should be in each of their "rooms" -- or just two players who are close to each other; who do you put in the other's "room"?

Because of this, I've begun a process of moving from allowing content code to use the environment efuns (environment(), all_inventory(), etc.) to making them use lfuns like obj->query_object_nearby(), with the optional argument to that reserved for a "distance" value that's presently ignored in favor of "nearby" meaning "in the same room".  This will hopefully make an eventual transition to roomlessness smoother.

On the topic of benefits, note that if you have a virtual room mechanism, you can already pathfind without loading; I'm doing so.  So that isn't exclusive to this approach.

One benefit I see is that you can model doors as full objects without the hideous hack of having linked duplicate objects in each room the door connects to, then trying to synchronize their state.

But to me, the core benefit is that roomlessness lets you drive toward a fully deformable virtual world, which rooms are an enormous stumbling block toward.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Rooms revisited
« Reply #2 on: February 16, 2013, 08:32:37 PM »
I've seen the moving room done on a mush, but can not for the life of me remember where.  I would abstract the idea of room out entirely, and just fake roomness.

    I've been giving some thought to this of late, for those who watch TMC.  How to implement a mud that is able to be made into a graphical mmorpg.  To quickly summarize my solution, it would consist of a tree such that each node has 25 children arranged into a 5x5 square, such that, for example, the weather is not an attribute on each node but is instead set for 5x5 nodes at once--I say nodes, because I'd be going for a roomless experience like godwars2.  Extract things up the tree, such that for example the system time is considered to be only set for the root node--I'd not actually set it there, but conceptually it is the same everywhere, and so part of the highest node.  This has a number of interesting implications which aren't relevant to this discussion.
    But, I was thinking about how awkward true roomlessness can be if not done correctly, and came to the conclusion that there's no reason they need to represent a roomless world.  It doesn't quite move everything out, and it doesn't allow for a noneuclidian geometry in the way I would use such a structure, but it does allow for some interesting things.  Move the weather to the parent node to the current environment, for example, and you could implement time zones and such, abstracting the data that is the same for each region upwards, and unloading regions that aren't in use right now.  You can even parallelize it by splitting it into smaller trees, calling each a plane, and running them in parallel.
    For getting rid of the room object all together, I'd not fake it by having a moving magic room.  That's cumbersome in some situations, but may be the easiest approach--I'd argue that the best approach is to change all the code to query your new system and forego the idea of being "in a room" all together.  Easier said than done.

    All that said: I think that for a mud that wants to present rooms to the player, just use rooms.  All the technical features that alternative representations allow; well, 95% of players won't notice, and 95% of those who do won't actually care, for the most part.  You've got better pathfinding in terms of efficiency, that's only cool to a programmer; there's enough resources, for most if not all muds, that subpar algorithms for that kind of thing are fine, as is having everything in ram.

Offline Nilrin

  • Friend
  • **
  • Posts: 85
    • View Profile
Re: Rooms revisited
« Reply #3 on: February 17, 2013, 11:38:41 AM »
There's always that nostalgia of what a MUD can represent as well. Obviously not everyone is this way, but part of the reason I play MUDs is because of those old room based adventure games I played on my Comedor 64. I think I could see myself enjoying a room-less MUD, but part of me would always miss old style rooms.

I'm a bit biased towards virtual rooms also, and sometimes I don't think it's clear what they can do, or what concepts are available to you while using them. On the topic of path-finding, I too use it without loading a single room. Also, having rooms loaded all the time is not an issue. By default, if a virtual room is empty, it is unloaded. Generally, unless there's a bunch of junk or NPCs laying around, a player wandering only really has one room loaded (well, technically two if you count the master object plus the clone).

One thing that came to mind, is if someone decided to go the path of a truly room-less world, in what way would information be handed to the player, and at what rate. As it stands, if a player wants to move a little further down the new road they're exploring, they execute a command to do so and then read the text of the next room (or choose to ignore it) and continue onwards. In the room-less MUD, I'd imagine they would use more seamless travel, such as “walk north”, or “follow road” or some such command. Then the character would begin walking, and slowly display text to the player concerning important notes as they move along. However, would you have a player variable tick of some sort that updates info on their surroundings? Or perhaps display the general info only once, and then scroll text when something unique appears, such as an item laying on the ground or a change in terrain. I believe that would be one thing to consider. I suppose you wouldn't even need text at all, but could use a large overhead map of some sort. Though, at that point, you start to step outside of the realm of MUDs as I see them, and look forward more towards that of some kind of multi-player Ancient Domains of Mystery or something (hey, that would be kinda cool actually).

Anyways, just a thought.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Rooms revisited
« Reply #4 on: February 17, 2013, 01:19:43 PM »
Well, try Godwars2.  I'm not even going to try to describe it.  The normal interface does move towards ADOM but multiplayer, but enable blind accessibility--which a number of players on there use successfully, and which is one of the top implementations of it anywhere--and you get to see how it can be done fully through text, no ascii art or maps allowed.

    I think roomless is neet.  Godwars2 is the only one to do it.  Most of my points, though, weren't move to that, though reading back I could see why it looks that way.  My point was that rooms can be faked to the player, without actually having rooms under the hood.  I could take, for example, godwars2, divide it up into tiles, and assign each tile a text description and exits.  For a mud like godwars2, that's pretty pointless, save maybe as a building tool, but there's no reason you can't use the same representation under the hood and fake rooms.
    My particular representation, the one I'm thinking about maybe trying lately (it's becoming really hard to convince myself I don't have time to start it) is probably not best for such a world, as it is spoken of in this discussion; that is, there's probably better alternatives for a mud that wants to fake rooms to the player without loading rooms.  I've designed it, though, to have a number of interesting properties, namely that I can separate the tree a few different ways and move concurrency issues out of all the code: either by making it "planes", and the highest node's children are the planes, or by making it flat and only dealing with concurrency issues when things cross the edge of each region.  Give each node-n, that is a node n nodes up from the leaf nodes, a thread, such that activities on all child nodes run on that thread...and now you can write a whole bunch more simulation into your mud, possibly even simulating each citizen.  Since the idea I'm personally toying with would be somewhat like sim city, or assault: high tech war (which is a mud no one really even knows about), that's a good thing to have.

Offline quixadhal

  • BFF
  • ***
  • Posts: 631
    • View Profile
    • WileyMUD
Re: Rooms revisited
« Reply #5 on: February 17, 2013, 09:52:36 PM »
Just to be clear, I wasn't talking about getting rid of rooms.  Just the opposite, in fact.  The current game mechanics use the "room" as a container which limits the scope of interactions.  When you say "kill orc", the game doesn't need to walk through the list of every player/npc in the game to find out which orcs are in range... it looks at the room's inventory and sees if an "orc" is there.

All I'm suggesting is to not have all the empty rooms sitting around waiting for something to wake them up.

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Rooms revisited
« Reply #6 on: February 18, 2013, 03:11:20 AM »
Oh.  I read you wrong, then.

If all we're talking about is replacing destructing rooms when people leave them (that being the other way to avoid having lots of rooms loaded) with reconfiguring the room they're in, I don't see a lot of value.  The overhead of the destruct and create cycle is meaningful, but it's not overwhelming, and any gains are moderated by the cost of the state transition.

Offline quixadhal

  • BFF
  • ***
  • Posts: 631
    • View Profile
    • WileyMUD
Re: Rooms revisited
« Reply #7 on: February 18, 2013, 06:43:01 AM »
*nod*

I got a similar response (although somewhat different reasons) over on DramaBytes.  The consensus seems to be the complexity isn't worth the trouble, assuming lazy loading of areas (which LPMUD's tend to do by nature).

It seemed like an interesting idea though, so I figured I'd see what others thought of it .  Thanks for the feedback! :)