26 Jan, 2013, Idealiad wrote in the 1st comment:
Votes: 0
Scandum said:
arendjr said:
@Scandum: You talk about a general purpose description engine, but you're light on details. What would it take in your opinion to create a minimal viable description engine? :)


The first step would be to have something to describe, so this means adding actual content, which means you need some kind of physics engine. Objects need shapes and sizes, these can be fairly generic due to the medium. Colors can be determined based on the material / skin, and lighting conditions.

The engine needs to be able to prioritize, a stone may not need be described unless someone specifically looks at the ground. Multiple stones eventually become a pile of stones, so the engine needs to handle grouping.

Skills need to be taken into account, what is a metal sword to a carpenter might be seen as a silver sword to a blacksmith, who in turn wouldn't be able to tell oak from pine. The actual room needs to be described and surrounding rooms need to be described as well. Line of sight becomes important here, a short person may see something different than a tall person.

Dynamic description handling I've seen so far is very basic. They're basically pre-written descriptions with some code to fill in the blanks. So the MUD will have to generate the description layout and fill in the blanks. This will create a markup language that builders in theory could use as well though this is undesirable as the content is pseudo-dynamic. There probably needs to be some way for builders to influence the description layout so they can empathize and de-empathize content.

The most likely way this is going to be accomplished is by using a bare bone implementation where the focus is on game physics and dynamic description handling. The main selling point would be that builders don't need to provide descriptions, the availability of game physics, and a much greater degree of malleability of the game world.

There was a guy claiming to have written such a MUD, called PhysMUD, but apparently the work was lost in a hard disk crash, while others believe it was an imaginary project.


I'd like to talk about this more. Imagine at first that you're writing a spec for this engine.

First off, who's done this before? There are the PhysMUD examples (real or fake). You can find those in the mud-dev archives (by Nathan Yospe right?). There's God Wars 2. I think there are some threads at TMC that describe that in more detail, maybe KaVir has the links.

Others?

Some links:

http://mud-dev.zer7.com/search?q=physmud

"Manual vs. Dynamic Descriptions" http://www.mudbytes.net/topic-3937

"Dynamic Description System" http://www.mudlab.org/forum/viewtopic.ph...

"Dynamically-generated object descriptions" http://www.mudlab.org/forum/viewtopic.ph...
26 Jan, 2013, KaVir wrote in the 2nd comment:
Votes: 0
I think the best description of my approach was on this thread: Dynamically-Generated Room Descriptions.

Methuselah on the FutureMUD forums wrote an interesting room generator. It's too random for the sort of thing being discussed here, and the results are static descriptions, but the concept is very cool and could certainly be combined with other ideas. I'll send him a PM, perhaps he's interested in weighing in on the topic.
26 Jan, 2013, Idealiad wrote in the 3rd comment:
Votes: 0
Cool, principles of generation certainly would have something to add to the idea.

Many interactive fiction engines include some means for dynamic descriptions. Inform 7 does stuff like,

Quote
A dead end is a kind of room with printed name "Dead End" and description "This is a dead end. You'll have to go back the way you came, consoled only by [river sound]." A dead end is usually dark.


where river sound is a property of a dead end room class instance.

It has basic conditionals:

Quote
The Customs Wharf is a room. "Amid the bustle of the quayside, [if the cask is open]many eyes stray to your broached cask. [otherwise]nobody takes much notice of a man heaving a cask about. [end if]Sleek gondolas jostle at the plank pier."


and

Quote
The initial appearance of a door is usually "Nearby [an item described] leads [if the other side of the item described is visited][direction of the item described from the location] to [the other side][otherwise][direction of the item described from the location][end if]."


Though this is not as dynamic as I think a description engine should be.
27 Jan, 2013, Scandum wrote in the 4th comment:
Votes: 0
I wrote a basic description generator for emud/lola for the road system. It's 800 lines of code that accomplishes very little and is entirely cosmetic, with that I mean there's no real point in reading the description. It looks at how rainy it is, the season, what the sky looks like (time of day and weather), what the road looks like (based on weather and number of exits), and the room sector. I think one criteria has to be that the description must have some innate value to gameplay, otherwise you're wasting your time as players won't read the descriptions.

