18 Jan, 2010, donky wrote in the 1st comment:
Votes: 0
Hi,

Generally, I'm building up my MUD framework bit by bit. Most recently this involves working on general systems not directly related to gameplay. However, someone emailed me several weeks back and asked if I would add a standard room-based world model. This is not something I planned to do, but it occurs to me that it should be pretty straightforward and would be a good exercise of the framework, and the way it allows different world models to be supported. I currently have a working tile-based world, more or less working support for a roguelike world and some old code that places the player on a fractally generated planetary surface.

Anyway, back to the subject at hand. I'm appreciate it if people could read over what I have in mind for the room-based world, and add anything that pertains to the state of the art or best practices for how rooms are constructed (feature-wise, rather than implementation-wise) and how players interact with them.

Saying that I have logged into a MUD as a player since 2000, would be generous. I did log into Midkemia Online and play through its character creation an hour or so ago, but that did not seem to add anything over and above what was present back in the day. Given what I saw of the other MUD types, my interest and experience is LP-centric. So, with that in mind, here's my idea of the core of a room-based model. I'll use Python pseudocode for illustration, but this is not how I would actually implement it as it is more a Python representation of how it used to be done in LPC.

A room has a short description (one sentence), a long description (one paragraph), exits linking it to other rooms and objects which may be present within it. For the purposes of avoiding writing my own room description, I took this one from the Discworld room description commandments page.

class SomeRoom(Room):
def Setup(self):
self.SetShort("The marketplace.")
self.SetLong("This is a large marketplace. Giraffes are bouncing on the stalls " \
"and pink elephants in tutus are waltzing gently around the villagers " \
"as they shop.")
self.AddExit("north", "marketEntrance.py")
Aspects of the descriptions may be elaborated on as details. Ignore that the giraffes and elephants should actually be proper npc objects within the room.

self.AddDetail("giraffe", "Long necked and fat, the giraffe demonstrates more " \
"agility than gravity should allow.")
There would be two commands, brief and verbose (the default). These would be linked to the different movement modes, brief being the display of the short description on movement into a different room and verbose beng the display of the full description on movement into a different room. So in brief mode..
Quote
> south
The marketplace.
Exits: north.
>

And in verbose mode..
Quote
> south
The marketplace.
This is a large marketplace. Giraffes are bouncing on the stalls
and pink elephants in tutus are waltzing gently around the villagers
as they shop.
Exits: north.

And to demonstrate details..
Quote
> l giraffe
Long necked and fat, the giraffe demonstrates more agility
than gravity should allow.
>

And then for the objects within the room, there might be special spawning systems for different types of object. So, instead of..

self.AddObject("merchant.py", 5)
.. to get five merchants spawned, and respawning. NPCs would instead be spawned through a custom system..

self.AddNPC("merchant.py", 5)
With objects present in the room featuring in a extra line of description..
Quote
The marketplace.
This is a large marketplace. Giraffes are bouncing on the stalls
and pink elephants in tutus are waltzing gently around the villagers
as they shop.
There are five merchants here.
Exits: north.

So, ignoring implementation details and concentrating on supported features for builders, have I left anything out with regard to the state of the art in room-based MUDs?
18 Jan, 2010, elanthis wrote in the 2nd comment:
Votes: 0
Quote
have I left anything out with regard to the state of the art in room-based MUDs?


Yup.

I don't know if it's even possible to enumerate it all, though. There are so very many things you can do with a room-based MUD, and most of the ideas have been tried somewhere before or not.

I recommend you just keep it simple and basic, and then only add a feature if and only if an actual builder on your actual codebase comes around and asks for it.
18 Jan, 2010, Idealiad wrote in the 3rd comment:
Votes: 0
Most of the extensions of the mud Room I've seen deal with sub-rooms, sub-room coordinate space, etcetera. None of that in my opinion works very well.

I suggest investigating the Room model of the two most popular interactive fiction languages, Tads 3 and Inform 7. There are some simple things they do that very handy, like rooms grouped into regions, room parents/inheritance (also in mush and probably LP, and as prototypes in some bases like NakedMUD I guess), backdrops running through rooms, room senseconnecters, etcetera.
18 Jan, 2010, donky wrote in the 4th comment:
Votes: 0
Let me try a slightly different question, if you could have the minimal set of functionality for rooms in your MUD, what would it be?

