12 Feb, 2010, Barm wrote in the 21st comment:
Votes: 0
donky said:
Idealiad said:
I'm not that advanced – I'm just going to use Python's format() and string Template from the standard library (2.6). The trick will be to process every string and replace the tokens in a nice way using that.

I've done a lot of Python programming, and that's the way I am expecting to go too.

"{0.name} is a {0.gender} {0.race}".format(actor)
However, unlike in your example, you cannot have arbitrary levels of depth in the formatting brace bits. But then you can just do:

"You're seeking the blarney stone? You'll have to find {0.name},
{0.pronoun_subjective}'ll know where it is.".format(faction.leader('Irish'))
Doing it this way will make it easy to cache fetched data in the local variables, for easy reuse in the string to be formatted.


Wouldn't you run into a bit of a chicken-or-egg issue where you have to know ahead of time each variable that needs fetched? I was picturing lines of dialogue pulled from raw text scripts written by designers. Those would be parsed and the keys and the player object passed to a function that inspects them to determine where to pull the values from;
"Be careful this {calendar.phase_of_day} {player.name}, shadowy figures have been spotted here in {area.name}."

Where calendar would be an imported function, player an argument, and area probably looked up from a method of player. Conceivably, someone could use format strings combined with a dictionary-like object that has an elaborate __getitem__()method.
12 Feb, 2010, Scandum wrote in the 22nd comment:
Votes: 0
Is there a good way to deal with nested braces/parenthesis using regular expressions? That would seem like a problem to me that is easily resolved with a custom parser as you can keep track of the nesting level.
12 Feb, 2010, David Haley wrote in the 23rd comment:
Votes: 0
Scandum said:
Is there a good way to deal with nested braces/parenthesis using regular expressions?

It is actually a formally unsolvable problem, so no, there is no good way. The short version is that regular expressions can't "count" and therefore you cannot find the matching brace if there are other terminators inside. You can however cheat by doing things like processing the inner-most pairs first, and just keep hitting the string with your regular expression until you get no matches. But that is obviously kind of funky. Indeed using a custom parser (such as a straightforward stack-based parser, or stuff like you get from yacc/bison) is indeed more appropriate.

Barm said:
Wouldn't you run into a bit of a chicken-or-egg issue where you have to know ahead of time each variable that needs fetched?

Indeed. I was also thinking about an equivalent to "string.format" in many cases. Using that the strings become more like pre-programmed messages where you fill in a parameter (such as the person whose subjective pronoun you are obtaining). That said, those will get you pretty far I think, if not even cover very many cases, since many messages in the game are indeed pretty straightforward in terms of the parameters they use (an actor, an acted-upon (victim), a thing-acted-with, a place-acted-in, etc.). But to do things like what you describe (where the parameters are not known ahead of time and can really be anything – why not mathematical expressions?) you would need to do something fancier, along the lines of what you've been describing so far.
12 Feb, 2010, Barm wrote in the 24th comment:
Votes: 0
Nope. Regular expressions can't count, so they're incapable of tracking nested levels. There's some limited support for saying "if following X" or "if preceding Y" but that's about it. This is a classic rant on the topic;

http://stackoverflow.com/questions/17323...


Edit:

Yeah, that thing what David said.
12 Feb, 2010, donky wrote in the 25th comment:
Votes: 0
Barm said:
Wouldn't you run into a bit of a chicken-or-egg issue where you have to know ahead of time each variable that needs fetched? I was picturing lines of dialogue pulled from raw text scripts written by designers. Those would be parsed and the keys and the player object passed to a function that inspects them to determine where to pull the values from;
"Be careful this {calendar.phase_of_day} {player.name}, shadowy figures have been spotted here in {area.name}."

Where calendar would be an imported function, player an argument, and area probably looked up from a method of player. Conceivably, someone could use format strings combined with a dictionary-like object that has an elaborate __getitem__()method.

Well, I was looking at it from the level of someone with the ability to specify those arguments perhaps going the scripting route rather than the data-driven one. But that doesn't really matter, it's just implementation detail. Whether you might have a second format that you pass and infer the real Python-level format from, or whether you make them use the Python-level format and specify what gets passed in via drop down boxes per token. No biggie. Not trying to elanthis you or nothing btw.
12 Feb, 2010, David Haley wrote in the 26th comment:
Votes: 0
Barm said:
This is a classic rant on the topic;

http://stackoverflow.com/questions/17323...

That's pretty funny, I'd never seen it before. :smile:
13 Feb, 2010, Idealiad wrote in the 27th comment:
Votes: 0
I have had in mind something like what David posted, where designers can put Python expressions (a whitelisted subset of Python) inside their tokens. I think that's pretty important for making fun interactive areas. Passing those expressions through a script filter shouldn't be that hairy though.
13 Feb, 2010, David Haley wrote in the 28th comment:
Votes: 0
Idealiad said:
I have had in mind something like what David posted, where designers can put Python expressions (a whitelisted subset of Python) inside their tokens. I think that's pretty important for making fun interactive areas. Passing those expressions through a script filter shouldn't be that hairy though.

You should look into sand-boxing (which is the general term for not allowing unwanted operations). In general you have to be really careful with your filtering, or trust your designers to not do dumb things (like infinite loops). Even if you trust them to not be malicious, you still have to make sure that they're not being accidentally silly.
13 Feb, 2010, donky wrote in the 29th comment:
Votes: 0
Idealiad said:
I have had in mind something like what David posted, where designers can put Python expressions (a whitelisted subset of Python) inside their tokens. I think that's pretty important for making fun interactive areas.

Why?

I ask because it sounds like lots more work, and I cannot see the benefits. Of course, I do lots of things in my codebase that are lots more work and most likely others would not see the benefit, so that's hardly a reason not to do it.
13 Feb, 2010, Idealiad wrote in the 30th comment:
Votes: 0
I agree. The general plan is to use just a whitelisted subset of Python with a recursion depth limit. The end result is something not that different from mushcode in terms of flexibility.

edit: donky, I'm imagining a description like:

Quote
The bartender wipes the counter, {one of}chatting with the regulars{or}smiling at the waitress{or}eyeing you{or}a dreamy look in his eye{in random order}.


double edit: obviously that's not Python, but it's the general idea.
20.0/30