So the first step would be to think of game elements that would be worth describing. I guess we can call this dynamic description oriented content design.

Another problem is that you'd probably want to split up the code to deal separately with describing a room and a creature. The downside of that is that you may end up unable to reuse code. So you'd probably want to create pseudo-dynamic descriptions like KaVir writes about, using [tags] that are filled in by a different parser. Tag handling may require further thought, like how to handle references to rooms, items, and characters, and how to reference various properties. Tags shouldn't be limited to object they relate to, and if a player in a bordering room is aiming a bow at you this may need to be described - this is easier in roomless worlds, but there are disadvantages to roomless as well.

So the second step would be to think of what different generic elements need to be described, areas, rooms, characters, items, doors, weather, etc, and what type of gameworld is the easiest to describe. So that'd be dynamic description oriented world design.

The next issue is prioritization, meaning what is worth describing. Players don't want to read about the weather in every description, if they want to know about the weather they can look at the sky. They don't want to read a dozen mentions of stuff being wet from the rain in a single description, or that most features are blurry due to the smoke from the flickering torch light. You also don't want to describe every single thing because that ruins the sense of exploration, butyou don't want to make it obnoxiously difficult to get a good idea of what all is in the room. This might be fairly difficult. The key aspect here would be that the focus of a dynamic description engine is towards explorers, it won't be as appealing to socializers (facebook), killers (3d shooters), or achievers (pogo?).

Subsequently everything needs to be able to be examined and described in greater detail. This would include features I haven't heard of before, like being able to examine the weapon another player is wielding in greater detail, which would probably require a check to see if that player is in motion or combat, as that would make this more difficult. So this introduces gradients of detail to the design, which I think is highly important because you can require specific skills for the greatest level of details, combined with how well developed a character's senses are. A myopic dwarf may be unable to read without glasses.

I'm just highlighting a few of the elements that I think would be important, but I can't stress enough that there's no real point in this endeavor without maximizing the influence of dynamic descriptions on gameplay.
27 Jan, 2013, Rarva.Riendf wrote in the 5th comment:
Votes: 0
Dynamic description is like asking a computer to be a writer. And a good one at it.
And one that can write while reading your mind to see what you would be interested to actually look at.
Like only picking the girl with a red dress in the crowd.

You really think you can achieve that ? In a few line ? I deem it is impossible, text is not the medium for that.
27 Jan, 2013, arendjr wrote in the 6th comment:
Votes: 0
Personally, I'm gonna try to generate dynamic descriptions using spatial relations. I'm using a room-based system, but for this to work a MUD needs to have a few prerequisites:
1) Rooms need to have a 3D coordinate
2) Items need to have a 3D coordinate relative to the room they're in
3) Characters have a direction vector indicating in what direction they are looking
4) Character objects remember their last action for at least a few seconds
5) Rooms can have a "type" that provides a little, possibly intelligent description

If you want players could be positioned at different places in rooms, but for the sake of simplicity during gameplay I will assume all players are in the center of whatever room they're in. This also releases builders from the need to specify room sizes or shapes. But feel free to add as much complexity as you like of course.

Okay, let's start with an example of a simple, but complete description:

The corridor runs from the north to the south. To your left is a door leading to the cloning chambers. On the right wall there's a sign reading "District 21, Floor 34". Ahead of you, two guards are running in your direction.

Obvious exits: north, south, door


The first sentence here would be generated because the room type is a corridor. This part is relatively easy, but will save builders a lot of time by not having to repeat the obvious.

The door to the left is an exit. To make things even easier for builders, exits don't require a coordinate like items do. Because you know where the adjacent room is the algorithm can figure out where it is relative to the player.

The sign is hanging on the wall, but the algorithm doesn't know as it doesn't know the room size. But you can easily have a flag on the item to indicate this.

