Welcome, Guest. Please login or register.

Pages: [1] 2 3 ... 7
Print
Author Topic: Proposal: Dialog System Implementation  (Read 33219 times)
trained circus idiot
Community member

Posts: 7



View Profile
« on: June 19, 2009, 05:56:11 AM »

Hello again,
and more apologies because I am new to wiki formatting and probably made a bit of a mess of it. That said, here's a link to a simple proposed syntax for a dialog scripting language: http://wiki.parpg.net/Proposals:Dialog_Implementation
I've included a sample script below (as I was running into issues adding it to the wiki). The placeholder grammar is admittedly rather ugly and suggestions to fix that are welcome (as is any input in general), but my primary concern is with identifying and addressing any gaps in the functionality before moving on with the implementation. The script's ugliness is potentially a non-issue, if there is a decent dialog editor.

Code: ("sample script")
#sample dialog script
#offers the player 3 choices and insults them if they choose the 3rd one
#Thu Jun 18 23:27:06 EDT 2009


#special variables
$(DBOX_TITLE) string Hello World
$(DBOX_IMG) string images/sample_npc.png

#if we've already played this dialog then skip to START (bypassing the init section below)
!$(previously played dialog)
@START

#mark this script as previously played/started
$(previously played dialog) bool true

#set some variable, case sensitive, no other rules really
#you can set them anywhere in the dialog script but they do not have a value until then
#unset variables will eval as 'false'
$(failed) bool false
$(current insult) string kind sir
#we can have long space-filled variable names
$(bad choice text variable) string don't choose this one


#start section, the label is for our benefit, the interpreter doesn't treat any of them specially
[START]
"Prepare for the ultimate choice!
#flush the dialog before displaying the choice, for good measure
^

[CHOICE_MENU]
$(DBOXTITLE) string Choice Menu
#choice sections begin ?? followed by the choice menu title, if any
??choose one, $(current insult):
?  this is a good choice
>GOOD_CHOICE
?  another option
>GOOD_CHOICE
?  $(bad choice text variable)
>BAD_CHOICE
#this ends the choice section
??


[BAD_CHOICE]
#they chose badly (we told them not to)
#give them another chance if they're not marked as STUPID
!$(STUPID)
@FAILURE

$(STUPID) bool true
$(insult) string you nancy boy
$(bad choice text variable) string i said DON'T choose this

[SILLY_SECTION]
#cat sailor gives them some advice!
#back up the current NPC image before we change it
$(NPC image backup) string $(DBOX_IMG)
$(DBOX_IMG) string images/cat_sailor.png
$(DBOX_TITLE) string Cat Sailor
"In the name of cat sailors everywhere, I beg you please reconsider!
^
#restore the NPC image
$(DBOX_IMG) string $(NPC image backup)

#jump back to the choice menu
@CHOICE_MENU


[GOOD_CHOICE]
#we don't have to have our sections in any particular order
$(DBOX_SND) string sounds/applause.ogg
#cheer 3 times
$(DBOX_SNDLOOPS) int 2
$(DBOX_TITLE) string WINNER! ^_^
"Congrats, $(insult)!
!$(STUPID)
#evals connect to the next actual line of code, skipping comments and such
@GOT_IT_SECOND_TRY
"Thanks for playing.
#E stands for exit, and the number following is the exit code to give
E8008135


[GOT_IT_SECOND_TRY]
"That's more like it.
E 1


[FAILURE]
$(DBOX_IMG) string images/failure.png
$(DBOX_TITLE) string you are dead X_X
$(DBOX_SND) string sounds/boo.ogg
$(FAILED) bool true
#variables for fun
$(intelligence stat) string IQ
$(insultingly low value) int 28
"when your $(intelligence stat) rises to $(insultingly low value), sell ($(insult)).
"you have failed.
#numbers can have whitespace between them and the first char, if you want
E 0

Addendum:
My reference documentation for the prototype, which didn't translate particularly well into the wiki.
Code: ("Quick Syntax Reference")
$(VARNAME) string your mom
  creates or sets a variable named VARNAME of type 'string' with
  the value 'your mom'. valid types are int/float/bool/string.

[SECTION_LABEL]
  denotes a section (in this case, SECTION_LABEL). used by jumps.

