26 Mar, 2013, salindor wrote in the 21st comment:
Votes: 0
I see. So what I am seeing are four distinct types and weather they are important or not are really based on the game and its player base.

- no room descs (or small terse ones). Mostly pk MUDs where the description of what is being seen doesn't really add much value
- static room desc useful for quest and maze games
- dynamic room descs based on various stats. Useful for MUDs where the room can have affects added dynamically.
- dynamic room descs based on events. Useful for heavy story MUDs

Salindor
26 Mar, 2013, KaVir wrote in the 22nd comment:
Votes: 0
Roguelikes don't really have rooms. Nor do all muds. And some muds don't really differentiate rooms from other types of container. So what you're really talking about are "internal descriptions".

If you look at a backpack, should you see a description? If you climb into the backpack, should you see a different description? If a monster swallows you whole, should their stomach have a description?
26 Mar, 2013, salindor wrote in the 23rd comment:
Votes: 0
So then what I wrote about the four different types just become more generic then from a design perspective?
26 Mar, 2013, KaVir wrote in the 24th comment:
Votes: 0
I wouldn't differentiate between dynamic descriptions based on what sort of variables they used. If I were going to differentiate between them, it would be based on whether they were generated or hand-written (although there's no reason why a game couldn't use both). And of course static descriptions can be generated or hand-written as well.
27 Mar, 2013, Runter wrote in the 25th comment:
Votes: 0
A mix of both seems like it has the most potential.

But there's a reason why static descriptions are appealing. People don't want to have to read them over and over. It's like the layout of your house. People want to be able to wake up in the middle of the night and get to the bathroom. This is why I always hate games that mix room descriptions with contents of the room and force me to read it to see what you can interact with.

This is mitigated by games that use color patterns to allow you to quickly pick those things out, but then, why not just list them separate if you're going to go that far?
27 Mar, 2013, KaVir wrote in the 26th comment:
Votes: 0
I think that's the first time I've ever heard someone say they prefer static descriptions.

If you don't want to read them more than once, why would you bother displaying any description at all once the person has read them the first time?

And of course there's a lot of variation among dynamic descriptions. There's no reason why you can't have descriptions that only change based on the viewer - so that each person sees a different description, but the same viewer will always see the same description they did previously. For example my "build" help file, which gives build suggestions based on the viewer's class. That's effectively static, it just means you don't have to read through irrelevant text to get to the useful stuff.
27 Mar, 2013, salindor wrote in the 27th comment:
Votes: 0
I think there maybe three descriptions of dynamic going on here.

When I was using the word dynamic I simply meant the description displayed was calculated somehow (so by this definition it is impossible to have a auto-generated static descriptions). Also it seems like what Runter (please correct me if I am wrong) is referring to is content mixed into the description (like what is common to puzzle games).

Even though this is somewhat of a repeat from above, I am going to attempt my classification again based on your guys comments and some additional thoughts so lets see how well I do :)

So with two caveats
- that if the mud is container based rather than room based, then substitute container for room and depending on the style your going for the answer to Kavir's question will either be yes or no :)
- a mud could combine several of them. They could for example use a grid based system for their world map and use a static room system for dungeons


So here are the types as I understand them:
- Grid based system – best for pk based muds or hack and slash? Can turn off hard core rpers
- Room based, limited/no description – best for pk based or hack and slash. Can turn off hard core rpers.
- Room based handcrafted static description (with keywords in the description possibly being meaningful) – can be used in adventure games like I am thinking "king's quest" type genre, and pk. Can turn off hard core pkers who aren't really interested in the room descs. Can turn off people who don't like the active content in description
- Room based multi-handcrafted description choosen by game stat– an extension to above but the description is selected based on some game state weather it be class or quest.
- Room based dynamic content - content generated by 'affects' on the room to alert the player to changes. Not sure this is a distinct style but it was brought up in the discussion

Salindor
27 Mar, 2013, KaVir wrote in the 28th comment:
Votes: 0
salindor said:
I think there maybe three descriptions of dynamic going on here.

You might find this thread of interest: Manual vs. Dynamic Descriptions

salindor said:
When I was using the word dynamic I simply meant the description displayed was calculated somehow (so by this definition it is impossible to have a auto-generated static descriptions).

It is possible to automatically generate descriptions with tools like this, then store the results in exactly the same way as static descriptions. Such descriptions would be both generated (as opposed to hand-written) and static (as opposed to dynamic). Some muds use this approach as filler for large wilderness areas.

Note also that a dynamic description doesn't need to be generated. It could also be hand-written using some form of markup language, with text substitution and conditional checks. While it would still be processed before being displayed (in the same way as a webpage), the description itself would all be written by hand.

salindor said:
- that if the mud is container based rather than room based, then substitute container for room and depending on the style your going for the answer to Kavir's question will either be yes or no :)

