Dynamic Description System

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Thu Dec 08, 2005 6:48 pm    Post subject: Dynamic Description System Reply with quote

I've been giving considerable thought to descriptions and views and I think I've come up with a workable system, although many of the finer details still need ironed out. I wanted to post here to foster discussion on the subject, find any holes in my plan, and glean some inspiration from my fellow MUD designers Smile

For an added layer of complexity, I'm hoping to have all descriptions be generated. Instead of a builder writing a description for a room and then adding items to that room to match the static description, I want the description to be dynamically generated based on the items in the room. At the same time I don't want the dynamic descriptions to be bland. This is not what I want:

"You enter the room. You see an orc. You see an orc. You see an orc. You see a table. You see the bartener. There is a door leading to the east. There is a staircase leading up."

Instead I'm looking for something like this:

"You step in to the dimly lit tavern and look around. Three burly orcs sit at a large oak wooden table. A bar juts away from the north wall, and a tall, lanky human bartender stands behind the counter, polishing glasses. Two large kegs of ale rest on the bar. Along the east wall is a open wooden door. Wafts of tobacco smoke drift through the opening. Against the west wall is a staircase with an ornately carved wooden railing leading up to the guest rooms."

I've decided to use a Proximity system, similar in function to that of Skotos, where objects are described in relation to each other. Many accolades to the people at Skotos for developing such a system. I don't typically like to emulate someone else's system when I can develop my own, but it's such a good system!

Each room, and possibly some of the items and exits in that room will be an "anchor point" for describing the position of objects. For example, in a typical indoor room, you would have one anchor point for the room (the center of the room), and one for each of the 4 walls, with possibly one more for the ceiling. All the remaining items, mobs, and exits in the room would be described in relation to these anchor points. In the above example, the anchor points for the room would be: Room (which is a catch all for anything not anchored to another point, the table with the orcs are anchored here), West wall (anchoring the staircase), East Wall (anchoring the door), and north wall (anchoring the bar and bartender).

One goal I would like to acheive is to keep a player from feeling like they are in a room when they are outdoors. Thus I want open exits to be an anchor for items in the adjoining room. So an outdoor street might appear as:

"You step onto the busy Market street. The salty smell of the sea is strong here. Several children are playing here with sticks and an inflated hog bladder. A street vendor stands near the east side of the road. His sign advertises "Fresh Fish". The odor of the fish assaults your nostrils. Several large mud-puddles remain in the dirt road from a recent downpour. On the west side of the road is the heavy wooden door to the "Tinker's Haven" tavern that you just exited from.
To the north you can see the intersection with State Street. A wagon is stuck in a large mud-puddle in the middle of the intersection, and a farmer struggles to push it free. Two city guards mounted on war-horses keep watch over the busy intersection.
To the south, Market street ends near the docks. Many dockworkers bustle around, moving crates of supplies. You can hear an overseer shouting instructions to the workers. A large trade ship, the Oversea is anchored near the dock."


Now, in this example, the docks to the south and the intersection to the north are both technically in another room. However, to the player, the concept of rooms has dissapeared and instead they appear to be on a busy street near the docks. If the move north, they will be at the intersection, and they will see more detail about that area. They may still see the fish vendor or the playing children, and possibly even the hulking shape of the Oversea in the distance.

The basis for the system is a tree-like structure. At the top of the tree is the room. This branches out to all anchoring objects such as walls, etc.. Then each of these banches to objects anchored to them (in proximity) and so forth. Exits (if open) branch out to the adjacent room they link to. Individual items and mobs branch into detail items that give better descriptions of those objects.

Each item, mob, exit, and detail has a "noticability" score. The noticiablity score indicates how important it is for the object to be included in a description. When a player looks at a room, the system follows the tree from the root (room) and returns any objects whose noticability threshold exceed a certain value. These are the objects a character is "most likely to see" when entering a room.

The noticability score for an object will never be less than it's children's scores in the tree. This causes you to notice items simply because they are the parent object of an important item. For example, in the bar description above, you notice the "Oak Table" because the orcs (high noticability) are the proximity children of the table.

Noticibility scores for objects can be modified by a variety of factors. A players location in the room is one. If the player is standing next to the Orcs at the table, it is much more likely to notice individual details about the orcs and the table then if it was standing at the door.

Another factor is recognition. A champion orc slayer is much more likely to notice the Orcs in the room than someone who is indifferent to orcs. A rogue is much more likely to notice a trap than someone who has no experience with traps. An adventurer is much more likely to notice his fellow adventuring party members over the other people in a room.