@TARGET_SECTION
  jumps to the section specified. target section number
  can be a variable (@ $(EXIT_SECTION) for instance)

!$(VARNAME)
  evaluates the variable (in this case VARNAME) as true or false
  and skips the next command if the eval was false (comments are skipped when
  searching for the next command)

??choice menu title (not the same as caption)
  choice sections begin ?? followed by the menu title, if any

?choice text
>6
  ? specifies a choice item, the > indicates what section to go to if that
  choice is selected (variables are allowed)

"dialog text with $(example variable)
  sends a line of dialog to the dialog box (which handles the line wrapping)
  any variables will be interpolated before sending the line.

'dialog text
  sends a line of dialog text to the dialog box without interpolating variables

^
  flushes the dialog buffer, causing any dialog to be immediately displayed.
  the next lines of dialog will not be shown until the user has pressed a
  button.

E8008135
  flushes the dialog buffer and then exits the dialog script returning the
  value following E (in this example "8008135").

dialog system special variables
the effect will take place on the next dialogbox displayed

DBOX_TITLE
  evaluated as: string
  effect:
    used to set the title/caption of the dialogbox

DBOX_IMG
  evaluated as: string
  effect:
    determines the image file to load and display in the dialogbox

DBOX_SND
  evaluated as: string
  effect:
    determines the sound file to load and play
    the value is auto automatically cleared and the sound stopped when
    the dialog box is closed

DBOX_SNDLOOPS
  evaluated as: int
  effect:
    determines how many additional times to play the dialogbox sound.
    a value of 1 plays the sound effect 2 times total. -1 will attempt
    to loop forever. automatically reset to 0 when closed.

« Last Edit: June 19, 2009, 06:08:07 AM by trained circus idiot » Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #1 on: June 19, 2009, 08:37:54 AM »

I like the idea, how you want to direct the dialoge. Two things though:

1. Window manager: I think the general idea is to use pychan for any UI stuff, as it tightly integrates with the FIFE engine. Please have a look at it if it serves your purposes well. Smiley
2. Why reinvent the wheel? Do you have a special reason to use your data-format like this? Otherwise I suggest adapting it to XML. Saves us the troubles of writing our own parser etc. Smiley

Keep up the good work. Smiley
Logged

zenbitz
Community member

Posts: 1164



View Profile
« Reply #2 on: June 19, 2009, 09:41:43 PM »

One of our first programmers (Icelus why haf thou forsaken us!) had some strong arguments against using XML.
Uh, I am sure they are on the wiki somewhere. ...

http://wiki.parpg.net/Proposal:Story_Engine doesn't seem to rail against XML, so maybe I am misremembering.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
maximinus
Community member

Posts: 694



View Profile Email
« Reply #3 on: June 20, 2009, 02:33:00 AM »

XML is too wordy and hard to read as normal text.

Secondly, writing a parser is fairly easy.
Logged

Science is open-source religion
trained circus idiot
Community member

Posts: 7



View Profile
« Reply #4 on: June 20, 2009, 07:38:10 AM »

I like the idea, how you want to direct the dialoge. Two things though:

1. Window manager: I think the general idea is to use pychan for any UI stuff, as it tightly integrates with the FIFE engine. Please have a look at it if it serves your purposes well. Smiley
2. Why reinvent the wheel? Do you have a special reason to use your data-format like this? Otherwise I suggest adapting it to XML. Saves us the troubles of writing our own parser etc. Smiley

Keep up the good work. Smiley

Thanks for the input.
I understand that PyChan is used for all the GUI components, so I'll have to add that to the list of things to learn. The dialog box should be a pretty simple/light layer over PyChan. In regards to that, I would be interested to hear what people's opinions (particularly from the artists) are in regards to the use of NPC portraits (like in my mock-up on the wiki) vs. using the large transparently backed portraits that you see in many of the newer RPGs. Is changing the portrait image sufficient for displaying changes in NPC mood/emotion or should a more elaborate system (potentially animated) be added?

As for using XML, I don't have anything particular against it but I don't expect it would make the scripts any easier to read. If you wanted to show an example of what an XML version of a dialog script might look like, that would help in evaluating the usefulness of XML for this particular task. I rolled my own format simply because I viewed the dialogs as being more script than data, and this particular script format was trivially implemented (in C/C++/SDL/SDL_mixer). If people are going to be working directly with the scripts (as opposed to using a GUI dialog editor) I think it would probably benefit from being given more self-apparent command names, i.e. replace '!' with an 'if/then' construct, '^' with a 'flush()' or something similar, etc..

My own proposed updates to the above spec are as follows.

Add variable scoping/namespaces. There should be a way for scripts to have instance specific variables (such as for controlling script flow) without having to worry about clobbering or inheriting other variables (or cluttering up save-states or system memory). There should also be variables that persist between instances of the script interpreter. An amendment to the above syntax could be something along the line of:
Code: ("namespace and persistence example syntax")
#set the local namespace for this script
$:default local namespace:
#set the persistent namespace for this script
%:default persistent namespace:

$(local variable name)
%(persistent variable name)

#use a local variable with a different namespace
$(other local namespace:local variable name)
#use a persistent variable with a different namespace
%(other persistent namespace:persistent variable name)
which would add a restriction to variable names such that ':' would not be allowed.

Another potential concern is how to handle internationalization/translations. I'd assumed that dialog scripts would be stored as individual text files and so translations would be stored in an appropriately name alternate directory. For instance, if dialogs are stored in 'data/dialogs/' then french versions of the scripts would be stored in 'data/dialogs_fr' or something similar. The layout/search could even be designed such that untranslated/missing scripts would fall through to the default (english), allowing for partial/incremental translations. The downside of that scheme is that changes to a dialog script's flow that do not effect any of the dialog displayed would still require rewriting/reorganizing all of the translated scripts.

How dialog scripts are triggered and/or attached to objects and NPCs should also be clarified. Has there been any example scenario or run through of the game's story/dialog/gameplay?
Logged
tie
Community member

Posts: 77


View Profile Email
« Reply #5 on: June 22, 2009, 08:42:16 AM »

Please, don't use '$' in front of variables - nothing good ever came out of it Smiley /joke

Icelus did have some good arguments agains using XML for dialogue. The main one was that XML is a tree structure. Dialog choices however, are not really trees - they could loop, grow new branches, etc. Implementing looping in XML structures seems like a Bad Idea (TM) (http://www.youtube.com/watch?v=AXEqoWWN9TY) .

He was also on a way to performing quite a feat by writing the infamous story engine (that would actually drive all game events). Sadly, I don't think we could finish up his work, or even reproduce it.

Creating a custom script language that drives the dialogs and other game events is a complicated task. My suggestion is to avoid it altogether. Instead, we can have dialogs (and game events) coded in Python. I can already hear the screams -'But, but, but... how will the non-technical content creators get around this?'. Well, tough luck Smiley Think about it though - is basic Python usage really that harder than the script posted by trained circus idiot? I'm pretty confident that once a writer creates 2-3 scripts with the help of a dev, the writer will start whipping out new scripts on their own like there is no tomorrow. While we won't have to write some confusing, hard to maintain, and in the end - less flexible scripting engine.

So, my vote goes to using Python  code directly instead of inventing our own dialog language.
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #6 on: June 23, 2009, 12:06:48 AM »

I was a supporter of "write it in python" but I know python, and I know lots of "half-assed programmers"

Icelus (it's like he's a Saint now or something) hated the idea of exposing programming to the unwashed masses of content designers.  I suspect that we will get more than a  couple programmer-types (like myself) writing dialogues, so I would be in favor of using python for all PARPG scriping purposes.

It might makes sense to *cripple* python a little bit (make a scripting wrapper with restricted interfaces) so that content devs don't have any access to protected methods (IIRC, python doesn't really protect interfaces).

A good example of this (IMO) in the scientific world is pymol:  http://www.pymol.org which has an entire command-line interface written in python.  It's for super structural biologist nerds, but I think that anyone who is writing a "script" for a game has to have some concept of "control-flow" and "loop" (which is what Saint Ice hated)
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
trained circus idiot
Community member

Posts: 7



View Profile
« Reply #7 on: June 23, 2009, 07:58:58 AM »