Finally, the guards are one or two rooms ahead of me, but line of sight tells me I can see them. Their last action was to run, and they're facing your direction, hence the result they are running toward you.

But now we'll look at the door:

look door
The door is an automatic, mechanical door made out of solid steel.

On its right there's a little keylock glowing a faint red light.


Ah! So while the keylock was no point of interest for the general room description (many MUDs have a hidden property for items/exits that don't appear in the room description, possibly you can reuse it for this purpose), it's very relevant when looking at the door! And this relationship is simply defined by their proximity. The keylock is right next to the door, so you'll spot it when looking at the door.
27 Jan, 2013, quixadhal wrote in the 7th comment:
Votes: 0
Dynamic descriptions are really several different tasks rolled into one label.

First, there's the description of the landscape. For a typical game, this will usually be the description of the local room, and some of the rooms around it. In an ideal world, you could also have points of interest which are visible from much larger distances. Not all POI's are special things though…

For example, let's pretend our game uses a wilderness system and the "room" size is 100 yards (classic AD&D). So, you're in a clearing in the woods. There's a path leading away to the east. There's a burbling stream running along the north edge of the clearing. A tree stump is to the west, where the large tree that probably shaded the spot you're standing in used to be. Through a gap in the trees along the stream, you can see mountains to the northeast.

Obviously, you can create the local description from the terrain type being "grassland". You can deduce it's a clearing by the fact that most of the surrounding rooms are "forest". The path/road and stream/river can either be terrain types or (my preference) overlays that sit atop the underlying basic terrain type. The tree stump is a random detail, and once you figure out it's a clearing, you can add it or not.

The mountain part is the tricky one here. The mountain terrain is not likely to be one, two, or even a dozen rooms away… it may well be 30 rooms distant, but mountains are BIG. You wouldn't see them if you were surrounded by forest, but you might if you were on the edge of a forest (IE: a gap on the right side, or even only one layer of forest rooms on that side).

If you want to be more accurate, you also need to analyze the slope of the terrain, since if there are hills, or you're on a hill, your view will be different.

I don't think you need to make your descriptions super-high-quality.. and I doubt you really can. That's why you have builders. But, there's no point making your builders describe 10,000 square miles of wilderness that most players will zip through as they travel from POI to POI. It needs to be informative (if a cliff blocks your path, you should be told by the description… not by falling off it, or the error "You can't go that way!"). It would also be nice if it sounded reasonable and varied a bit from room to room.

Note that for the purposes of a euclidean wilderness, you can replace "room" with "tile" and you have the same thing.

Indoor areas, cities, cave systems, and other things will need different algorithms, as those types of terrain don't work quite the same. I would probably have slightly different algorithms for vastly different climates as well. A jungle and a frozen tundra won't have very much in common for flavor text or details, but will still share the same general LOS issues.
27 Jan, 2013, KaVir wrote in the 8th comment:
Votes: 0
Scandum said:
So you'd probably want to create pseudo-dynamic descriptions like KaVir writes about, using [tags] that are filled in by a different parser.

You appear to be confusing "generated" descriptions and "dynamic" descriptions. A dynamic description (as opposed to a static description) is one that changes based on various factors such as the viewer and environment. A generated description (as opposed to a hand-written description) is one that is doesn't need to be written manually for a particular location. I posted a more detailed breakdown with examples in this thread.

You can't really have "pseudo-dynamic descriptions" from a game design perspective, either your descriptions use dynamic elements or they're static. I guess you might use that term to refer to muds with separate day and night descriptions, but technically those are just two separate static descriptions.

Scandum said:
I'm just highlighting a few of the elements that I think would be important, but I can't stress enough that there's no real point in this endeavor without maximizing the influence of dynamic descriptions on gameplay.

I don't agree, even cosmetics alone can have a signific....

Rarva.Riendf said:
Dynamic description is like asking a computer to be a writer. And a good one at it.

Nope, that's a generated description. A dynamic description is like a webpage that uses a markup language - it doesn't reduce the quality of the writing. In fact you already use dynamic descriptions for various messages, such as combat messages, socials, actions, etc. If I draw a sword it says "KaVir draws his longsword", not "A character draws their weapon". A dynamic description is the same concept applies to room/object/mob/etc descriptions.

But even generated descriptions aren't really the same as asking the computer to be a writer. The mud doesn't have to create the descriptions word-by-word, it's perfectly sufficient to assemble pre-written sentences with dynamic elements.
27 Jan, 2013, quixadhal wrote in the 9th comment:
Votes: 0
Good point KaVir. I was using "dynamic" to mean "dynamically generated", which isn't the same thing.

In fact, a description generator might well include dynamic markup, since you probably want different text output for day/night, weather, seasons, etc… and may not want to re-generate the description every time (so you can cache the results).

In my ideal game, you'd want both available anyways, since you DO want your builders to hand-craft "interesting" areas, and markup allows them to do so without needing to cut and paste as much to handle the various permutations your game's environment might provide.
27 Jan, 2013, Rarva.Riendf wrote in the 10th comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
Dynamic description is like asking a computer to be a writer. And a good one at it.

Nope, that's a generated description. A dynamic description is like a webpage that uses a markup language - it doesn't reduce the quality of the writing.


I beg to differ. We are talking about making a resume of what you are seeing, and depending on various conditions highlight or emphasis some objects more than others.
This is not done with grammar only but with style. Otherwise you do not make a description but an inventory.
At this point calling it 'generated' or 'dynamic' is basically the same.

In stock rom mobiles are separated from the description.
It could be easy to flag the room with some value like 'street' 'shop' and you could insert 'you notice a guard in the street' 'and a customer in the shop'
(provided you have guard and customer mobiles)
Still is an inventory, not really something I would call a 'description'.
And as a player you may not be interested at all in noticing any of the mobiles.
27 Jan, 2013, KaVir wrote in the 11th comment:
Votes: 0
Rarva.Riendf said:
At this point calling it 'generated' or 'dynamic' is basically the same.

Let me quote the original post, perhaps it'll clarify the distinction:

Quote
The usual divide is "static vs dynamic" and "hand-written vs generated".

Most muds use static hand-written descriptions. A builder writes them, and that's what everyone sees.

I personally consider dynamic hand-written descriptions to provide the best solution, although they also require the most work - a builder writes them, but includes text-replacement tags and conditional checks so that the description is customised for each viewer.

The worst solution is static generated descriptions, which are often used as filler for vast wilderness systems. They are generated based on various criteria, often on-the-fly, but always look the same to every viewer.

A better way to handle vast wilderness systems is with dynamic generated descriptions. These are also generated on-the-fly, but are also modified for each viewer. This is particularly worthwhile for wilderness systems because it allows you to refer to things like the weather, the position of the sun and moon, and so on. Without including that, the description tends to be all padding rather than useful information.


I'd also like to stress the point I made earlier: Adding the option for dynamic descriptions doesn't mean you have to change any of the existing descriptions. It just means you have that option available should you want it.

For example you might decide you're perfectly happy with the current descriptions, and leave them as they are. But the next time you're writing an area, you might find yourself thinking "I'd really like to mention the sun shining in through the hole in the roof of the ziggurat and illuminating the ancient runes on the floor, but that would only happen at midday, so I can't really include that"…except now you can. And better still, you can even reveal what the runes say, if the viewer also happens to understand the language.
27 Jan, 2013, Rarva.Riendf wrote in the 12th comment:
Votes: 0
Even, dynamic generated descritption will output the same result in the same condition. (computers are made for that heh). Thing a player cannot type what is his mood at all time.
Is he hunting (then only caring about what he can kill) is he tracking (then not caring about the bird in the sky), or is he tracking but if can kill a bird to eat he would stop…
Thus you cannot make a dynamic description that would not fill an entire page without knowing what the player is thinking.
27 Jan, 2013, KaVir wrote in the 13th comment:
Votes: 0
The purpose of a dynamic description isn't to include everything the viewer might see, hear or feel.

It just means you don't need to exclude things you do know about.
27 Jan, 2013, quixadhal wrote in the 14th comment:
Votes: 0
Linking this here, because it's in another thread but has some usefulness in the context over here.

Short version, you can use the slope of your exits to improve your generated descriptions, at least for wilderness type areas.
27 Jan, 2013, Scandum wrote in the 15th comment:
Votes: 0
quixadhal said:
The mountain part is the tricky one here. The mountain terrain is not likely to be one, two, or even a dozen rooms away… it may well be 30 rooms distant, but mountains are BIG. You wouldn't see them if you were surrounded by forest, but you might if you were on the edge of a forest (IE: a gap on the right side, or even only one layer of forest rooms on that side).

I think some MUDs call these landmarks. If a MUD treats areas as rooms, and keeps track of how they inter-relate, it should be possible to add some code to build proper landmarks and possibly make them more than a purely cosmetic feat. So I guess the choice becomes to create landmarks, or detect landmarks. They're obviously important for navigation, though I'm not sure if they can have other uses.

quixadhal said:
I don't think you need to make your descriptions super-high-quality.. and I doubt you really can. That's why you have builders.

Builders however do very little building in your average MUD. They set up a quick canvas and spend most of their time painting (writing descs). If you focus on area based quests they'll spend most of their time writing scripts. In the model I propose Builders would actually be building.
28 Jan, 2013, quixadhal wrote in the 16th comment:
Votes: 0
Sure, landmarks are an easy way to get around the issue. The point though, was to develop a description generator which would take an arbitrary (unknown) set of map data and generate correct and useful descriptions from it WITHOUT needing to have builders hand-place things.

You have to think of this problem as a general one, not something specific to a given MUD instance. It's trivial to work around issues when you have a small enough data set, but what about an infinite map?

As suggested earlier, you can generate terrain maps that do not end. If a user wants to walk north forever, they can do so, because the map will constantly generate new terrain as they move. If you use 64-bit integers, it will be larger than they can access in their lifetime. If you use one of the arbitrary precision math libraries, it could be as infinite as your hardware allows.

For those cases, you can't just have your builders place landmarks. The engine itself has to be able to deal with LOS for terrain height, and have some useful heuristics for knowing that certain terrain or vegetation types have a higher chance of blocking LOS than others.

If you were in a pure coordinate space, where each tree and shrub is an object, and you use R-trees (or similar) to handle distance averages, it's a bit more straight-forward since you can use real LOS algorithms for everything. In a room system though, you have to fudge some things since you don't have that level of accuracy. All you know is you're standing in a room full of trees, with more rooms of trees on some sides, and rooms without trees on others.
28 Jan, 2013, Idealiad wrote in the 17th comment:
Votes: 0
Description generation is an interesting problem, and not irrelevant to dynamic descriptions, but in the OP when I said 'dynamic description' I did not mean pure generation, so we do have more control over the output.
28 Jan, 2013, arendjr wrote in the 18th comment:
Votes: 0
quixadhal said:
Sure, landmarks are an easy way to get around the issue. The point though, was to develop a description generator which would take an arbitrary (unknown) set of map data and generate correct and useful descriptions from it WITHOUT needing to have builders hand-place things.

It may have been your point, but I don't think it was everyone's :)

Generators are fun, but dynamic systems that really on input from builders are certainly useful too.
28 Jan, 2013, Idealiad wrote in the 19th comment:
Votes: 0
One thing I've never liked about markup-based dynamic description systems is the kind of 'syntax soup' you get when combining prose and procedural checks. This seems like just the thing that would benefit a lot from a graphical design system.
28 Jan, 2013, Ssolvarain wrote in the 20th comment:
Votes: 0
I think this thread is a good example of why they made 'graphical muds'.
0.0/59