Hey folks. I know some MUD's have done this (specifically GodWars 2), but I was unable to find any snippet-like things, so I went ahead and made my own code to dynamically generate a room description for a room that has none specified by its builder. I know it compiles fine and I've strolled around my place a bit without seeing any errors, but I'd love for anyone to offer their feedback, ideas for improvements, criticisms, whatever.
This code generates room descriptions such as:
Market Square
[Exits: north east south west] [Vnum: 401]
You are walking across the street. The street continues to the east, south and west. Immediately to the north is a room.

[Exits: north south west] [Vnum: 917]
You are flying above rolling hills. The hills continue to the north, east and west. In the distance to the south is a street.

http://www.mudbytes.net/pastebin-29627

Looks good! Some code style comments:

- The constants should be just that, constants, not things on the stack in the function.
- Various things can be split up into helper functions. For example, the "you are <x>ing across" could be moved to its own function. This increases clarity of the main function's control flow.
- The four scan sectors could be a for loop, but not a big deal.
- I would document what the i *= 2 is about. But…
- …for your for loops, you don't really need two parallel counters. Just use one, and multiply it by two when you need the flag value.
- I would document why you choose 15, or list it explicitly as the disjunction of exit directions.
- The bit about continuing to the x, y, z, etc., could/should be encapsulated as a function or other loop, which would make it easier to handle new directions. (Note that the blocks are very similar.)
- Line 101 is hard to read.
- I would document the return value of the recursive function.
- You're using the wrong line ending: it's \r\n, not \n\r.

Will that work? Bit 3*2 would be 6, when you really want 2^3

Edit: Side (related) note: I think your iteration through bits is extremely clever :)

you could do something like

for ( i = 0; i < NUM_BITS; i++ )
  int bit = 0 << i;

or something?

i dont remmber how bits work :P

My first thought, looking at your samples, is automate "across". "…walking across a field" is okay, but "…walking across a forest"? For that matter, unless you're going from building to building, you're more likely ".. walking down a street".

Second thought, mention the room name rather than saying "…to the north is a room".


Nice job. I've done this in mushcode, but that's meant to handle strings. Never dared try it in C.

I had a stab at dynamic descriptions in GroovyMud, just to occupy my weekend. They seem to be incredibly complicated if you go in to any kind of detail and you can wrap youself up in ifs and whens and so on the more complex the description becomes.

I used the Groovy templating engine (there are c++ equivalents: http://code.google.com/p/google-ctemplat... to name but one) to help me, but still had the same sorts of issues. I think keeping descriptions reasonably short works well, as in GW2 otherwise you tie yourself up in hard logic which isn't nice to look at.

There is this Rom snippet which generates room descriptions based on terrain type which you may or may not find useful.

Nakedmud includes code to generate readable exit strings, although it's not very sophisticated. I don't use it but I think it just takes the direction and the name of the exit it leads to and prints a "Continuing south takes you to blah blah" or if the destination room has the same name as the current room something like "Blah blah continues north". It also handles open/closed exits. The relevant code is in inform.c.

Sorry, yes, I meant to the power of 2, not just multiplication. And this is equivaelent to 1 << i (because 0 << i wouldn't be shifting any bits).

Thanks for the comments, all.

I'm sorry, but I don't quite grasp the difference. Would you be happy if I defined the character arrays outside of the function, removed the const part or both? :grinning:


Davion and Kiasyn got to this before I did, but I can't really just do that, I'd have to look up bitwise arithmetic or look up the C library with the exponents function, either of which is more complicated than using a second counter was. It did occur to me, and I was, like, oh screw it…


Yeah, I thought of this as I was heading to bed, but I had work this morning and couldn't spend any more time on it. I'll be adding that in tonight.


I'm sorry for doing it wrong, but that's the way it is all through the rest of my code (Diku/Merc/GodWars). As far as my education is concerned, the right line ending is endl :wink:



Good call. I made the arrays to describe all the other stuff, then spent time coming up with a generic verb that kinda worked all the time instead of just doing what you suggest. I'll do that.


I'm a bit less convinced on this one. "Far off to the north is Deep in the Spider Forest" as opposed to "Far off to the north is a forest". Or do you suggest that specifically in the case of indoor sectors which would be an actual room?

Sorry, yes, I meant just declare it outside the function, so that the memory for the arrays isn't allocated on the stack unnecessarily. (I suppose it depends on what your compiler's optimizer is doing, though.)

Oh, and the bitwise math was given just above, perhaps I posted while you were writing. (Sorry about the earlier mix-up… that's what happens when I post at 2:30am after a long Friday night :tongue:)


It's not your fault; Diku/Merc/family are notorious for getting it wrong all throughout the code. So much so that many clients implement workarounds to fix it when necessary. :smile:

Some of the GW2 descriptions can actually get quite long, but (much like the approach I discussed for generating character descriptions) I've found the easiest way it to assemble them from a series of sections. The method I use for this is as follows:

Section 1: Viewer's position (standing, walking, flying, etc), season and terrain.

Section 2: Time and terrain.

Section 3: Weather and terrain.

Section 4: Optional hand-written area description (season and day/night specific).

Each of the above usually consists of a single sentence, but can consist of more, and sometimes result in fairly lengthy descriptions such as:

You are walking through Whispering Wood, the leaves on the trees a mottled brown from the onset of autumn. Many leaves have already fallen to the ground, and they crunch beneath your boots with every step. The sun is beginning to rise on the eastern horizon, its red glow barely visible through the tall trees. Flashes of lightning and the rumble of thunder fill the night air, framed against the backdrop of incessant rain which falls through the tree branches overhead before pattering on the ground. Your cloak flaps wildly in the wind, providing little protection against the pouring rain. The trees in this part of the forest are tall and sturdy, their great trunks towering high above you.

So tempted to start a religious debate on building…..use of the word 'You' in room descrips…..but, I shouldn't do that, right?

These are dynamic descriptions, not static. Those arguments don't hold water here.

I agree. "You" has no place in most static descriptions, but if it describes what the character is actually doing, then it's fine and sometimes even quite appropriate, as it can avoid far more awkward phrasing.

I implemented Sandi's suggestion to change the preposition based on sector type, and I condensed some of the code using the leftshift operator. Is there some reason, however, why it doesn't seem to work with parentheses? I tried to get rid of the j counter in my last loop by incrementing i from 0 to 3 and then checking for

if (!IS_SET(similar_exits, 1<<(i+1)))

and that didn't work. I then thought maybe the bitwise operator in IS_SET was getting performed against 1 then the whole thing was leftshifting i+1, so I tried writing out

if (!(similar_exits & (1<<(i+1))))

and that still didn't work, so I've left the additional counter variable in there unless someone can offer an explanation of why those evaluations aren't getting the answers they should.

These descriptions will never be as florid as the ones in God Wars 2 unless I largely rewrite the Diku room data - I've seen KaVir's posts on how he made his area tiles so that his MUD knows the difference between a pond, a river that flows north and a part of the ocean. Diku just knows…you have a room with water in it. I'm trying to do the best I can with what I have :grinning:

I have something between a notion and intent to add in a descriptive sentence depending on the sector type and the current weather/time of day - "You are walking across a lush, field. Raindrops glisten on blades of grass in the moonlight."

Right now, the output is still not perfectly efficient English, but is much less stilted than before:
Western Road
[Exits: north east south west] [Vnum: 440]
You are walking down the street. The street continues to the east and west. Immediately to the north and immediately to the south are some hills.

Any other thoughts or suggestions are welcome.

http://www.mudbytes.net/pastebin-29627

"You" also has different uses. Some remain bad. Telling the player what they think or feel is bad. Telling the player what they are in a physical sense is expected (the player doesn't get to decide if he's a 50-story fire-breathing dragon; the game mechanics and rules do), telling the player where he is at is fine (again, game mechanics determine location), and telling the player what he is actually doing is already widely accepted (many games say things like "You attack the orc" instead of "YourName attacks the orc" because it's more natural and immerses the player into the action better), telling the player what his condition and status is is fine (e.g., saying "you walk east" if the player is walking east, or "your boots" if the player is wearing boots, etc.), and forcing an action that is a guaranteed response to an event (e.g., "you fall into the pit" is quite acceptable, because it makes little sense in most games to give the player the option of falling into the pit when the trap springs under his feet).

The bad examples are the emotional descriptions and forced reactions ("you jump as a fox darts out of a bush" is bad), in no small part because a forced reaction implies an emotional response (jumping at the fox's movement implied skittishness, fear, anxiety, edginess, or any of a number of other similar moods and feelings).

Essentially, uses of "you" that dictate the mechanical state of the simulated environment the player is in are fine, while uses of "you" that dictate the mental state of the player or his alter-ego are not fine.

It can get a bit fuzzy when you have effects or spells that in a mechanical sense are supposed to alter players' minds. I strongly feel that in those cases, the game should attempt to distort the players' perception of the world in order to get the player to _actually_ think what the mechanics want him to think, rather than just trying to tell the player what he thinks and force him to play along.

The recent game Batman: Arkham Asylum managed to pull that off. I will leave the specifics out to avoid giving spoilers, but the Scarecrow in several scenes actually made me question MY sanity. Not Batman's sanity, not the sanity of the avatar I control, but my own personal Sean sanity. It was only for a couple seconds before I realized what was going on, but to achieve even that is pretty damn impressive. And that's what every game designer should strive for if he's going to have mechanics that affect the player character's mental state, rather than pure dictation and mechanics-enforced fiat that the player is simply forced to accept even if he isn't being immersed into the environment itself.



Name the rooms better, or provide alternate names/mini-descriptions for that specific feature. If you want to have good, descriptive, useful English output, you have to put in the effort on both the code side and builder side to pull it off. It is, in my personal opinion, very much worth that effort. These days with the ever-widening gap between descriptive powers of plain text and modern graphical engines, and the increasing ease with which artistically unskilled people can contribute to graphics-heavy game area design and layout, it's pretty important to take that plain text and make it as immersive and descriptive as possible (without overloading the player, of course). A little extra work to be able to help the player mentally visualize an area without a means to richly draw that area is every bit a good idea. :)



Avoid the verb unless the player is actually performing an action. That also simplifies the English pecularities that Sandi brought up. It's a lot easy to just say "You are standing on the street" and not worry about all the different ways the player can traverse the street. Plus most other room types will work pretty well with a simple "You are standing on," "You are standing under," "You are standing in," etc. You can replace the "standing" bit with the player's position status (standing, sitting, laying, flying, floating, hovering, hiding, dancing, whatever).

If you do want verbs, you can quickly get yourself into trouble. Should the player "walk down the street" when he moves to other positions on the street but "walk across the street" when entering a door on the side of the street? Does a flying player "duck under the doorway" when he moves between rooms, or does he just "zip through the door" ? What about relative speeds? You have far more variables with verbs than you do with describing static positions, so unless you want a LOT of extra work, don't bother.

It's the same as graphical games, really. Good graphics don't make a game good on its own, but bad graphics limits the game's potential severely. Having great and perfect English won't make your MUD great, but bad English can really hurt it. You're better off with mediocre normal MUD style output that the player can at least expect to be mediocre MUD style output, rather than pull the player in with beautiful prose and then occasionally shatter the immersion when a big grammatical issue pops up and donkey punches him in the face. ;) Just like cartoony graphics that have a lot of style and beauty can offer a better play experience than realistic graphics that fall short of true realism, controlled and well phrased English offers a better play experience than "real novel" prose that falls short of natural prose. Those cartoony graphics are very very good graphics, not bad graphics, but they're still quite different than realistic graphics. Likewise, controlled prose can be very very good prose, not bad prose, even though it's very different than the kind of writing you see in a novel.

I honestly think, if you put a little blurb explaining it's a bit iteration, your previous code was fine. It's much more readable than… that :P.

I don't agree with that. I don't see any problem inherent with the word 'you', nor do I see any problem inherent with the use of emotions. The only problem I see is with making immersion-breaking assumptions about the viewer that don't necessarily hold true.

If your mud supports the mechanics for a phobia system, and you know that the character is afraid of foxes, then I see no reason (other than personal preference) why you shouldn't use that information in descriptions.

Yes, only in the case of indoor rooms. I don't remember if you got "outside" on my MUD, but in the town you can see this done as "signs". I did it after the building, and had very few places where it was awkward.

You would have also noticed above the room name is the 'sky desc' with the weather. I did it this way because the sky's the same everywhere, and it gets very repetitive when traveling to start each description with "The sky is clear and the sun is low in the west. Blah, blah…". And the more detailed it is, the worse it looks. Random wording helped somwwhat on the MUSH, but then you were caught reading something different that just turned out to be the same old sky you saw in the last room.

I'm curious what you mean with your first recommendation. I could see how adding secondary room descriptions would help, but if you're going to be going through that much detail in the area, it's probably a portion of the world you want to have properly typed out room descriptions for, not these dynamically-generated descriptions for large, filler areas. How would one name such a room "better"? Is not "Deep in the Spider Forest" an acceptable name for a miscellaneous, average room that is deep in the Spider Forest?


That's actually a good point. I did it primarily because I thought it would be all fancy to show off that I could differentiate between the player flying, walking, being maimed, etc., which work better in relation to locomotion than they do to stillness. I don't think it looks bad now, but if I go in and add descriptive text for weather and time of day and such, that might be a change to make.