Please, don't use '$' in front of variables - nothing good ever came out of it Smiley /joke
...
Creating a custom script language that drives the dialogs and other game events is a complicated task. My suggestion is to avoid it altogether. Instead, we can have dialogs (and game events) coded in Python. I can already hear the screams -'But, but, but... how will the non-technical content creators get around this?'. Well, tough luck Smiley Think about it though - is basic Python usage really that harder than the script posted by trained circus idiot? I'm pretty confident that once a writer creates 2-3 scripts with the help of a dev, the writer will start whipping out new scripts on their own like there is no tomorrow. While we won't have to write some confusing, hard to maintain, and in the end - less flexible scripting engine.

So, my vote goes to using Python  code directly instead of inventing our own dialog language.

Firstly, it might be relevant that I am not yet familiar with Python (I have only yesterday started reading through the Python documentation tutorial). Not knowing Python is why I haven't been more eager to participate in PARPG development before this.

Secondly, I finally got involved in PARPG because maximinus's comment on the dialog system in this thread (Towards tech demo 1) that, of the listed features, only implementing dialog with NPCs "could be tough" seemed to me like a challenge. I like challenges, so I gave it a shot with the tools that I am familiar with (C/C++/SDL/SDL_mixer in this case) and had it designed and implemented within a day (hence the rather affected style which uses a single char to determine what sort of line/command it is).

I don't have any particular attachment to having variables start with '$'; I only used that because it tied in with my shell and makefile experience and $(VARNAME) is quite easy to match, even in plain C.

Also, the above scripting thinger isn't meant to be a general scripting language, but rather the more or less bare bones of functional scripting required to do (fairly complex) dialog. It would probably be easier to read if I had done it in PERL instead of C, and so I assume Python would make it equally trivial to have descriptive command names and such.

As for whether it would be useless to implement a dialog script system and we should instead commit to teaching the dialog writers sufficient Python to accomplish whatever they need to do is still open to debate, at least in my opinion. The judges (and/or script syntax designers) should probably be the writers who are going to use the system (that is, they should go through sample dialogs with pen-and-paper and see what they need and how they want to describe their needs). Even if straight Python is chosen in the end (and it makes sense, since it ALREADY IS a scripting language) the writers should have input as to the naming and calling style of the functions that they'll be using (as Djikstra said back in the 70's, you should write as if you were working in a very high level language that does exactly what you want and then write the virtual machine for that language (continue with this until you hit the actual implementation language)).
Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #8 on: June 23, 2009, 03:38:50 PM »

In my opinion something like you proposed is required to do storry scripting. We are right now in the design process and this is part of it. Please feel free to contribute! Smiley

About teaching writers python: I'd rather write an editor once we have a solid structure for the story. One that visualizes dialogue in a simple graph and it more a WYSIWYG editor. Cheesy But I don't know if we have the resources to do something like that within a reasonable amount of time.

But first of all we have to decide on the underlying structure.
Logged

zenbitz
Community member

Posts: 1164



View Profile
« Reply #9 on: June 23, 2009, 04:48:14 PM »

What about some kind of templating language?

http://template-toolkit.org/python/index.html

I have used this in perl (yes with $s) and it has some nice features.  It can be a little too tempting to stick too much logic and "model" in the "view" if you know what I mean, but it's probably a tiny bit simpler than python (no whitespace issues)
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
maximinus
Community member

Posts: 694



View Profile Email
« Reply #10 on: June 23, 2009, 04:56:45 PM »

I don't think the hard writing is the dialog logic, it's coming up with a easy method for the writers.

You can easily end writing a mini language, which leads you logically to using Python (or a sub-set of). But it doesn't feel right to me to have a huge bunch of extra Python code for all the custom dialog. And it just plain doesn't seem nice to demand writers to learn Python, no matter how good it is.

So maybe let's start with a core library to actually handle scripts, and then build a language or dialog builder around that. I know the language is important, and that will mean a lot of thought has to be put into it. But the underlying Python should be a lot simpler to write.
Logged

Science is open-source religion
tZee
Community member

Posts: 190


View Profile Email
« Reply #11 on: June 23, 2009, 05:01:16 PM »

