11 Aug, 2012, arholly wrote in the 1st comment:
Votes: 0
Hello:
I want to bring up another design topic, manual descriptions vs. dynamic descriptions. Now, this in theory, could apply to anything (mobs, objects, etc…). I'm thinking objects is the best place to start, but maybe mobs might be easier.

What are people's feelings on manual vs. dynamic descriptions?

Arholly
11 Aug, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
While there's something to be said for a well written area (and letting players write their own descriptions on heavy RP muds/mushes) IMO the benefits of dynamic descriptions for a typical mud are so great that if you don't face enormous obstacles in implementing dynamic descriptions (a legacy codebase or whatever) you'd be foolish not to do it.
11 Aug, 2012, Runter wrote in the 3rd comment:
Votes: 0
The obvious benefit of dynamic vs static is that dynamic isn't the same every time. Stuff changes based on the factors you design into the system. I think it's a fallacy to think that static = well written and dynamic = cheap crap. All things being equal, both are well written or both are cheap crap… dynamic in almost all cases, unless you're designing a storybook adventure that players flip from page to page to play, is better. The real difference I believe is the difficulty level of implementation and pulling it off. It's much easier to make a well written static description. Because it takes 1 discipline. Writing. Making good dynamic descriptions takes two disciplines. Good writing and good programming.
11 Aug, 2012, KaVir wrote in the 4th comment:
Votes: 0
arholly said:
What are people's feelings on manual vs. dynamic descriptions?

I posted a summary a few years ago:

KaVir said:
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.

As you run a World of Darkness mud, you might also find these examples of help files (using dynamic descriptions) interesting - they're from my old WoD mud:

* Fortitude
* Strength
* Disciplines
11 Aug, 2012, Alathon wrote in the 5th comment:
Votes: 0


Thats pretty cool. I'm curious how your implementation splits up responsibility. I can think of a few different ways to go about it:

1) Hardcode helpfiles, giving each helpfile a chance to uniquely react to the player. Easiest to implement, but rules out having helpfiles stored in a database / modifying them in-game.
2) The more obviously appealing solution: Provide a range of tokens that get replaced on-view.

However, your helpfiles are fairly verbose. Case in point:

"unfortunately, because his Fortitude is two lower than his Stamina, he is only able to use four dots of Stamina in addition to his four Fortitude (a total of eight
dice) when soaking aggravated wounds."

I would normally prescribe something like that to conditional statements (The 'unfortunately' being there there because Fortitude < stamina, f.ex).

Is that logic a part of the token itself (A $fortunately token, that will be 'unfortunately' if fortitude < stamina), or is something else figuring out that logic?
11 Aug, 2012, KaVir wrote in the 6th comment:
Votes: 0
The help files can contain conditional checks. It's pretty much essential for dynamic descriptions, there's only so much you can do with just text replacement.
11 Aug, 2012, Scandum wrote in the 7th comment:
Votes: 0
Dynamic descriptions are pointless if they have no impact on gameplay. So the first design step should be to figure out various ways dynamic descriptions can meaningfully impact game play.
11 Aug, 2012, KaVir wrote in the 8th comment:
Votes: 0
Scandum said:
Dynamic descriptions are pointless if they have no impact on gameplay.

Mechanics vs cosmetics: two sides of the...

KaVir said:
Some mud developers have argued in the past that you shouldn't waste time on code that doesn't have a direct effect on the game, yet the benefits of a well-written world are very clear, and I've found the same is true in other cases as well; a cool feature will usually be overlooked or unappreciated if it doesn't also have cool cosmetics. Or as I've phrased it in the past, "Mechanics may be the meat of the game, but cool cosmetics provide the flavour. Even the most well designed of games can feel lifeless and barren without the appropriate cosmetic touches."
11 Aug, 2012, Runter wrote in the 9th comment:
Votes: 0
I wouldn't advise reinventing the wheel. Templating engines are extremely common and well developed technology in a wide variety of language.

For C++, for example, i recommend http://code.google.com/p/ctemplate

#include <cstdlib>
#include <iostream>
#include <string>
#include <ctemplate/template.h>

int main() {
ctemplate::TemplateDictionary dict("example");
int winnings = rand() % 100000;
dict["NAME"] = "John Smith";
dict["VALUE"] = winnings;
dict.SetFormattedValue("TAXED_VALUE", "%.2f", winnings * 0.83);
// For now, assume everyone lives in CA.
// (Try running the program with a 0 here instead!)
if (1) {
dict.ShowSection("IN_CA");
}
std::string output;
ctemplate::ExpandTemplate("example.tpl", ctemplate::DO_NOT_STRIP, &dict, &output);
std::cout << output;
return 0;
}


Hello {{NAME}},
You have just won ${{VALUE}}!
{{#IN_CA}}Well, ${{TAXED_VALUE}}, after taxes.{{/IN_CA}}
12 Aug, 2012, Ssolvarain wrote in the 10th comment:
Votes: 0
I liked how GW2 has the overhead map with the dynamic descriptions. I think that would make a good addition to any over-head type map, especially world maps like we use on End of Time.

I like the idea of hand-written dynamic descriptions, but I think it would ultimately take more time than it was worth. I'd much rather write a description and leave it at that. For some areas, I've gone back and written night-time descriptions, but I don't think that really counts as dynamic.
12 Aug, 2012, arholly wrote in the 11th comment:
Votes: 0
I like the GW2 dynamic descriptions overall. But, I was curious about what people in general thought of the debate.
12 Aug, 2012, KaVir wrote in the 12th comment:
Votes: 0
Ssolvarain said:
I like the idea of hand-written dynamic descriptions, but I think it would ultimately take more time than it was worth.

It really depends how much you want to use them - as with any hand-written description, the amount of detail is up to the builder, and it'll vary from room to room. As I mentioned in the thread I linked to earlier:

KaVir said:
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.

In regard to GW2, it's also worth remembering that I don't use rooms, so traditional room descriptions weren't really an option even if I'd wanted to use them.
12 Aug, 2012, Alathon wrote in the 13th comment:
Votes: 0
I think the concept of dynamic, hand-written descriptions appeal the most to me. Although the concept of entirely dynamic descriptions and natural language is certainly interesting on a theoretical basis (I have to think that, since I work with language processing ^^).

I've mulled over writing a templating engine for the purpose, to provide conditional dynamic formatting for:
- Helpfiles
- Room descriptions
- Mob descriptions
- Object descriptions
- Area descriptions
- Combat

I think you can look at some really, really interesting situations if *anything* on the MUD can be context-sensitive to what your player knows or can perceive of the world around them.

Consider a fictive situation with 3 players: A newbie warrior, a seasoned warrior and a Wizard. The newbie warrior might not have any clue what the hand-waving and odd stuff the Wizard was doing is, but the seasoned warrior might have seen those things sufficiently to know whats going on. They might, as such, see different things.

Or consider a vendor selling items. One player might recognize just a short sword, while another might know blacksmithing well and recognize the metal used and the craftsmanship of the sword.
16 Aug, 2012, KaVir wrote in the 14th comment:
Votes: 0
Alathon said:
I think you can look at some really, really interesting situations if *anything* on the MUD can be context-sensitive to what your player knows or can perceive of the world around them.

As Sandi pointed out in the thread I linked to in my first post, most muds already have something very similar to (basic) dynamic descriptions - colour codes, such as "@R", or "^R", or whatever character you choose to use to indicate colour. And they're parsed at such a low level that they can indeed be used anywhere in the mud.

So really, most muds already have the infrastructure in place to handle the text-replacement aspect of dynamic descriptions. You just need to expand it to handle longer tags and conditional checks.

Also, a couple of related threads for those interested in the subject:

* Dynamic descriptions based on equipment

* Dynamically-Generated Room Descriptions
0.0/14