30 Mar, 2009, David Haley wrote in the 41st comment:
Votes: 0
Sure thing, Mr. Hammer and Nails :tongue:
30 Mar, 2009, elanthis wrote in the 42nd comment:
Votes: 0
I just wanted an excuse to make a blown-out sorority girl joke. So sue me.
30 Mar, 2009, Sandi wrote in the 43rd comment:
Votes: 0
Scandum said:
What if there is both a winter and a night description?


Well, you can have EXTRA_WINTER and EXTRA_NIGHT descs, and I think that answers your point, but you bring up something Kavir touched on - English isn't well suited to this sort of substitution. Even I blanch at the thought of creating seasonal descriptions that can be appended appropriately by a single nighttime description. At some point, the required wordplay takes longer than simply rewriting it all.

Incidentally, for the lurkers, before anyone starts on something like this, you need to consider if perhaps there's something more important you might be doing for your game environment. While weather related, day/night seasonal descs are cool, if, for instance, you were doing a WoD setting, you might wish to exchange descriptions based on the character's perceptions of the Umbra.


Since it's generally considered bad form to include emotions in descriptions, my descs are definitely "object oriented". :rolleyes: I have plans for a system where "rooms" would simply be containers for description objects. Yes, there would be a "room" object, so you could look at the walls and the floor, or the ground and the sky, as appropriate. (there are several directions to go with this idea - one will lead you to KaVir's grid system, another to my original vector system, but this time I'm considering relative placement)
30 Mar, 2009, David Haley wrote in the 44th comment:
Votes: 0
Sandi, it sounds to me like you're talking about something that appends descriptions together, so that you have a "main description" to which you add the day/night description, to which you add the season description, etc. I think that's a little different than what's being discussed here, which is the ability to insert the switches at any point. If you want arrangements to be different, for instance in one case the season affects something at the beginning of the text and in another case the end, and you have more than just a handful of switches, it becomes prohibitive to do it as a single block of text (and the append version doesn't work in the first place).
30 Mar, 2009, Kayle wrote in the 45th comment:
Votes: 0
KaVir said:
Sandi said:
Well, me too, and in my experience this:



will be a maintenance nightmare.


Well yeah it was a poor example, as he's repeating the same text over and over. In reality the description would look more like this:

You are [#position] within the [#season winter: frigid] expanse of the famous Darkhaven 
Square. A stone statue of something occupies the square's center, surrounded by

[#season summer: gardens of flowers in full bloom which enhance the air of serenity and peace]
[#season spring: gardens of budding flowers which fill the air with lovely fragrances]
[#season fall: gardens of wilting flowers as winter fast approaches]
[#season winter: an army of snowmen the children of the city have built]

here in the center of the city. The main road lead away in the cardinal directions, while to
the northeast and northwest are forested paths

[#season fall: of many color falling leaves]
[#season winter: which are still lightly covered in snow]

. The spires of a cathedral can be seen rising to the northwest.


That's exactly right, KaVir, although I hadn't thought about the [#position] thing. But yes, the nightmare that is the current test description is strictly for testing. I didn't want to have to read the description each time to see if anything changed. By just repeating the same text over with subtle seasonal changes, I was able to make each one different enough once formatted to wrap around the automap that it was rather easy to tell the difference. Descriptions actually using this system will look a lot more like the example KaVir gave.
30 Mar, 2009, Sandi wrote in the 46th comment:
Votes: 0
David, we're on the same page. I'm talking about inserting phrases. I'm saying don't inline them in the desc paragraph, set them out as in KaVir's example. To counter a complaint about changing the format, I suggested encoding the format that was already there. Soon, I'll be suggesting it all be done with Lope's Colour Codes. :wink:

I just figured out my real problem with this - if you're doing things like day/night and seasons, they should be done globally, as they'll affect every room. The room desc should be parsed for local options.
30 Mar, 2009, David Haley wrote in the 47th comment:
Votes: 0
Oh, I see, never mind then :smile:

Sandi said:
I just figured out my real problem with this - if you're doing things like day/night and seasons, they should be done globally, as they'll affect every room. The room desc should be parsed for local options.

Wouldn't some rooms react differently to day/night/seasons? The town square might be illuminated by streetlamps, whereas the alleyway is dark without the sunlight.
30 Mar, 2009, KaVir wrote in the 48th comment:
Votes: 0
David Haley said:
Wouldn't some rooms react differently to day/night/seasons? The town square might be illuminated by streetlamps, whereas the alleyway is dark without the sunlight.

Indeed, although I suppose you could add a few terrain-specific defaults if you wanted to, and then insert "[#city time]" or [#forest winter]" or whatever into the description. Alternatively you could tell your builders not to mention time or season specific details in static descriptions (I believe many muds do that anyway).
30 Mar, 2009, kiasyn wrote in the 49th comment:
Votes: 0
01 Apr, 2009, shasarak wrote in the 50th comment:
Votes: 0
Seems to me that it would be better to have the room's description be a value returned from a method rather than trying to wrap everything up in a single coded string. Sooner or later you're bound to have something which depends on more than one variable at once (e.g. if it's night and it's winter and the moon is up then the snow on the path might glow softly in the pale light of the moon, but if it's summer there's no snow, and if the moon is below the horizon there's no moonlight, and if it's day-time there's no pale moonlight even if the moon is above the horizon). I'm not saying you can't do all that with a coded string, but it rapidly gets to the point where it becomes almost impossible to debug because you can't tell what the string is doing just by looking at it.

The better way, therefore, is to make the room_description function call other functions to determine each part, or even (as previously suggested) for the room description to be generated in a recursive fashion from the descriptions of the scenery objects the room contains.

Edit: And, just to stop Cratylus from saying it… 50!!!
01 Apr, 2009, KaVir wrote in the 51st comment:
Votes: 0
shasarak said:
Seems to me that it would be better to have the room's description be a value returned from a method rather than trying to wrap everything up in a single coded string.

But then you're moving towards generated descriptions, a step many MUDs don't want to take. The beauty of the approach discussed here is that (once implemented) any description can be made dynamic without any coding effort, while existing static descriptions continue to be displayed exactly as they did before. You don't even need to change any of the old descriptions if you don't want to, or you could just tweak a few - if you felt like it.

Dynamic descriptions certainly have the potential to become complex, but you could argue the exact same thing about (for example) mobprogs. Both can be valuable tools for builders, as long as they're used with care.
01 Apr, 2009, elanthis wrote in the 52nd comment:
Votes: 0
shasarak said:
Seems to me that it would be better to have the room's description be a value returned from a method rather than trying to wrap everything up in a single coded string. Sooner or later you're bound to have something which depends on more than one variable at once (e.g. if it's night and it's winter and the moon is up then the snow on the path might glow softly in the pale light of the moon, but if it's summer there's no snow, and if the moon is below the horizon there's no moonlight, and if it's day-time there's no pale moonlight even if the moon is above the horizon). I'm not saying you can't do all that with a coded string, but it rapidly gets to the point where it becomes almost impossible to debug because you can't tell what the string is doing just by looking at it.


It's not an all-or-nothing approach. You can let simple rooms have static room descriptions. You can let very complex rooms have an overloaded showDescription method that does some fancy-ass scripted logic. And in between, you can have simple markup because that's a crapload easier to write and to read than the equivalent script code.

I would have suggested that the OP use a slightly more flexible format, but that in turn requires a more complicated parser, and it's better to start simple for a first attempt. Eventually he could build it up to use a start/end tag approach, e.g. Blah blah blah [winter][night]The moonlight reflects off the snow.[/night][day]The winter Sun blindingly reflects off last night's wet snow.[/day][/winter] Blah blah blah. That's pretty simple. The script alternative would likely end up being bigger and harder to grok, e.g.

ch.print("Blah blah blah");
if (world.weather == WINTER) {
if (world.time.isNight())
ch.print("The moonlight reflects off the snow.");
else
ch.print("The winter Sun blindingly reflects off last night's wet snow.");
}
ch.print("Blah blah blah");


Yeek, ugly. The method might be useful for really complex descriptions, but I wouldn't want to be forced to use that for the simple stuff.

Btw, nothing stops the simple markup from having object-dependent descriptions, either. Just depends on how powerful you make the tags. Nothing stops you from having a [has-object <tag>] [/has-object] (or [has-object <tag>: <text>]) tag that can display conditional text based on an object being there.

The OP's syntax could be extended with an else clause, too, for making some descriptions a bit easier to deal with. e.g. [weather winter: text if its winter: text if it's not winter]

Really no limit to what you can do. Heck, if you have a suitably flexible script engine, you could just use that as the code in your tags (which I plan on doing to replace AweMUD's crufty nasty-ass parser with Lua), e.g. [blah]foo[/blah] would get replaced with if blah: print "foo"; end, and then a {blah} would get replaced as literal code. All within a highly restricted Lua environment that really just exposes read-only properties and such, of course.
01 Apr, 2009, David Haley wrote in the 53rd comment:
Votes: 0
The proposal I made to Kayle after playing around with it exploits some nifty Lua syntax.

You are [#position] within the [#test(season == "winter") "frigid"] expanse of the famous Darkhaven
Square. A stone statue of something occupies the square's center, surrounded by …..


where the Lua environment is set to hook back to C to get values for things like position, season, etc. (using __index and not __newindex naturally); where a tag's text is set to the evaluated expression; where test is a function that returns a function that returns its argument if the condition is true, and nothing if the condition is false.

Although I'm not completely satisfied with the syntax, I think it's quite close to a very simple tag approach, while exploiting a lot of the moony goodness that Lua gets you.

This way, you can test basically arbitrary boolean conditions, and if you really wanted to, you could in principle embed arbitrary code in there too at the expense of it being ugly.
01 Apr, 2009, elanthis wrote in the 54th comment:
Votes: 0
Yeah, that's exactly what I was thinking. The __index metatable method trick is useful in so very many ways.

With a little more effort you can transform a slightly cleaner tag syntax into the Lua code and make it look prettier.

AweMUD had a whole custom grown scripting system for parsing stuff, which was retarded, but a good learning exercise at the time. Tags would be something like:

{if test}some text{elif test}different text{end}

basic boolean expression support, special methods on objects (so you could do something like viewer.height > large), and macro variables. Overengineered piece of crap in the grand scheme of things, I should've just used Lua (or Ruby, which was the engine I had embedded at the time) instead. Live and learn, I guess.
01 Apr, 2009, David Haley wrote in the 55th comment:
Votes: 0
elanthis said:
With a little more effort you can transform a slightly cleaner tag syntax into the Lua code and make it look prettier.

Yeah, I was thinking about using a colon to delineate the expression from the text, so that instead of
[#test(season == "winter") "frigid"]

you'd have
[season == "winter": "frigid"]

Not totally happy with that since the colon can actually mean something in Lua therefore you'd have to escape it or whatever, but you could come up with other schemes that would work nicely I would imagine.

(EDIT: this is close to the original syntax in this thread, naturally)

The other not-so-nice thing is that the text needs to be quoted to parse as a Lua expression; if you told Lua to treat it as a string then you wouldn't be able to put arbitrary code in there.

I'm inclined to just go with the test function that returns the function that returns the string or not depending on the expression value.
01 Apr, 2009, elanthis wrote in the 56th comment:
Votes: 0
Quoting isn't hard.

You could also go totally l337 k0d3R and just generate Lua bytecode directly. :) [It's actually easy, relatively speaking]
01 Apr, 2009, Scandum wrote in the 57th comment:
Votes: 0
Sandi said:
Since it's generally considered bad form to include emotions in descriptions, my descs are definitely "object oriented". :rolleyes: I have plans for a system where "rooms" would simply be containers for description objects. Yes, there would be a "room" object, so you could look at the walls and the floor, or the ground and the sky, as appropriate. (there are several directions to go with this idea - one will lead you to KaVir's grid system, another to my original vector system, but this time I'm considering relative placement)

I considered the same thing, though more for a prince of persia like climbing adventure than cosmetic reasons. n e s w u d c (center) would be logical keywords for placement of objects.
40.0/57