Dialogue token parsing

Dialogue token parsing

Schala Zeal

Member #11,509

November 2009

I'm designing an RPG using C++ and Lua with LuaBind and well, in certain dialogue I want there to be some pausing in the dialogue like when the character says something like "Uh... well... you know..." I was wondering if there was a way to put tokens like everytime my program read something like "{pause 1}" in the string, it would trigger a call to a function that would pause the dialogue text for a second before displaying more.

kazzmir

Member #1,786

December 2001

That sounds reasonable to me. The way I would do it is have some special syntax meaning "escape to code from raw text" so you can write

Hello there. I am a character in an RPG and blah blah ${pause 1} so therefore blah blah ${pause 1}.

So whenever you see $ you start read an entire expression enclosed in {} and do something with it.

Schala Zeal

Member #11,509

November 2009

Yeah, I felt { and } would be good delimiters since it's very uncommon to see those characters in a dialogue, plus C# seems to use it for arguments in strings. So, how would I be able to do this? After all, I might want the $ sign if a character were to say something like "I just got $100!"

I searched Boost's documentation for strings/parsing/etc but it's very complicated to understand the documentation.

kazzmir

Member #1,786

December 2001

You have to escape the special character if you want to use it as a literal. So if $ was the magic character to start reading code then $$ would be used to represent a literal $.

RPG text wins $$100 dollars ${pause 1} and then $$200 dollars.

A simple solution to do this parsing is to split up the original string into a bunch of other strings separated by ${...}. You can go through the original string character by character and decide to append it to the current string or to start a new string.

String original; // passed in
List strings;
String current;
for character in original {
  if character == "$" then
    strings.add(current)
    current = ""
    // parse the {...} expression
  else
    current += character
  end
end

Or something.

Schala Zeal

Member #11,509

November 2009

Okay, I assume 'current' is the buffer 'original' is being read into? Your example operates on it while it is uninitialized -- that is "String.add(current)"

Also, this really doesn't seem like C++ but more like C#.

EDIT: Or is it Lua? I'm confused

kazzmir

Member #1,786

December 2001

Its psuedo-code. `current' is supposed to represent the current piece of the input that does not contain any ${pause 1} expressions.

`original' is the full text string you want to work with. At the start you would have:

original = "hello world this is an rpg ${pause 1} ok good job"
current = ""

Then you go through each character in original, 'h', 'e', 'l', etc. until you hit the $. At that point you have

current = "hello world this is an rpg ";

And since the character that you are looking at is $ you would add `current' to the list of strings. Then you have to do some more parsing (which I didn't show) to deal with the {pause 1} part.

Audric

Member #907

January 2001

Side note: When you start adding non-text in string, it gets more difficult to do the line wrapping (assuming fixed-width font):

If the line-wrapping is hard-coded, you can no longer rely on the visible length of the source code.
If the line-wrapping is dynamically counted, you can no longer rely on the length of strings in characters - you need the length-counting to understand these escape sequences too.

bamccaig

Member #7,536

July 2006

Or if it's a consistent behavior, you might get away with pausing at certain cues, such as "..."

--
I mean the best with what I say. It doesn't always sound that way.

Peter Wang

Member #23

April 2000

If ${ will never appear in text (pretty likely) then you don't need $$. Just check if the character after $ is {.

Thomas Fjellstrom

Member #476

June 2000

bamccaig said:

Or if it's a consistent behavior, you might get away with pausing at certain cues, such as "..."

Well a period is generally a normal full stop, and you'd pause there. And two, or more would indicate a longer pause. So I don't see why you couldn't just use those, in most cases.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro SVN Snapshots] - [Allegro TODO] - [Web Hosting]
"God Bless Joe Pesci" -- George Carlin
"Goto is the buldozer of coding. Sometimes, the buldozer is just the right tool for the job. Not often, but sometimes." -- LordBob

Arthur Kalliokoski

Member #5,540

February 2005

I was making a hyperlink help thing a dozen years ago, and used '`' (backtick) and '~' (tilde) for stuff like that because I never used them in normal text.

I really admire the U.S. Constitution. It's so much better than what we have now.

Schala Zeal

Member #11,509

November 2009

I'm rather concerned about the parsing potentially slowing down the game.

Arthur Kalliokoski

Member #5,540

February 2005

If you're computer is a 286 or better, I wouldn't worry about it. Unless the text is several megabytes long.

I really admire the U.S. Constitution. It's so much better than what we have now.

Jonatan Hedborg

Member #4,886

July 2004

Whatever you go with, make sure the player can fast-forward through the text... there is nothing worse than having wait through an "artistic" dialogue for no good reason

(also, some people are bothered when text is printed character by character, since it takes focus from whatever you are reading to the end of the line because it's moving)

-------
Sweden: Free from the shackles of Democracy since 2008-06-18!

bamccaig

Member #7,536

July 2006

Read character by character, storing them in an output buffer. When you find a period ('.'), and maybe also a comma (','), flush the buffer to the dialog and signal a delay in the text processing. Repeat that process, beginning where you left off in the input buffer. Or, if you don't want ellipses to be "animated" (i.e., one period at a time) then read until you find a not-period character before flushing the buffer, incrementing the delay for each sequential period.

If the user presses a key while the dialog is being processed, jump to a read-all section and just flush the entire buffer.

--
I mean the best with what I say. It doesn't always sound that way.

gnolam

Member #2,030

March 2002

Jonatan Hedborg said:

(also, some people are bothered when text is printed character by character, since it takes focus from whatever you are reading to the end of the line because it's moving)

Also, because it's always printed slower than our regular reading rate.

But even if it's sped up it will still actually interfere with the human reading process, in which characters and words further ahead in the text are used to help decode the current word(s).

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

bamccaig

Member #7,536

July 2006

Indeed, it's probably best to leave a configuration option in a sub menu to disable that feature game-wide so users don't have to keep hitting keys to draw all of the text. Those that read slow or like the effect can keep it and those that are annoyed by it can disable it entirely. Everybody wins.

--
I mean the best with what I say. It doesn't always sound that way.

Schala Zeal

Member #11,509

November 2009

Well I don't want to display it as if it's being typed. I want to display it as if someone's speech is being processed.

Like if someone says "Well... uhm... you see... I..." you're likely to get pauses. I'll offer such an option but for realistic purposes I want to display it as if a confused person in some cases were talking. Like, suppose there's a character telling a lie. When being dishonest, people often stop to think in the middle of talking.

I'm talking about brief pauses of course.