Senses are another factor. A player who has poor vision but good smell may not notice the bartender or the staircase in the dimly lit room. But he would be pretty likely to smell those foul orcs...

I'm sure there are other factors as well that I havn't thought of yet. However, the point is that the noticability scores of objects should be modified based on the player doing the observing and the environment.

Players can also choose to look at a specific object (or group of objects) in the object tree, and thus will only see a portion of the tree, but in greater detail. For example, if a player looks at the orcs:

"You glance at the three orcs. They sit in sturdy wooden chairs around an oak table. They talk amongst each other in Orcish and they appear like they may have had too much to drink. The tallest of the three wears a crude dented metal helmet and several patchwork peices of plate armor. One of the orcs has a long nasty scar that strecthes from his ear to his opposite cheek. A large battle-ax rests against his chair. Meat juice drips from his chin. A half-eaten plate of beef ribs sits on the table. Various gnawed rib bones are scattered around the floor near the table."

Because you are looking at the orcs, you see only their section of the object tree, but in greater detail. You can then look even closer if you wish: At the tall orc's helmet, at the battle ax, at the scar, at the ribs, etc.

One issue that must be tackled is identifying common objects in different branches of the tree and grouping them together in a way that makes sense (ie so you see "three orcs" instead of "an orc. an orc. an orc."). To help accomplish this, I suggest giving each object a set of "classes" that identify it. For example the orcs would have classes of "orc", "humanoid", and "being". A battle ax would have classes of "ax" and "weapon". The plate of ribs would have classes of "plate of ribs", "meal", "food", etc.

Each class would have a score. Classes that described an object more specifically would have higher scores. For example, "Orc" would have a much higher score than "Humaniod" at describing an orc. Once the system has examined the tree and returned a list of objects that should be described, it should try to group those objects by class with preference given to higher-scored classes. Classes that score low should only be used if they are the best descriptor for a large number of objects. For example, if a Dwarf joins the Orcs at the table, the system should group them "3 Orcs and a Dwarf", not "4 Beings". However, if you enter a crowded room with 10 Orcs, 10 Dwarves, and quite a few members of other races, you should see "The room is full of a multitude of beings of various races" not "The room is full of 10 orcs, 10 dwarves, 5 haflings ...".

Noticiability score should also affect grouping. If one object of a class has a noticability score much higher that the others, it should be broken out into it's own group. For example, if one of the orcs was wearing a jester's cap, you should see:

"A large orc sitting is sitting at a oak table. He is wearing a bright red jester's cap and has a goofy look on his face. Two other orcs sit at the same table."

Objects with large quantities (over 3-4) should be grouped using words instead of numbers. ie, 5 orcs sitting at a table should be described as "Several orcs sit at a table" not "5 orcs sit at a table". Other grouping descritor words that could be used are: "many", "a multitude of", "various", "a few", etc. The system could pick the best descriptor based on the number and type of items in the class.

Another (more difficult) factor that must be taken into account in order to produce realistic dynamic descriptions is action. The bartender is "polishing glasses". The children in the street are "playing". The farmer is "trying to free his wagon from the mud". Somehow, the mud has to be able to recognize the mobs actions and translate that into a description. Now part of this is solved already by the nature of muds. We can show action over time using messages. For example, after entering the room you may receive messages like

"The bartender puts down the glass he is polishing and picks up a different one"

"A sudden burst of hardy laughter comes from the table of Orcs"

"A child races past you, hitting the pig-bladder with his stick"

While messages like these entrench the character in the setting, your initial descriptions sound dry without some action words. One way this could be acheived is to query the goal system I described in the "Mob Combat AI" to describe the mob's active goal. For example, the bartender's current goal is "polish the glasses", the farmers current goal is "free the cart from the mud". It would be fairly simple to translate these goals into the description.

This doesn't work as well for the "bustleing" dockworkers. To bustle implies movement. So perhaps the best way to indicate this is to look at a list of recent actions in the room. If there are lots of movement actions coming from dockworkers in the room within the past 30 seconds, then the dockwerkers are described as "bustleing", otherwise they are described as "standing". Of course, that's very vague and general, and I havn't yet considered how to translate this concept into code without using more computing power than NASA.

Anyway, this is the basis for the system I hope to implement. I would appreciate comments, suggestions, and general discussion!
Back to top
View user's profile Send private message Send e-mail
Author Message
Teelf



Joined: 12 May 2005
Posts: 21
Location: Seattle, WA

PostPosted: Sun Dec 11, 2005 3:52 am    Post subject: Reply with quote

Overall, sounds like a good goal and you have an idea about where to start so go for it. I just noted a couple of things that may or may not be useful.

Quote:
Each class would have a score. Classes that described an object more specifically would have higher scores. For example, "Orc" would have a much higher score than "Humaniod" at describing an orc. Once the system has examined the tree and returned a list of objects that should be described, it should try to group those objects by class with preference given to higher-scored classes. Classes that score low should only be used if they are the best descriptor for a large number of objects. For example, if a Dwarf joins the Orcs at the table, the system should group them "3 Orcs and a Dwarf", not "4 Beings". However, if you enter a crowded room with 10 Orcs, 10 Dwarves, and quite a few members of other races, you should see "The room is full of a multitude of beings of various races" not "The room is full of 10 orcs, 10 dwarves, 5 haflings ...".


I think it would be difficult to keep those numbers consistent across all objects that can be described. How does the scoring work for an orc and a chair?
You should resuse your class hierarchy (or make one if you don't have one) for your game objects. The lower the class in the hierarchy, the more descriptive it is. Note I am not necessarily talking about a class hiearchy of code, although it could be that. A data inheritance tree would work far better than an explicit one in code.

Also, it sounds like all the objects in the room have to be attached to an anchor point? This would prevent you from having the proximity chain/tree as in Skotos' version. Is that intended?
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sun Dec 11, 2005 2:26 pm    Post subject: Reply with quote

Sorry, I wasn't clear. Every object would either attach to an anchor point, or another object. So you would have a proximity tree forming from each anchor point.

While I havn't explicitly decided how object classes will be structured, the data inheritance model is already in place. Each and every type of object in my MUD loads from an XML file, which specifies the default attributes and function for that object type. The XML files use inheritance, so this could be the basis for the object classification system. For example, the XML file for a "Rapier" inherits from "Sword" which in turn inherits from "Weapon". If the object classification system is based on this, than a Rapier could be classified under any of those names.

Another thought I had was to give each object class a table of classification names. To use the same example, a Rapier would have a table like this:

NAME SCORE
Rapier 10
Sword 6
Weapon 2

Then, you would determine groupings based on the sum of the score for that group. Let's say you have 1 Longsword and 2 Rapiers. The score for the groups would be as follows:

Rapier (2 objects x 10 points) = 20
Sword (3 objects x 6 points) = 18
Longsword (1 object x 10 points) = 10
Weapon (3 objects x 2 points) = 6

The highest scoring group is selected (using the more specific name if tied). The objects in that group are described using that word. Then any remaining objects are rescored. So in this case, the result would be "Two rapiers and a longsword". However, if you changed it to 2 Longswords & 2 Rapiers the results would be:

Sword (4 objects x 6 points) = 24
Rapier (2 objects x 10 points) = 20
Longsword (2 objects x 10 points) = 20
Weapon (4 objects x 2 points) = 8

In this case the description would be "Four swords" or "A few swords". Not a perfect example, but I think you get the idea. Objects that really stand out would have high scores for their specific names. For example, a Diamond might have a classification table like this:

NAME SCORE
Diamond 50
Gem 10
Stone 1

Then, if you put a Diamond in a pile of stones, you will still see the diamond as a separate description ("A diamond and many stones") unless the pile gets larger than 50 stones, in which case you would no longer be able to distinguish the diamong ("A pile of stones") unless you look specifically at the stones, which would give you a more detailed description.
Back to top
View user's profile Send private message Send e-mail
Author Message
Teelf



Joined: 12 May 2005
Posts: 21
Location: Seattle, WA

PostPosted: Sun Dec 11, 2005 6:47 pm    Post subject: Reply with quote

My earlier point was why do you need to make up these numbers? The relevant information is implicit in your hierarchy. Rapier derives from sword derives from weapon. The lower the object in the hierarchy the bigger the implicit score. In the case of siblings, like I'm assuming longsword also derives from weapon, you can use the first common parent (sword). Or you have a preference order on siblings. Perhaps prefering the 'left' most child.

Making up the numbers seems difficult to balance and error prone, doesn't it?
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sun Dec 11, 2005 7:10 pm    Post subject: Reply with quote

Good point.

In addition to balance difficulties, the system I described above makes it less likely for you to notice an item of one type mixed in with items of other types, which is counter to the way the brain works normally. The data inheritance method is probably the way to go.

One other issue I've stumbled across as I work on coding this system is describing the proximity relationships. Now, the Skotos design article already discussed using prepositions to related objects (Under the table, near the chair, behind the bar, etc.). It's easy enough to assign a list of prepositions to an object that limits how other objects can relate to it. However, the problem lies in determining which objects can relate with which preposition. For example, I might have a recliner chair in a room. It's possible to have an item under the chair. A coin or paper could be under the chair. A character however (due to size constraints) can not. A plate of ribs might be able to sit on the table, but if an Orc tried it, it might break. I'm not quite sure how to account for these issues without writing separate code to handle them all on a case by case basis, which isn't a sound design.
Back to top
View user's profile Send private message Send e-mail
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sun Dec 11, 2005 7:44 pm    Post subject: Reply with quote

Ok, sorry for the double post, but I've been doing more thinking about objects and classification words. While the words above (rapier, sword, weapon) might all fall nicely into a data hierarchy, what about words that don't? For example, items with a low value might have the classification "Junk" (to generate descriptions like "Various junk is scattered about the room"). Also, what about occupational words like "Sorcerer" or "Guard"? Apart from setting up a multiple inheritance data hierarchy (which is possible, but creates it's own issues) I'm not sure how you would include descriptors like these in an inheritance classification system.
Back to top
View user's profile Send private message Send e-mail
Author Message
Teelf



Joined: 12 May 2005
Posts: 21
Location: Seattle, WA

PostPosted: Sun Dec 11, 2005 7:47 pm    Post subject: Reply with quote

Yes, that is tough. Now we are getting into the limits of this models ability to represent reality. Hopefully ChristopherA will comment since he is posting here now (woo!), but I think the key is in how the proximity instances are created. Initially you have stuff hand done by builders. From then on, things happen because of things players do to them or other events. If a player 'put sword on table', then you have enough to form the prox. If a player 'drop sword', then that command has an implicit destination for the sword. Since your code determines that destination, it could be be something in the prox chain.

For realism, I think the only things you may need to deal with are when things are ON and UNDER. In those cases, the same kind of logic you use for containers could probably work. How do you know if something fits in a container? How realistic do you want to be? Your chair could be composed of a chair and a 'container' that respresents underneath it. Skotos also has an article on a semi-realistic bulk system that they may use to assit in realism. There will definetly be special code for handling realism in placing things ON other things, but if you have a bulk system, it can be generic and you will not need to do it per item. [/url]
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sun Dec 11, 2005 8:06 pm    Post subject: Reply with quote

A third post....

Going back to the classification table system for a minute. What if each classification's score was based on the minimum required number of objects to use that classification. For example:

NAME SCORE
Weapon 10
Sword 4

So your system would group objects using the most specific class that met it's minimum and described every object that would fall into a broader class. If an object didn't fall into a qualifying class, it would be described using it's name. So, 4 rapiers and 2 longswords would be "Six swords", but if you add 4 pikes, you instead have "Ten Weapons". However, if you have 5 rapiers and 5 longswords you would have "Ten Swords" instead, since it uses the most specific class that describes all the objects.

This would cut down considerably on the difficulty of the classification table system as each item wouldn't have to maintian it's own classification scores. Instead, there could be one central classification table with the scores, and individual objects could simply register for specific classes (for example, a rapier could register as a "Sword" or a "Weapon").
Back to top
View user's profile Send private message Send e-mail
Author Message
RuinsOfFeyrin



Joined: 20 May 2005
Posts: 4
Location: Chicago!

PostPosted: Sat Dec 24, 2005 12:33 pm    Post subject: Hi Reply with quote

Here is something to consider. While this idea for description is rather intresting, and if done properly would create some vary nice dynamic descriptions, would it be worth the time and effort put into it.

In general i would say most players dont even read 90% of the room,mob, item, etc descriptions in a game. One thing i often do when considering new ways of doing things, or new features to add to my game is to look at realistically how much i think players will make use of that particular bit of code. More often then not, despite the idea being REALLY REALLY cool, the time investment into it is often much greater then the use of it and i therefore do not end up putting it it.

Im not sure of the particular kind of game you have, but if it were me, i could not justify the time it would invovle in creatnig such a dynamic system unless i was running a HARDCORE RP game. The other thing that woud perhaps to me, make it worth your time, would be if you planned on releaseing either the code as a snippet for an exsisting base, or releasing your base all together.

Just some food for thought.
Back to top
View user's profile Send private message Visit poster's website AIM Address
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sat Dec 24, 2005 2:46 pm    Post subject: Reply with quote

To be honest, you're right. That's why I abandon the concept. It would work well for a roleplay mud that centered around that type of thing, but since I'm going for a hack n' slash mud, I decided it wasn't worth it. As a H&Ser, I would rather see a short concise list of what items & mobs were in a room instead of having to pick them out of the room description.

On a side note, however, I do plan to release my codebase to the public once it's complete, so at a later time I may choose to make this a "Plugin" feature for the codebase.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign