16 Feb, 2013, quixadhal wrote in the 1st comment:
Votes: 0
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?
16 Feb, 2013, KaVir wrote in the 2nd comment:
Votes: 0
Isn't that basically what most wilderness systems do already?

I guess there's no reason why you couldn't apply the same concept to other rooms, the only question is whether the amount of memory you save is worth the implementation effort.
17 Feb, 2013, Lyanic wrote in the 3rd comment:
Votes: 0
I see one immediate problem with this approach. To accommodate ranged/global targeting abilities, you either have to apply the virtual room creation/existence property to all characters equally (so all NPCs) or you have to hook that code into really low level subsystems and write even more code to simulate extra stuff related to the NPCs. If you go with the former strategy, given typical NPC population density, a large enough proportion of the total possible rooms would be occupied, rendering computational resource savings minimal relative to the amount of work you are putting in. The disadvantage of the latter strategy is obvious - even more complexity and implementation effort. So, I agree with KaVir that it's probably not worth it. However, I suppose the problem I have presented disappears if you either don't want to allow ranged/global targeting abilities or you plan to have a very sparsely populated world (NPC to room ratio).
17 Feb, 2013, Scandum wrote in the 4th comment:
Votes: 0
This would work for a world with a low level of interactivity, but I've seen little evidence that players prefer huge empty worlds above small rich worlds.

Keep in mind that traditional MUDs have small empty worlds.
18 Feb, 2013, quixadhal wrote in the 5th comment:
Votes: 0
With the exception of ranged combat (which, I'll admit, makes zero sense to me in a room-based system), I don't see the implementation being much harder than lazy-loading of existing rooms. I'm primarily thinking this is useful for large games where you have many thousands of rooms, most of which are going to sit idle with only a handful of players.

To further clarify the NPC aspect. There are two kinds of NPC's in most games. The NPC's with a purpose, who tend to have some specific role to play. They may wander randomly, or they may walk a fixed circuit, or they may stand still at a location. In any case, those NPC's would likely work like players, in that they'd walk around in their room, interacting with things and each other.

The other kind of NPC is the random encounter mob. These are throwaway creatures which are there to give the players something to hunt that's less predictable than the fixed areas. In many games, these already don't exist as free wandering creatures, but are instantiated on a random dice roll only when a player walks into the room. There's no need to provide rooms for them, as you can continue to instantiate them in the player's room after a "move".
18 Feb, 2013, Runter wrote in the 6th comment:
Votes: 0
In most situations I think it doesn't make sense.

There's a few options I would consider for savings.

1. Only include fields on the room structure which are unique or almost completely unique. Other fields I'd remove and build some type of associative array for many to one relationships to data. In other cases when a default value is mostly present I'd do the same thing, with rooms not in the collection having the default value.

2. Lazy load everything using an ORM. It saves you a lot of effort and from a development standpoint doesn't change the way you write your code.

3. Load areas that players are in. Make other areas completely inactive. This is appealing if your playerbase is small, or you have an excessive amount of content.
18 Feb, 2013, kiasyn wrote in the 7th comment:
Votes: 0
18 Feb, 2013, quixadhal wrote in the 8th comment:
Votes: 0
Heh, my machine already has 16G of RAM. :)

However, I'm not really thinking of the kind of paltry sized MUDs we use. I'm more thinking along the lines of infinite sized wilderness maps that get generated on the fly as people wander around, with hand-coded areas built in places that fit the landscape. It just occured to me that if the wilderness worked that way, why not just use the same technique for everything?

Lazy loading also works, if you do it by zone or "chunk". It's just slightly less predictable what the memory use will be. IE: How long until you unload stuff vs. how quickly players wander around.

Thanks for the feedback guys.
18 Apr, 2013, Nathan wrote in the 9th comment:
Votes: 0
It's probably worth noting that people congregate in an MMO in a spot where there is something to do. Wilderness areas are far more likely to be empty, excepting a few players going monster hunting, than are towns and cities with npc quest givers and shops. Many concepts are shared between graphical and text muds and an mmo is probably a good place to and look and see what works so you can implement in a text game, because those games have the money to engage in whims wholesale. By that I mean they can pursue an interesting idea to completion, easily, especially if it might be profitable or attract more players. Wilderness areas probably don't need much, unless they are special. This explains the use of systems that simulate the existence of rooms where an actual representation isn't as necessary.