Forget all the wanky things like sub-room coordinates.
18 Jan, 2010, KaVir wrote in the 5th comment:
Votes: 0
donky said:
Let me try a slightly different question, if you could have the minimal set of functionality for rooms in your MUD, what would it be?

Off the top of my head:

1. Easy to remove rooms entirely without having to dig through other parts of the mud.

2. Compatible with standard game mechanics (eg you should be able to attack rooms, pick them up, etc).

3. Provide a generic way of adding custom properties and attributes.

4. Flexible support for customisable exits and exit names.

5. Supports scripts and dynamic descriptions.
18 Jan, 2010, Mudder wrote in the 6th comment:
Votes: 0
KaVir said:
2. Compatible with standard game mechanics (eg you should be able to attack rooms, pick them up, etc).


I could imagine a giant picking up a room and throwing it, it's cool but that seems like it would only complicate things needlessly. How would you use this functionality KaVir?
19 Jan, 2010, KaVir wrote in the 7th comment:
Votes: 0
Mudder said:
KaVir said:
2. Compatible with standard game mechanics (eg you should be able to attack rooms, pick them up, etc).


I could imagine a giant picking up a room and throwing it, it's cool but that seems like it would only complicate things needlessly. How would you use this functionality KaVir?


For combat sequences like this:

Quote
You soar down from the sky.

You beat your wings steadily, keeping yourself airborne.

You breathe a blast of fire at the small farmhouse, blowing the top of its roof off!
The farmhouse burns down, leaving behind only a smoking ruin.
An angry man clambers out of the wreckage.
An angry man draws his cudgel from his belt with his right hand.

You land, your clawed feet digging into the ground.

Your wings stop beating, and fold up behind you.

An angry man swings at your face with his cudgel.
His bash bounces harmlessly off your rotting red scales.

You grab the angry man with your front right foot and bite his head off!


Or this:

Quote
You shoot an arc of black lightning at the watchtower, burning its chimney.

You shoot an arc of black lightning at the watchtower, blowing a gaping hole through its wall!
A young watchman dives out through the watchtower's doorway.
The watchtower explodes, leaving behind only a smoking ruin.

A young watchman crashes to the paved street.

You close your right hand into a fist.

A young watchman clambers back up to his feet.

The young watchman draws his longsword with his right hand.
The young watchman unslings his target shield from across his back with his left hand.

The young watchman's heart erupts from his chest and flies to your hand!
The young watchman's body goes limp.

The dead watchman crashes to the paved street.

You hurl your torn-out heart at the dead watchman, hitting him in the face.
19 Jan, 2010, elanthis wrote in the 8th comment:
Votes: 0
Quote
I could imagine a giant picking up a room and throwing it, it's cool but that seems like it would only complicate things needlessly. How would you use this functionality KaVir?


If you code your architecture intelligently, this is not hard at all. Look at the recent thread in which I brought up component architectures.

That said, the way I would code features like KaVir mentions is not to make rooms attackable, but to add room details (something I might add to a list of basic room necessities). Room features are basically objects/items that are (mostly) static and fixed to the room. Things like furniture, doors, tapestries, clocks, etc. It lets you do a lot of nice things, including examining various parts of a room, storing items in furniture, or having secret passages that have to be found by interacting with the room itself.

Combine that with a flexible portal (door/exit/direction/whatever) system that handles more than just directional exits. Allow for example crawl spaces that in addition to being "north" are also flagged as hidden, requiring crawling, require moving/destroying a blocking object (including doors), and so on. This makes the world more interesting and you get most of the benefit of sub-rooms without the complexity.

So far as sub-rooms being complex, I disagree. They're complex only because most MUD programmers have absolutely no ****ing clue how to design a UI, text-based or otherwise, and make using sub-rooms and the like far more complex than should be necessary. If your UI requires more than the cardinal directions and a "go" command, you've probably crossed the line. Even special exits that require crawling or the like should be usable with a simple "go <foo>" that automatically puts the character in the crawling position instead of requiring the player to type out a sequence of commands. Even better, make sure any common exits (if not all exits) have a direction attached, and make the "go <foo>" syntax unnecessary for basic navigation. If you have sub-rooms, make sure that "go <person>" or "go <object>" intelligently navigates the player to the proper sub-room instead of requiring him to type out a sequence of commands to get to something he can already plainly see. The code to support sub-rooms is almost trivial once you have a decent portal system in place with an event/message-based internal architecture (which you should have even without sub-rooms).
19 Jan, 2010, Confuto wrote in the 9th comment:
Votes: 0
If you're going to add things like attackable and gettable rooms, you may as well just dispense with the room-based approach entirely.
19 Jan, 2010, JohnnyStarr wrote in the 10th comment:
Votes: 0
Confuto said:
If you're going to add things like attackable and gettable rooms, you may as well just dispense with the room-based approach entirely.


Or:

Maybe you could have rooms and objects inherit something like "GameObject" or what have you, with the built in functionality to be
obtainable. You probably know this of course, but it's the first thing i thought of.
19 Jan, 2010, David Haley wrote in the 11th comment:
Votes: 0
Confuto said:
If you're going to add things like attackable and gettable rooms, you may as well just dispense with the room-based approach entirely.

What exactly is a "room-based approach"? Is a MUD with rooms in which people can be a "room-based MUD"? This isn't a facetious question really; it's not clear to me what you mean by "room-based approach". I'm guessing that you mean something like the Diku family, which makes extremely strong assumptions about what rooms mean; are you generalizing that to rooms in general, or something else?
19 Jan, 2010, elanthis wrote in the 12th comment:
Votes: 0
Quote
Maybe you could have rooms and objects inherit something like "GameObject" or what have you, with the built in functionality to be
obtainable. You probably know this of course, but it's the first thing i thought of.


While that is in itself almost obvious (all your game objects should be an instance of a game object class, mostly because you need it for good debugging and lifetime management code), please please please checkout the thread I brought component architectures up in. The simple approach you seem to be suggesting is exactly what has been ****ing over game engine architectures for years. Go ask any developer who's worked with the Unreal Engine for example as to why your suggestion is worthy of being dragged out back and shot. :)

Basically, with your approach, at some point any and all interesting functionality (and hence all supporting data members) end up in GameObject, and it turns out that every single little object in your MUD takes up multiple kilobytes of data, your virtual function tables are big enough to cause cache misses all on their own, and the documentation for GameObject becomes a huge monolithic monstrosity. Component architectures let you break up your GameObject sub-classes into self-contained components of data/logic that can be combined in any way, so objects that need to be attackable can include the necessary AttackableComponent and those which do not need to be attackable pay zero cost for the existence of the component. It's a little more complex up front but once you wrap your head around it and start using it, it actually becomes way easier to work with than trying to figure out how to fix all functionality into a strict hierarchy of game object class inheritance. You can even do dynamic component systems relatively easy that make development iteration a bit quicker, or you can just have a (flat!) inheritance set from GameObject that pulls in the necessary components for every distinct type of game object your design includes.

There really shouldn't be anything in your GameObject class besides the things that every last single game object definitely for-sure really actually needs to have for the architecture to work, which basically comes down to component management, unique identification, memory/ownership tracking, and possible some debugging/editing helper facilities. Everything related in any way to actual game logic should be moved out.

You can do a hybrid approach, but that means all game logic ends up in your GameObject descendents and components, and not in GameObject itself, ever.
19 Jan, 2010, David Haley wrote in the 13th comment:
Votes: 0
elanthis said:
please please please checkout the thread I brought component architectures up in

It would be most helpful to provide an earl, plox. :wink:
Just because I'm feeling nice (and mainly because I think it's an interesting post), here's a link. There's some further discussion – and no, I'm not the least bit biased because I wrote some of that further discussion. :tongue:
19 Jan, 2010, Idealiad wrote in the 14th comment:
Votes: 0
Mudder said:
I could imagine a giant picking up a room and throwing it, it's cool but that seems like it would only complicate things needlessly. How would you use this functionality KaVir?


This sort of goes beyond the idea of just picking up rooms or attacking them – it points out that rooms should be nestable rather than always connected at the edges.
19 Jan, 2010, David Haley wrote in the 15th comment:
Votes: 0
Idealiad said:
This sort of goes beyond the idea of just picking up rooms or attacking them – it points out that rooms should be nestable rather than always connected at the edges.

Yes. The idea is that rooms are "game objects" just like any other, and there's really little reason to treat them as remarkably special things. They're really just containers that happen to have exits to other containers.

You need to get more careful when rooms matter spatially. For instance you might have a spell that affects all things within 50 feet; that radius might cross room boundaries. So you need to start having some idea of where things are. This distinguishes rooms from normal containers to some extent, where (almost all of the time) all you care about is that thing X is in thing Y.
19 Jan, 2010, elanthis wrote in the 16th comment:
Votes: 0
Quote
You need to get more careful when rooms matter spatially. For instance you might have a spell that affects all things within 50 feet; that radius might cross room boundaries. So you need to start having some idea of where things are.


Assuming a classical room-based/Diku layout, that is just horrible UI. If you are sticking with classical rooms, the only area of effect you should ever have is a room. If you want to go with volumes and areas and such, you really should be making a graphical game, or at the very least a coordinate-based MUD.
19 Jan, 2010, Idealiad wrote in the 17th comment:
Votes: 0
Separate from the idea of room size, most DIKU-likes implement things like scan/peer/survey and sometimes missile combat from one room into another successfully enough. I do agree that ranged combat is far, far preferable in a coordinate based mud.
19 Jan, 2010, David Haley wrote in the 18th comment:
Votes: 0
elanthis said:
Quote
You need to get more careful when rooms matter spatially. For instance you might have a spell that affects all things within 50 feet; that radius might cross room boundaries. So you need to start having some idea of where things are.


Assuming a classical room-based/Diku layout, that is just horrible UI. If you are sticking with classical rooms, the only area of effect you should ever have is a room. If you want to go with volumes and areas and such, you really should be making a graphical game, or at the very least a coordinate-based MUD.

I'm not sure why you made that assumption, but regardless I disagree. Even with a coordinate-based MUD it makes all kinds of sense to have things that contain things, even people. A trivial example is any form of vehicle; this is an object that can be entered, picked up, destroyed, blablabla. It is a "room" for all intents and purposes (or maybe even several!).

Even with a coordinate-based MUD, it can make all kinds of sense to group coordinates into "rooms", if anything precisely because it simplifies the UI. You were talking about this yourself earlier, w.r.t. clear ways of entering and leaves "places". With coordinates, what's easier: "walk to X/Y" or "walk to inn"? While there are good reasons to want the former from time to time, having the latter seems ridiculously useful for very many purposes. Heck, even "walk north" would make all kinds of sense: it would move you to the next logical unit to the north.

In other words, rooms can be highly relevant as logical groupings. It is very true that a logical grouping of a bunch of cells is different from a carriage that can be entered; the carriage is an actual thing whereas the grouping of cells isn't a tangible in-game thing that can be manipulated (at least, not in the same way).
But this is precisely why I said that you need to be careful. :smile:

To put it simply, having given more context: when spatial relations matter, you need to be very careful about the distinction between tangible places and intangible (logical) groupings.
19 Jan, 2010, Confuto wrote in the 19th comment:
Votes: 0
David Haley said:
What exactly is a "room-based approach"? Is a MUD with rooms in which people can be a "room-based MUD"? This isn't a facetious question really; it's not clear to me what you mean by "room-based approach". I'm guessing that you mean something like the Diku family, which makes extremely strong assumptions about what rooms mean; are you generalizing that to rooms in general, or something else?

I would define a room-based world design to be one that:
a) Treats rooms as special and different from regular objects; and,
b) Uses rooms as its main representation of locations within the world.
While I'm sure there are plenty of holes in this definition, it seems logical to me that a room-based approach is one in which rooms (whatever they are) are unique in some way and define the way location is represented to the player.
19 Jan, 2010, KaVir wrote in the 20th comment:
Votes: 0
Confuto said:
I would define a room-based world design to be one that:
a) Treats rooms as special and different from regular objects; and,
b) Uses rooms as its main representation of locations within the world.

What about MOOs, where 'rooms' and even 'exits' are regular objects?

Personally I would consider a room-based world to be one in which geographical locations are represented by a series of containers, with movement across the world requiring you to teleport between containers via (explicit or implicit) exits.
0.0/36