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

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.

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.

I posted a summary a few years ago:


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

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?

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.

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.

Mechanics vs cosmetics: two sides of the...

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}}

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.

I like the GW2 dynamic descriptions overall. But, I was curious about what people in general thought of the debate.

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:


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.

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.

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