My point was that rooms are containers - so whatever approach you use for rooms, it will also need to factor in any other container you can enter.

salindor said:
- a mud could combine several of them. They could for example use a grid based system for their world map and use a static room system for dungeons

By "grid based system" are you referring to a (roomless) coordinate-based world system? If so, I would not suggest including room-based areas as well, better to be consistent throughout the mud.
27 Mar, 2013, salindor wrote in the 29th comment:
Votes: 0
KaVir said:
You might find this thread of interest: Manual vs. Dynamic Descriptions


Thank you, very pertinent and enlightening. It really helped me solidify some of my thinking of what I want to do for my mud.

KaVir said:
It is possible to automatically generate descriptions with tools like this, then store the results in exactly the same way as static descriptions. Such descriptions would be both generated (as opposed to hand-written) and static (as opposed to dynamic). Some muds use this approach as filler for large wilderness areas.


I suppose, but you are using an external application to do so and not really a design factor for the mud under code. From its point of view its static. I guess if you tried it to a random maze generator; but once the maze was generated it became a perm addition to the world… but whatever I guess the real point is there are degrees of dynamic.

KaVir said:
By "grid based system" are you referring to a (roomless) coordinate-based world system? If so, I would not suggest including room-based areas as well, better to be consistent throughout the mud.


I agree, poor example.
27 Mar, 2013, KaVir wrote in the 30th comment:
Votes: 0
salindor said:
KaVir said:
It is possible to automatically generate descriptions with tools like this, then store the results in exactly the same way as static descriptions. Such descriptions would be both generated (as opposed to hand-written) and static (as opposed to dynamic). Some muds use this approach as filler for large wilderness areas.

I suppose, but you are using an external application to do so and not really a design factor for the mud under code. From its point of view its static.

It doesn't cease to be a design factor just because the generation tool isn't integrated into the mud - it's still going to have an impact on the rest of your design, after all. It will affect decisions about the size of the world, what sort of details it contains, how different target audiences will react, and so on.

But you could also build the tool into the mud if you wished, then click a button or type a command to generate a static description from within the game. The reason I call it "static" is that once it's been created, it doesn't change. It doesn't factor in the time, the season, the viewer, etc.
27 Mar, 2013, Rarva.Riendf wrote in the 31st comment:
Votes: 0
Quote
So for example someone in the room before you set everything on fire. When you enter with the description off and start whittling a fishing pole, you suddenly wonder why your cloak of +1000 shock resistance suddenly is halfway burnt and now a +500 cloak.

Dont need a room description to what is a room agression on me. It is an "action" that will have its own text.
28 Mar, 2013, Chris Bailey wrote in the 32nd comment:
Votes: 0
I've dabbled with dynamic descriptions but I always find myself creating a system that requires just as much work as writing the descriptions themselves. One such venture required locales, i.e., the typical MUD room, to have various attributes assigned and a variety of objects placed in order to produce a description. Creating a mountain range object, a swamp object (each with their own varying attributes, e.g., height, depth, color) proved more difficult than just writing static descriptions. I'm not sure whether or not it would have been less work in the end but it certainly required more effort up front. On top of creating all of the items for each locale, I also had to write several short descriptions that could blend easily with one another.
28 Mar, 2013, salindor wrote in the 33rd comment:
Votes: 0
I haven't replied in a bit because I am letting the information KaVir provided stew. I can't imagine an outcome much different from your experience. But I think for the style mud I am going to go for I will need it in order for it to feel complete ( both as important in game mechanic and as polish)

However my thought is to keep the dynamic simple and something specified by the builder where the deciding factor is based of the characters attributes not the rooms attritibutes. Things like times visited, players name, quests done etc.

The specific goal I am going for is to get the player engrossed in the story of their character. I am planning on supporting pvp but between a design decision to encourage players attracted to rp and stories and those there only for pvp– I am going to go for rp.
28 Mar, 2013, quixadhal wrote in the 34th comment:
Votes: 0
Chris Bailey said:
I've dabbled with dynamic descriptions but I always find myself creating a system that requires just as much work as writing the descriptions themselves. One such venture required locales, i.e., the typical MUD room, to have various attributes assigned and a variety of objects placed in order to produce a description. Creating a mountain range object, a swamp object (each with their own varying attributes, e.g., height, depth, color) proved more difficult than just writing static descriptions. I'm not sure whether or not it would have been less work in the end but it certainly required more effort up front. On top of creating all of the items for each locale, I also had to write several short descriptions that could blend easily with one another.


It depends a lot on what kind of dynamic events you want to have in the description. It's pretty common for MUDs to offer day and night descriptions (although less common to have them USED extensively). It's also not unusual to offer seasonal descriptions. If you keep it to just those few limited changes, and only provide multiples when it would be dramatic and/or useful, static descriptions work fine. Just show the one that fits the current conditions and you're good.