I think we can even avoid the language thing all together, thanks to pickle. We just need the internal data-structures, as they will be held in memory, and pickle/unpickle them, and not worry about the saving format at all. Only piece missing would be the creator of those structures, an editor of some sorts.
Logged

maximinus
Community member

Posts: 694



View Profile Email
« Reply #12 on: June 23, 2009, 05:30:45 PM »

I think we can even avoid the language thing all together, thanks to pickle. We just need the internal data-structures, as they will be held in memory, and pickle/unpickle them, and not worry about the saving format at all. Only piece missing would be the creator of those structures, an editor of some sorts.

Unless I'm getting confused here, I'm thinking the language WILL essentially be the dialog editor?
Logged

Science is open-source religion
tie
Community member

Posts: 77


View Profile Email
« Reply #13 on: June 23, 2009, 06:26:04 PM »

If everything that we care about will be the dialogue, there are no problems to come up with an easy system. As Zenbitz pointed out, templates fite nicely (ex: jinja, django or cheetah for the $ lovers). We can have these either way.

However, the game stories are not consisted of just dialogue. The bigger problem is let the non-technical game creators control the 'event' side of this. See an example of a quest arc as it was expected in the story engine Icelus was writing:
Quote
"Rescue princess"
-----------------
("guard") to "PC": 'I will help you get her majesty away from here!'
Beforehand:
-    ("guard") is nearby.
-and ("guard") is loyal.
Afterwards:
- begin "princess rescue arc" with ("guard") as "princess guard".

"Princess rescue arc"
=====================
Cast: a "princess guard".

* "princess guard": 'My name is {"princess guard"s "name"}'.

"Guard" here is not a predefined NPC - it is decided at gametime who exactly guard is. For example, there could be a fight beforehand, and some of the guards stay alive, some don't. At game time 1 guard is selected to start this plot arc.
This is 90% action, 10% dialogue. How will the non-techical writes create such a content?

Check:
http://wiki.parpg.net/Proposal:Story_Engine
http://wiki.parpg.net/Proposal:Story_Format

So, again, the dialogue by itself is a small problem. However, it is a part of the bigger picture - stories, quests, scripts,etc. We should figure out the big picture before we try to implement a dialogue system.
Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #14 on: June 23, 2009, 06:44:41 PM »

I think we can even avoid the language thing all together, thanks to pickle. We just need the internal data-structures, as they will be held in memory, and pickle/unpickle them, and not worry about the saving format at all. Only piece missing would be the creator of those structures, an editor of some sorts.

Unless I'm getting confused here, I'm thinking the language WILL essentially be the dialog editor?

The problem with that you have to teach the writers the language first. And it makes visualizing the flow of the story-lines at a more advanced stage quite hard.

If everything that we care about will be the dialogue, there are no problems to come up with an easy system. As Zenbitz pointed out, templates fite nicely (ex: jinja, django or cheetah for the $ lovers). We can have these either way.

However, the game stories are not consisted of just dialogue. The bigger problem is let the non-technical game creators control the 'event' side of this. See an example of a quest arc as it was expected in the story engine Icelus was writing:
Quote
"Rescue princess"
-----------------
("guard") to "PC": 'I will help you get her majesty away from here!'
Beforehand:
-    ("guard") is nearby.
-and ("guard") is loyal.
Afterwards:
- begin "princess rescue arc" with ("guard") as "princess guard".

"Princess rescue arc"
=====================
Cast: a "princess guard".

* "princess guard": 'My name is {"princess guard"s "name"}'.

"Guard" here is not a predefined NPC - it is decided at gametime who exactly guard is. For example, there could be a fight beforehand, and some of the guards stay alive, some don't. At game time 1 guard is selected to start this plot arc.
This is 90% action, 10% dialogue. How will the non-techical writes create such a content?

Check:
http://wiki.parpg.net/Proposal:Story_Engine
http://wiki.parpg.net/Proposal:Story_Format

So, again, the dialogue by itself is a small problem. However, it is a part of the bigger picture - stories, quests, scripts,etc. We should figure out the big picture before we try to implement a dialogue system.

That is why we decided to postpone work on this approach and do a simpler approach. In this case that would be hardcoding guard to one agent.
Logged

Pages: [1] 2 3 ... 7
Print
Jump to: