This goes back to an earlier discussion we had about the idea that rooms, simple objects, containers, mobs, etc., are all just things. There's no real difference between a backpack and a room, other than the room being very large. There's no real difference between a sword and a box, except that the sword has no exits and an inventory that's 0 in size. Mobs also act like containers that happen to have AI scripts attached to them.

If you design your system so that all these types of game objects share common structure, it becomes easy to make interesting things like a living room, which the players can attack from inside, or a giant monster that stuffs people into a bag it carries, or cursed weapons or armour that take control of the player under very specific (quest) circumstances.

You can also have fun with scale this way. A player holding a "labyrinth" game could cast a spell to shrink the party small enough to explore the game box, which itself could be in someone else's backpack as they travel around. Going the other way, a builder might very well be able to pick up buildings and move them around at will.

I think I suggested that the only real major change you'd need to do is have interior and exterior descriptions for everything. So, the default interior description of a sword might be "It's black, and you have no idea how you got here.", while the default exterior description for a room could be "A grassland room, containing Ned's Nut Shop".


And yes, the "room based" model is just that. Players and NPC's all exist in a container which is linked to other containers. A coordinate system is often imposed on the containers themselves, and sometimes extended to positions inside them, but it is the links between containers that make them rooms.

One blessing and curse of this is that you CAN create non-euclidean systems of rooms, if you really want to. Doing so with a coordinate-based system requires a bit more trickery.

The main problem that I have with this definition is that it does not mandate that rooms be a unique type of object. In my mind, a room-based design is one in which rooms are distinct from other objects in some way - generally because they are the only objects that can have links (exits) attached to them.

If you allow links to/from any game object with an inventory, there's no real difference between something called "a cardboard box" and something called "a grassy plain" (except, of course, the amount of stuff you can fit in the box vs. the field). I'm not saying this is a bad thing - it's actually pretty cool - but rather that when there's no real difference between a 'room' and anything else with an inventory, you can't really call the world design 'room-based'. And that, i guess, is my response to this comment:

Rooms don't even represent absolute geographical locations - their position in the game world is entirely relative to the positions of the rooms they're linked to. With the simplest scripting you can make a room represent a train, a car or even a horse - in some cases it's easier to use rooms to do this than it is to use objects/mobiles. In this sense, it's pretty silly to make rooms a special type of object, but that's what a room-based system is. At least, that's how I see it.

I'm inclined to agree. We clearly need to distinguish between MUDs where rooms as 'special' vs. MUDs that have rooms in the sense that people are in containers but otherwise these objects behave like any other.

But…

…this I disagree with, for the reasons I gave Elanthis (among others). The "grassy plain" can be a logical (intangible) construction that cannot really be picked up and moved (except perhaps by implementors) whereas the cardbox box is quite clearly a very tangible in-game object. These intangible objects (could) have a much more fixed notion of their spatial orientation; mountains and lakes don't tend to move around like cardboard boxes. (It would be amusing I suppose to have creatures that pick up mountains and move them, but in that case you're not so much moving a "room" as an entire geographical feature.)

That is - of course - entirely true. I guess I was making that statement assuming a system that would allow for room manipulation. I don't think I'd approach a container-based world in the way you described, though. Rather, I'd do something similar to what Quix described - with inside/outside descriptions, object & inventory sizes. Such an approach seems a bit less limiting that deciding that some objects are simply intangible.


This brings to mind that one episode of Futurama. "Correct! That box contains our own universe!"

I confess that I don't really understand the inside/outside descriptions. Isn't it always just the description of the thing that you are in? Would a room ever meaningfully have both? Why not have the sword's description be "it's dark" and the grassy plain's description be "it's grassy" and leave it at that?

I think that there are cases where the "intangible" approach is sort of unavoidable, for instance with a coordinate system. In that case you are grouping "coordinate cells" (or points or whatever) into commonly described units. In such a case, the grouping would be for things like description and navigation (e.g., "go living room" rather than "go 2 meters east and 1 meter north"). The notion of "room" would not apply in the sense of a container that has stuff in it; things have a position, and actions apply based on other things' positions, etc. I think that such a world is quite clearly very different from the "room-based approach" as you and I defined it.

I think that the concept of a "room" is a very useful one. Even in the grassy plains, it can be nice to navigate to places based on landmarks; a landmark can easily be considered a "room" in that it groups together places by description. (E.g., "You are standing on a hill with grass all around" vs. "you are standing at the tree in the middle of a grassy plain"). But the funny thing about such a system is that a 'room' might very well be some funny geometric shape with "holes" in it: you could easily imagine that there'd be one room (the "grassy plain") that "contains" (in the geometric sense, not literal MUD-container-containment sense) the "hill" and "tree" rooms. In other words, the notion of "room" becomes quite loose here. But it's still useful to have. It's particular useful to have as soon as you go inside (or in outdoors structures) and there are real "rooms" to speak of.

Oh topic, how we stray from thee…

You must be new here. :blues:

'sides I actually kinda think that this is relevant to a discussion of how one would add "rooms" to one's codebase. Although I suppose the original question is concerned solely with the standard room-based approach. Perhaps a charitable-feeling mod could split the thread.

Compared to your 5,500+ posts, I practically am new here.

So far as inside/outside descriptions… god, think like a programmer. Fine, you want some kind of container that can be carried and which can hold players. You have two options here. (a) Make a convoluted super-object that can be both a container and a room at the same time, and has two description and two sets of general attributes, and otherwise try to model your in-game "thing" as a single game object, or (b) just make two totally separate game objects, one being an item and one being a room, which are linked together logically.

One requires a lot of extra code for very little pay off while the other is just reusing the existing generic components you (should) have created in novel ways.

Given that this seems to be the only active MUD development discussion forums, I do not think that any development related discussion related even tangentially to the subject of the original post should be discouraged in any way.

There has been very little discussion that I consider useful to my needs, although I have found pretty much every post of interest. I'm going to go with a simple code defined room model to get something out there for anyone who in some universe want to use my codebase, and then once that is complete, do a completely data-driven one for myself. Ideally, I'd like to hook up OpenCyc, but the last time I tried it was just too complicated and undocumented – and didn't work on Vista.

In that case, what do you see when you 'look sword' while it's in your inventory? A better example might be a container object intended to represent a pub that is itself contained in (and linked to) our 'grassy plains' container object. When you 'look pub' while in the plains you see a description of the building from the outside (as if it were just another object that had been dropped there), but when you 'enter pub;look' you see a description of the bar, the dining area, etc. as if it were a room proper. Granted, the same thing can be achieved by adding a description to an exit in a standard room-based world, but there you go.


Any object with an inventory can contain any other object. Any object with an inventory can be linked to any other object with an inventory, allowing movement from one to the other. Any object designated a container can have other objects added to/removed from its inventory by objects not contained within it.

I don't think that's particularly convoluted at all - in fact it's fairly simple, really. I think it'd work pretty well with the component system you described in that other thread (unless I've misunderstood how that works).

The last room-based mud I worked on didn't actually have explicit exits, but it was still definitely room-based. Likewise, it's not uncommon to have 'portal' objects that are linked to each other, allowing players to walk into one and out of the other. Some muds might even want their players to have the option of climbing inside a portable hold, or the mouth of a huge monster, and be able to explore inside.


I'm afraid I disagree - a mud wouldn't cease to be "room-based" just because you add exit data to portals as well. A room-based design indicates the way a world is organised, not whether it literally has "room" object types.


True, perhaps I should have said "physical locations". I was trying to exclude coordinate-based muds that use transparent containers to group together nearby creatures.

No, you're definitely thinking along the right lines from a component perspective. There's more to designing the engine than just componetizing everything and then slapping them together willy-nilly, though. :)

The main thing that got me riled up was the inside vs outside descriptions. You don't need two descriptions, and even if you had them… where would you put them? Would the ContainerComponent have an innerDescription while the (almost universal) InspectableComponent have the outer description? All of this data and logic has to be put somewhere.

The problem with a generic ContainerComponent is that you still need actual game logic tied to _archetypes_, not components. Otherwise I could go buy a coin purse and crawl inside of it. Components break down the code portions of your game objects, but your game logic is still going to depend a lot on what the actual objects _are_. In many cases you can define this by whether or not a particular game object has a particular component (if the object has the WeaponComponent, it's a Weapon, for example), but you still have to actually define what those relationships are, what they mean, and what purpose they serve.

Saying you have a ContainerComponent that can hold anything is a fun little thought exercise, but there are a _lot_ of problems with the concept when you get into actually coding it. At best you end up with a ton of flags deciding which components are allowed to existing within a particular instance of ContainerComponent (is it big enough to hold people? is it allowed to hold people? is it allowed to hold items?). On the other hand, with a separate Room and Container component setup, the logic becomes way easier. The Container can hold anything that has an ItemComponent and a Room can hold anything that has an ActorComponent. (Perhaps Room also holds Items, or every object that has a Room also has a Container for the floor). When you're talking about a satchel, you also have a vastly different UI than a room. The satchel has simple look, get, and put commands. The "portals" you use to transfer items into and out of such a container are implicit in the container's existence. With a room, you've got a very different situation, where there are no implicit entrances or exits, you expect a lot more detail out of the exits that exist, and the entire command set and UI changes from "easy item management" to "easy navigation."

When you start putting too much functionality into a single component, you're just as screwed as if you had put everything into a single GameObject class.

There is then the further point of what a component-based engine really is. You don't start out with this idea of game objects having components. You start out with the whole engine being components. Your network/TELNET component is separate from your file I/O component is separate from your game logic components is separate from your account/login component, and so on. That is largely how all engines (or MUD codebases) are written anyway, except that sometimes the lines get really blurred because the components were not clearly defined. Fundamentally, though, that's how it all works. It's a very natural way to design a system, which is why is extends so well to game objects. It doesn't stop with the code, however. Your entire virtual world is a component system, which each game object being a component in a larger system. Once you realize that, you open yourself up to a lot more possibilities, including the idea that sub-systems within the _environment_ (not the code itself, but the world design) can be comprised of components, and are components themselves. So your idea of a pocket universe inside of some kind of mundane trash can container or whatever doesn't need to be composed at a code level in a single game object, but instead can be an entire sub-reality of the virtual world composed of multiple game objects. The trash can is a game object, the room inside of it is a game object, the talking statue inside of that is a game object, and the portal that connects the room to the mysical land of the faeries is a game object. You actually have WAY MORE power this way than if you tried combining just two of those game objects into a single game object, especially when you hook it up with a good message system that lets objects communicate in expressive ways. Plus, since your code is still comprised only of smaller, mostly self-contained Component objects (the ones mixed into a GameObject) that don't have a lot of overloaded functionality, your code is cleaner, easier, and more flexible; you can start thinking about all the ways you can reuse and extend the base Container instead of all the ways you can cram a new set of possibly contradictory functionality into a single Super Container. :)