What you propose is a completely room-less system (minus the "room" that encompasses everything else). Then you'd have virtual rooms for a player that defines what portion of that space they 'see'. Seems like a practical system if there ever was one. You could do away with the rooms and their object numbers, but you'd still need a way to bind properties, etc to a locational coordinate of some kind. I'm not sure how a directed graph would handle that… care to explain more?

Player's wouldn't be able to interact directly without their virtual rooms overlapping I assume. A good question is how you calculate that space around them and do you handle it differently if your game implements senses. Your sight might not be as keen as your hearing, and thus a way to handle what you can hear would extend further than the way to handle things you can see.
18 Apr, 2013, quixadhal wrote in the 10th comment:
Votes: 0
Not actually roomless…. that's a different beast entirely. If you're designing your game from the ground up, you can certainly go roomless and avoid the whole mess, for other messes. :)

This idea is more along the lines of using the existing room system in a more efficient way. All the combat code, communication code, etc… already expects the idea of a room container to handle deciding the list of valid actors and victims. It doesn't really care if the rooms are traditional hard-coded rooms that all get loaded as distinct objects, or if they're virtual things that get changed and reused on the fly.
19 Apr, 2013, Kline wrote in the 11th comment:
Votes: 0
I'm getting close to the point of needing to implement some type of "room" system in my little custom server. I've been thinking about a blend between traditional and wilderness / coordinates. Mostly by keeping a more traditional "fixed container" element of rooms but then maintaining an element of size/distance within the room. So it would be possible to do things like set off an AoE spell in a small group of 3 creatures even if there were 6 total in the room; yet the other 3 were far enough away. Maybe have light radius play into it to effect what/how/when you see exits. Dunno. Still undecided on it all so far.
19 Apr, 2013, Nathan wrote in the 12th comment:
Votes: 0
Kline said:
I'm getting close to the point of needing to implement some type of "room" system in my little custom server. I've been thinking about a blend between traditional and wilderness / coordinates. Mostly by keeping a more traditional "fixed container" element of rooms but then maintaining an element of size/distance within the room. So it would be possible to do things like set off an AoE spell in a small group of 3 creatures even if there were 6 total in the room; yet the other 3 were far enough away. Maybe have light radius play into it to effect what/how/when you see exits. Dunno. Still undecided on it all so far.


Hmm…I tried adding some coordinate stuff to mine, but it still feels hacked on. It needs more integration… Hex tiles as a coordinate model might work okay for AoE stuff, I think, since they would more closely approximate a circle. I figure you'd have to implement coordinate/? based movement then to navigate the rooms then, right? That and do you target an area or a creature?
19 Apr, 2013, quixadhal wrote in the 13th comment:
Votes: 0
One point worth mentioning here is that there doesn't NEED to be any distinction between room-based and coordinate-based, as far as the PLAYER is concerned.

In a room based system, you see a new description whenever you walk through an exit, and you see all the objects/npcs/etc that you can see, which are inside the room.

In a coordinate based system, you see a new description whenever you move a sufficient distance, and you see all the objects/npcs/etc that you can see, which are in a radius of your new position.

Targeting can be the same… you can target by thing, or you can target a distance in front of (or in a direction from) you. If it's room based, you'd see the effect hit some number of things in the room. If it's coordinate based, you'd see the effect hit some number of things in the radius of things you can see.

The only way it really gets weird is if you start trying to turn your MUD into a roguelike, and draw ascii maps or some such nonsense. Don't do that. If you want a roguelike, code a roguelike. :)
19 Apr, 2013, KaVir wrote in the 14th comment:
Votes: 0
quixadhal said:
One point worth mentioning here is that there doesn't NEED to be any distinction between room-based and coordinate-based, as far as the PLAYER is concerned.

