12 Oct, 2008, Vassi wrote in the 1st comment:
Votes: 0
Scenario:
You have a sort of theme engine running on your program\mud that lets you define arbitrary style keys. These keys are stored, along with formatting information, so that they can be translated by converters somewhere down the pipeline. In other words, kind of like CSS. The obvious benefits to this kind of support is that you allow your builders to put color in their stuff, without letting them go absolutely crazy. The second benefit is that you can allow your players to change these styles if you like, so they can define their own.

Anyway, so say you define the following two styles:

//Prototype: SetStyle(string key, BG bgColor, FG fgColor, params Format[] formatting)

Styles.SetStyle("exit", BG.Blue, FG.Yellow, Format.Bold);
Styles.SetStyle("item", BG.Default, FG.Red, Format.Italic, Format.Underline);


Now the idea is that when your reporting functions are about to send out some text they first check strings and replace them with accurate representations. For instance, an ANSI reporter would make an "item" tag into <ESC>

Now the idea is that when your reporting functions are about to send out some text they first check strings and replace them with accurate representations. For instance, an ANSI reporter would make an "item" tag into <ESC>[3;4;33m and an MXP reporter would convert the "item" definition into an MXP tag, send it to the client ([i]this part would probably happen by responding to a NewStyle or StyleRemoved event from the Styles class[/i]), and then convert the tag in the string to an MXP compliant syntax.

The real point of this post is, what syntax do you guys like? I'm looking for something unintrusive, easy to remember, but more importantly easy to parse.

For instance, of the following, which would you prefer to use:

"On the ground there is a small %;item;note%, as well as a %;item;broken pen%, you wonder how they came to be there?"

"On the ground there is a small <item>note</item>, as well as a <item>broken pen</item>, you wonder how they came to be there?"

"On the ground there is a small <item: note />, as well as a <item: broken pen/>, you wonder how they came to be there?"

I'm curious about what kind of tokens others have done in the past, and what works and hasn't. I'm kind of partial to the last approach, it's fairly clean and aside from maybe finding a way to escape a regular '<' parsing it wouldn't be too difficult, /> isn't a widely used and average combination. I don't really like <key></key> because it's a little harder to parse, and also implies that we want to allow nesting - which I really have no interest in.

Thoughts?
12 Oct, 2008, kiasyn wrote in the 2nd comment:
Votes: 0
12 Oct, 2008, Vassi wrote in the 3rd comment:
Votes: 0
Very interesting article, I hadn't really thought about something that in depth. Thank you! (Though I still don't like the nesting :P)
13 Oct, 2008, David Haley wrote in the 4th comment:
Votes: 0
In the article's case, the nesting is necessary because you're nesting not colors, but conditionals. In your case, nesting could still be necessary if you want to have two styles at once, one turning on (say) italics and the other color. Whether or not that is actually the case is an interesting question; in ASCII I don't see it really being necessary but in a richer presentation language it could be pretty nice.

I don't think that difficulty of programming a parser should be a factor in deciding, though. In the end of the day difficulty of writing and reading the text for non-technical builders is (IMO) what matters most. Besides, in the scale of things, these parsers are pretty straightforward to write.
13 Oct, 2008, Vassi wrote in the 5th comment:
Votes: 0
DavidHaley said:
In the article's case, the nesting is necessary because you're nesting not colors, but conditionals. In your case, nesting could still be necessary if you want to have two styles at once, one turning on (say) italics and the other color. Whether or not that is actually the case is an interesting question; in ASCII I don't see it really being necessary but in a richer presentation language it could be pretty nice.

I don't think that difficulty of programming a parser should be a factor in deciding, though. In the end of the day difficulty of writing and reading the text for non-technical builders is (IMO) what matters most. Besides, in the scale of things, these parsers are pretty straightforward to write.


I agree, which is why I wasn't planning on allowing for nested variables. Ideally you should have enough styles to cover your situation. The conditional thing kind of took me by surprise, though, I think I'm going to have to ponder it for a little while to consider if it's something worth having. I've also been thinking lately about CoffeeMUD's 'senses' thing, where you can listen or smell things. It'd be nice to have little extra details in a description if you were perceptive enough, or - for instance - if you were skilled enough in a certain craft (Kind of like the effect of Lore in D&D). That way a 'musty old scroll' would contain gibberish to a warrior, but a priceless spell to a wizard.
0.0/5