If you want more flavor, or a more complex reflection of world state, you pretty much have to develop some kind of markup language, and your builders will hate having to use it, because it makes a lot of extra typing for them. But, if done well it can offer some pretty interesting results, like having someone with high mechanical skills notice the workings of a lock mechanism (and potential ways to get around it), where someone with high metalurgy skills might notice a weakness in part of the hinge that could be broken. At night, someone might notice a concealed doorway because a glimmer of torch light can be seen leaking around a rough edge, but in the daytime it would be perfectly concealed in the surrounding rock.
28 Mar, 2013, KaVir wrote in the 35th comment:
Votes: 0
Chris Bailey said:
I've dabbled with dynamic descriptions but I always find myself creating a system that requires just as much work as writing the descriptions themselves.

Well, yes…dynamic descriptions obviously require more effort to write than static descriptions. The reason for using dynamic descriptions isn't to reduce the workload, it's to produce descriptions that are more interactive and immersive.
29 Mar, 2013, Runter wrote in the 36th comment:
Votes: 0
KaVir said:
I think that's the first time I've ever heard someone say they prefer static descriptions.

If you don't want to read them more than once, why would you bother displaying any description at all once the person has read them the first time?

And of course there's a lot of variation among dynamic descriptions. There's no reason why you can't have descriptions that only change based on the viewer - so that each person sees a different description, but the same viewer will always see the same description they did previously. For example my "build" help file, which gives build suggestions based on the viewer's class. That's effectively static, it just means you don't have to read through irrelevant text to get to the useful stuff.


Then I'll be the first to say something that should only be a shocking statement in the mud community. I don't want to spend all my time reading room descriptions. I'd prefer to sample the game mechanics more, read room descriptions less.
29 Mar, 2013, arholly wrote in the 37th comment:
Votes: 0
I don't find it that shocking, but I guess I'm a late comer to the community. Having come to age when MadRom was popular, I then came to Roguelike's shortly after and grew to love games like ADOM, which offer RP in minor ways in addition to combat. Need to save the Carpenter? Then you can kill him or have him follow you to the healer who touches him and heals his madness. I could see what type of terrain I was in because of the symbols, but never really cared (probably because it is/was not needed).

I know for designers (and builders I suppose), rooms are kind of a sacred cow. But it sounds like from a player POV, they aren't that valuable. Now, that could be because the designers/builders don't make them so, or because players just don't see the value in them.
29 Mar, 2013, quixadhal wrote in the 38th comment:
Votes: 0
So, getting rid of room descriptions (including generated "room-like" descriptions for roomless muds)… how do you present the world to the player in a way that's engaging?

A roguelike interface is all well and good, provided you are making a MUD that plays like a roguelike. Roguelikes don't have any real emphasis on mood or environment, because that's not the focus of the game.

A graphical interface is great… provided you have a team of graphic artists to produce content.

Describing ONLY what's happening can work well, if your game is all about PvP and not much else. In these games, it's all about finding your opponent and perhaps using terrain to your advantage, so that's all you really need to see. A room description could be "This area has high ground", or "There is plenty of cover here."

What other alternatives exist? Just not having room descriptions makes for a very bland environment, so for most of us, that's not an acceptable option.
29 Mar, 2013, arholly wrote in the 39th comment:
Votes: 0
I'm not saying to get rid of room descriptions, though it is a direction I am considering. I think your analyze of roguelikes might be a tad off because several of them, especially more modern ones, do have emphasis on mood and/or environment. Granted, the focus is still primarily combat driven, but then so are a great number of MUD's. I think the similarities between MUD's (especially MUD's vs. MOO's or MUSHes) and Roguelikes are more numerous than their differences.

Also, I am not sure what other alternatives do exist.
29 Mar, 2013, KaVir wrote in the 40th comment:
Votes: 0
Runter said:
KaVir said:
I think that's the first time I've ever heard someone say they prefer static descriptions.

If you don't want to read them more than once, why would you bother displaying any description at all once the person has read them the first time?

And of course there's a lot of variation among dynamic descriptions. There's no reason why you can't have descriptions that only change based on the viewer - so that each person sees a different description, but the same viewer will always see the same description they did previously. For example my "build" help file, which gives build suggestions based on the viewer's class. That's effectively static, it just means you don't have to read through irrelevant text to get to the useful stuff.


Then I'll be the first to say something that should only be a shocking statement in the mud community. I don't want to spend all my time reading room descriptions. I'd prefer to sample the game mechanics more, read room descriptions less.

Nothing shocking about such a preference, I just don't see how it has anything at all to do with preferring static descriptions. Dynamic descriptions have the potential to be shorter (because you can tailor them to the viewer rather than making them generic) - and if you really dislike reading descriptions, why not just remove them entirely?

If you dislike reading descriptions, then static descriptions are the worst possible solution.
Random Picks
20.0/128