I do in fact have both inside and outside descriptions in my mud, depending on whether you're looking at the thing from the outside, or whether you're looking from inside - I don't want to show people the interior of a hut while they're standing outside of it, for example.




"Q: How do you put a giraffe into a refrigerator?
A: Open the refrigerator, put in the giraffe, and close the door."

If your only limitation is "only inanimate objects can be placed inside the purse" then you end up with the situation whereby you can place a life-sized human statue in the purse, but an ant won't fit. You could perhaps also say "only coins can be placed in the purse", but that doesn't really make any logical sense, nor does it address the underlying problem.

Clearly some sort of size check is required. But that same check would work just as well for creatures as it would for inanimate objects - meaning there is no need to differentiate between rooms and containers (at least for this). The logic is in fact easier this way because the solution is generic. You don't have to worry about taking a skeleton out of a coffin, animating it as an undead, and then being unable to fit it back into the coffin - if it was big enough to fit in the coffin in the first place, then it can go back inside, unless you cast 'enlarge undead' on it first.

Oh yeah… :bonk self:
I'm still not entirely convinced that this is the right approach (I have some reservations along the lines of what elanthis said, but I don't have them as strongly) but it makes a lot more sense now. I'd have to figure out the "essential difference" between containers and rooms first. I guess it depends a great deal on what exactly you're using rooms to mean.


I agree with KV that this check feels a little too simple. Generally speaking I think it's usually ok, and that might be "usually enough" that it would suffice. But if the whole point of this approach is to provide a relatively rich model, then presumably we do care about large and small actors and objects.

I really don't see why you'd need much "extra" code to support being able to use objects as rooms. I mean, right NOW half the code is duplicated and special-cased BECAUSE rooms and objects are treated as different kinds of things.

A room has exits. An object doesn't. A container object does. Soooo, if all objects have exits, you just don't assign any to non-containers.

An object has hit points. A room doesn't. Why not? Give a room lots of hit points and see what happens when players attack the raft they're on. If you really don't want to deal with players destroying the environment, set the immortal flag so it's not attackable by default.

What's wrong with crawling inside a coin purse? Provided you are small enough to fit, I don't see it as a problem.

Inside/Outside descriptions are just to prevent you having to make the life of your builders hell. If you do a "look box", you expect to see the outside description of the box. If you somehow got inside the box, you'd kindof expect to see the box described more like a room, no? Where would I put it? Where's the description now? Where are the day/night descriptions?

As far as the "is it allowed to hold X" fiasco….. first question will filter 90% of the normal situations you'll encounter. Will it fit? If not, you're done. If so, you *may* want to have flags to make areas accessible only to certain players/mobs, but there's no reason that can't also work for bags and boxes. You buy a really expensive sack from a vendor, who has cast "repel insects" on it. Now, the sack can't be entered by anything of type insect. So, when you give it to your friend who plays a giant ant, he may be bummed that he can't shrink himself and sleep in his new sack. OTOH, he might be happy that the NPC insects you created that steal food can't get his. Yes, without the artificial room/object split, you could easily code pests and other vermin that can hitch rides and/or loot your belongings.

BTW: I've seen people empty their (larger) purses and find dead moths and grasshoppers, which presumably were alive when they entered. I guess they must be uber-hax0rz. *smile*

Sorry that I don't subscribe to the God likes Object Oriented Programmers best model of thought. While good OO code can be a blessing, it can also be overused to the point that you've spent so much time and effort designing the "perfect" object system, that you no longer feel like writing a game with it.

Perhaps it's easier to handle than I think it is. My gut feeling is that the code will end up convoluted and the MUD confusing, but to quote one of my industry-hardened game professors: "meh, just try it, you'll figure out if it works or not." :)