A coordinate-based movement system isn't going to feel like a traditional room-based mud unless typing "north" instantly teleports you several dozen feet. At that point you've basically given up most of the benefits of a coordinate-based system.

quixadhal said:
The only way it really gets weird is if you start trying to turn your MUD into a roguelike, and draw ascii maps or some such nonsense. Don't do that. If you want a roguelike, code a roguelike. :)

We're not in the 90s any more. A lot of players expect a map - and they'll have one whether you want them to or not. However it makes no difference whether the mud is room-based or not.
19 Apr, 2013, Runter wrote in the 15th comment:
Votes: 0
Agree, maps aren't nonsense. If you want to force more exploration then use some type of fog that is only uncovered as you explore the rooms. Either way, I don't consider maps nonsense or a distinguishing feature of a roguelike.
19 Apr, 2013, quixadhal wrote in the 16th comment:
Votes: 0
I disagree that coordinate-based has to require a roguelike display. I think it's perfectly fine to type "north" and have your character start walking north. I don't expect the description to be printed unless it changes, and in that case, it looks pretty much like entering a new room, does it not?

I really didn't mean the kind of passive mini-maps many muds have. I meant making the map the focus of the game, which is turning it into a roguelike. If the players focus is all on the map, and the descriptions are just flavor text, why bother with them at all? If the game is a MUD, the map should be there as a navigational aid, not as a required focus to play the game.
19 Apr, 2013, Runter wrote in the 17th comment:
Votes: 0
I don't think room descriptions should describe locality. If I want to know what my surroundings appear to my character like then a room description is the right tool. If I want to navigate the world then a map is the appropriate tool. If most of your game, or a significant part of it, is navigating and walking around then I think you'd be right in coming to the conclusion that the way individual rooms are described is (as the should be) flavor text.
19 Apr, 2013, KaVir wrote in the 18th comment:
Votes: 0
quixadhal said:
I disagree that coordinate-based has to require a roguelike display.

Disagree with who? Who said that?

quixadhal said:
If the players focus is all on the map, and the descriptions are just flavor text, why bother with them at all?

Because it adds flavour.
19 Apr, 2013, plamzi wrote in the 19th comment:
Votes: 0
Nathan said:
Kline said:
I'm getting close to the point of needing to implement some type of "room" system in my little custom server. I've been thinking about a blend between traditional and wilderness / coordinates. Mostly by keeping a more traditional "fixed container" element of rooms but then maintaining an element of size/distance within the room. So it would be possible to do things like set off an AoE spell in a small group of 3 creatures even if there were 6 total in the room; yet the other 3 were far enough away. Maybe have light radius play into it to effect what/how/when you see exits. Dunno. Still undecided on it all so far.


Hmm…I tried adding some coordinate stuff to mine, but it still feels hacked on. It needs more integration… Hex tiles as a coordinate model might work okay for AoE stuff, I think, since they would more closely approximate a circle. I figure you'd have to implement coordinate/? based movement then to navigate the rooms then, right? That and do you target an area or a creature?


That's a big fundamental decision. It might help to start with sketching out the interface you want to have, whether it is textual, or graphical, or hybrid (or more than one of these at the same time). Having a clear goal in mind usually sets off a domino effect and determines any long series of choices you have to make. It's just that you have to do what few MUD admins do naturally, and that is to realize that the goal should center on the end user experience, client and server and all.

If I were designing a MUD world from the ground up, I would probably retain the room concept and try to present it to the end user as a series of "places" or "scenes". Within each scene, there probably won't be coordinates like Nathan was describing. It does feel hacked, and more importantly, it complicates things pretty drastically by adding the need for collision checks, capacity checks, etc.

For the world as a whole, I would consider having logical placement of "places", unless it improves the user experience to allow "jumps" in certain places.
19 Apr, 2013, Nathan wrote in the 20th comment:
Votes: 0
Runter said:
Agree, maps aren't nonsense. If you want to force more exploration then use some type of fog that is only uncovered as you explore the rooms. Either way, I don't consider maps nonsense or a distinguishing feature of a roguelike.


I suspect he meant something like showing a map in the room description or instead of descriptions. Is that the same thing you mean?
0.0/26