You might want to download some files mentioned in the explanations below. These files were initially taken from the current version of FreedroidRPG, but as the game and dialog is subject to change, the material might not be inside the game any more by now or it might already look completely different. So for reference, the dialogs mentioned in the text are provided here such that they match the screenshots used.
Note: The dialog editor program is making use of the GTK library for doing menus and file selection and that. However that makes it difficult to cross-compile the program for the Windows operating system. Currently, the dialog editor program is therefore only avaiable for the Linux operating system, not for Windows users. We are however working on the resolution of this problem. If you have some hints or experience with the matter and would like to help, please don't hesitate to contact the mailing list. Thanks a lot.
FreedroidRPG is a role-playing game. It has some action elements, but it also strongly relys on dialogs to transmit the story and the plot.
FreedroidRPG dialogs are files stored in plain text, so you could (in theory) edit them with any plain text editor. (Like windows notepad or the like). If you would try editing dialogs that hard-core way, a dialog would look somewhat like this (using the barkeep Ewald for the purpose):
BEGIN OF AUTORS NOTES You can use this text field to make some notes on anything. These notes will get saved with the dialog. This is intended purely for the author's reference when using the dialog editor, while the engine of the game itself will ignore this entry. END OF AUTORS NOTES Beginning of new chat dialog for character="XXXXX" New Option Nr=0 OptionText=" Hi! I'm new here. " OptionSample="Tux_Hi_Im_New_0.wav" PositionX=44 PositionY=157 Subtitle="Hello! I'm Ewald. I run this bar." ReplySample="Sorry_No_Voice_Sample_Yet_0.wav" ChangeOption=0 ChangeToValue=0 ChangeOption=1 ChangeToValue=1 ChangeOption=2 ChangeToValue=1 AlwaysExecuteThisOptionPriorToDialogStart="no" ---------------------------------------------------------------------- New Option Nr=1 OptionText="How is your business doing?" OptionSample="Sorry_No_Voice_Sample_Yet_0.wav" PositionX=168 PositionY=138 Subtitle="Not so good. Times are dire and few dare to travel these days. But do you know what's funny? Somehow saying this makes me feel like a flat rpg character. Stange feeling, eh?" ReplySample="Sorry_No_Voice_Sample_Yet_0.wav" ChangeOption=1 ChangeToValue=0 AlwaysExecuteThisOptionPriorToDialogStart="no" ---------------------------------------------------------------------- New Option Nr=2 OptionText="So what have you got?" OptionSample="Sorry_No_Voice_Sample_Yet_0.wav" PositionX=170 PositionY=226 Subtitle="Take a look. You will find everything you desire." ReplySample="Sorry_No_Voice_Sample_Yet_0.wav" ChangeOption=2 ChangeToValue=0 DoSomethingExtra="InitTradeWithCharacter:Ewald" AlwaysExecuteThisOptionPriorToDialogStart="no" ---------------------------------------------------------------------- New Option Nr=99 OptionText=" END " OptionSample="NO_SAMPLE_HERE_AND_DONT_WAIT_EITHER" PositionX=253 PositionY=186 Subtitle="See you later." ReplySample="Tux_See_You_Later_0.wav" Subtitle="NO_SUBTITLE_AND_NO_WAITING_EITHER" ReplySample="Sorry_No_Voice_Sample_Yet_0.wav" ChangeOption=1 ChangeToValue=1 ChangeOption=99 ChangeToValue=0 ChangeOption=2 ChangeToValue=1 AlwaysExecuteThisOptionPriorToDialogStart="no" ---------------------------------------------------------------------- End of chat dialog for character="XXXXX"
These dialogs can be rather simple but sometimes they may have a rather complicated structure. Therefore it would be desireable to visually inspect and edit the dialogs.
A FreedroidRPG dialogs consists of several "nodes". A node consists of
You see: Dialog scripts excert a certain control and do have a certain flexibility that can be used to implement an increasingly wide range of content. The number of different properties makes it sensible to introduce an easy and conveninet way to inspect and modify these dialogs. This is why the DialogEditor program has been created.
The intention of the dialog editor is to make everything mentioned above visible. Therefore a first screenshot might give a good overview. The simple dialog from above would look like this in the dialog editor:
Since the dialog is so simple, there is not much variety in the image created by the dialog editor either. All dialog nodes apear as squares (instead of diamonds, which will come later). Also you see some arrows from one dialog node to the other. These arrows are either blue or red (and not orange or greens as some arrows later).
The red arrows indicate that one dialog option enables another dialog option. The blue arrows indicate, that one dialgo option disables another dialog option. Simple, eh?
So now we'd like to just take a quick glance at a dialog option, without looking at all the properties yet. This can be accomplished simply by moving the mouse cursor over the dialog node in question. The text of the Tux for this dialog option should appear in a small tooltip-style window without us needing to click anything. Like in the screenshot below:
No we'd like to see some properties of the dialog node in question. For this, we need to click the right mouse button directly on the dialog node. This should bring up a popup window with several tabs, that will allow us to excert total control over this dialog node. It should look somewhat like in the screenshot below:
Now since there are multiple tabs, we might like to take a short look at the other tabs too. They should look somewhat like this:
Ok. So much for an overview. The next section should explain in more detail with editing the pure text of a dialog node.
Ok. We have seen the three tabs when editing a dialog node (by clicking on it with the right mouse button). Now let's return to the first tab. We can care more about these other tabs later still.
For now we will just inspect the very first tab a little bit closer. Here we can edit the text that will appear in the dialog option selection menu of the player once the dialog is invoked from inside the game. This text is entered in the square highlighted with red color below:
Of course there might also be a voice sample associated with this dialog option (i.e. Tux saying something). The voice sample for Tux (i.e. the file name of the voice sample) can be entered in the textbox highlighted with red color below:
Now of course we don't always want the Tux to issue a voice sample (like e.g. when using the BACK menu option inside some submenu or something else that isn't really spoken. Because of this, we must be able to disable the voice sample for this dialog option altogether. This can be done by inserting a special text, that will be recognized by the game engine and that will make it suppress any error messages about missing samples and also not produce any voice output. The keyword in question to disable voice samples is Sorry_No_Voice_Sample_Yet_0.wav. Hint: It might be handy to have this text in a separate window (not the dialog editor) somewhere so you can easily copy and paste it from there, since typing it might lead to bad results in the likely case that a typo occurs somewhere.
So now you can edit the text that appears and the voice sample to be played, so now we come to the next thing, the reply of the chat partner.
The reply of the chat partner can be partitioned into subsections, so that the voice samples and the text being displayed are better in sync. You can use as many reply parts as you like up to a limit of 7 parts. The reply texts can be entered in the textboxes to the left. They are highlighted with red color in the screenshot below:
The voice samples that are to accompany the reply texts (in fact the file names of these voice samples) can be entered in the seven textboxes to the right. They are highlighted with red color in the screenshot below:
Ok. Of course you have noticed the Disable button in the top row. The purpose of this button is special. Pressing is will lead to the following change in the current dialog node as marked in red in the screenshot below:
You see the text for the name of the dialog option as well as for the voice sample have changed, but not only that, they've been changed to special keywords that will really disable the current dialog node in the following sense: From now on this dialog node is not a dialog node that can be selected by the player directy inside the dialog but now it's a special dialog node that can be used as auxhiliary node by other dialog nodes. More on that will follow later when discussing on-goto-conditions and that. But the new state of the dialog node can be seen immediately inside the main diagram: The changed node after applying the 'disable' button now takes on a diamond shape, like shown in the screenshot below:
Ok. That should be that. The next subsection will document how to create and remove connections between varios dialog nodes and how to insert new nodes.
For now let's stick to our 'Ewald' dialog example from before. If we want to investigate making new connection, we should first create some new dialog node that can be connected. We can use the menu: Dialog Option -> Insert New and we should get something like this:
Ok. We can drag the new dialog a bit over using the usual grag'n'drop with the left mouse button. However, in theory, the position of any dialog node on the dialog editor screen is completely irrelevant to the game engine. Only the connections and the text are of relevance to it. But of course, especially as the dialog gets bigger, it might be a good idea to keep things ordered a bit. Ok. So we can edit the text of this dialog node a bit like we did in the previous section. Let's assume you've done this. Then we can now establish new connections. Editing new connections inside the dialog editor works entirely with the middle mouse button of your mouse. If you don't have any middle mouse button, it can often be emulated by pressing left and right mouse button simulaneously. If you have a wheel, pressing (and not turning) the wheel should work as the third mouse button. So a connection has a source node and a target node. First we need to mark the origin node by clicking it once with the middle mouse button. It should turn red as soon as it is marked. Clicking it again with the middle mouse button should unmark it. Once it's marked, it should look something like this, where I mark the initial 'Hi! I'm new here' node of the Ewald dialog:
So now something about the effect of the middle mouse button has changed. Now that a dialog node is marked (the red dialog node) any click with the middle mouse button on some other dialog node will now cause
Now the red connection arrows are very simple. They enable dialog options (regardless of whether they have been active already or not). So in our example, there are red connection arrows from the 'Hi! I'm new here.' node to the other nodes, such that when the dialog first starts and the 'Hi' is issued, the new dialog options will become available after that.
The blue connections are just as simple. They disable dialog options (regardless of whether they have been disabled already or not). So in our example, there are no blue connection arrows anywhere, since it's never nescessary that available other dialog options are made unavailable, but we could easily insert something where that makes sense as seen below.
Ok. Let's edit the dialog connections. There should be a red connection from 'Hi!' to our new connection. (Don't forget to unmark the 'Hi!' node again with the middle mouse button.) Let's edit the text of the new node to be somewhat competing with the existing other node. The other node says something like 'How is your buisness going'. So our new node might say 'I guess your business is currently not going well'. The new node might (after editing it) look like this:
Now it would not make much sense to ask the same question again, so asing either of the two should disable the other question. We can do that by inserting blue arrows from each of them to the other so they will disable each other. It might finally look like this:
But once the dialog has ended and the Tux later comes back, it might be interesting to at least have the same dialog options available, such that the player might not need to worry about having messed up the current saved game. So it might be a good idea to make the 'END' option, that will exit the dialog also re-activate the other dialog options, such that they are available again when the Tux next enters this dialog option (and the 'Hi! I'm new here' option isn't available any more to do that). A simple red connection from the 'END' to the new node will do that. It might look like this:
Ok. Seems we're done here. Basic editing is not so hard after all. So we can now start to inspect special properties, add little extras (like leveling up) and conditionals (like giving different responsed based upon current cyberbucks of the Tux) and the like. That will be the topic of the next subsection.
Now we wish to deal with more complex dialogs. To illustrate to proceedings behind those, we need a bit of a more sophisticated dialog. Maybe the Sorenson dialog (the magics teacher in the town) will serve us well for this purpose, since this one has a few new elements like a shop interface, offers training for a fee and some sub-selection menu. So let's dive right into it and open up the Sorenson.dialog file. A screenshot might look like this:
The dialog above has a very simple structure. How can it be that this simple dialog structure offers everything we know from the Sorenson character inside the game? A look inside of the 'What can you teach me about mental abilities?' node reveals the secret: It's on the second page of the dialog node:
So the trick is as follows: A subdialog is invoked as soon as the player selects the 'What can you teach me about mental abilities?' node. The benefit of this is as follows: The current dialog will be stored and technically a completely new dialog will be started. So some selection menu can be offered without the dialog options from the main dialog interfering. The name of the subdialog file is subdlg_Sorenson. We can open it via the DialogEditor again. A screenshot would look like this:
So the real work happens inside the subdialog invoked from the Sorenson main dialog.
There are some things to consider when working with subdialogs:
There are many more 'Extra actions' apart from invoking a subdialog. In fact, clicking the selector reveals a list of them, as shown in the screenshot below:
The list of extra actions is already quite large. However more extra actions are easy to add, so the list is growing as we start to add new features to the game, requiring more things to do from eventual subdialogs. A short description of each of those extra actions (as they exist at the time of this writing) is given here:
In many situations the flow of a dialog should depend on achievements or status of the Tux. If the Tux has enough money to pay for some training the situation and response of the chat partner should be different from the response when the Tux is lacking the money and still wants to buy the training in question. On a similar note, once a certain mission is completed, the question for the status of that (resolved) issue should be something different from the initial response before the issue was resolved and the mission completed.
Therefore conditionals are of importance to create responsive dialogs. These conditionals can be combined and nested with each other to create sophisticated dialog behaviour and they can also be combined with dialog extras from the previous section.
Let's start with an example: We take a look at the Sorenson subdialog, i.e. the selection menu where Tux can choose from several training options. There should be one option called Improve spellcasting ability (cost 10 training points, 100 cash). Like here:
What we need now is the third tab of this dialog node. There we will find everything we need concerning on-goto-conditions:
The third tab now could look like this:
So the interpretation of this is easy. If the Tux can't afford the 100 Gold required for this training, the Dialog will continue at node 10. Note, that it is not nescessary for the player to click anything. The dialog will instantly jump to node 10 and continue there, most likely saying something like you don't have enough buck or the like.
If on the other hand the Tux has the 100 bucks (or even more), then the dialog will continue with node 11, most likely then checking whether the Tux also has the proper amount of lerning points available. Raising spellcasting skill after all costs money for the training and also requires learning points available. So that might be checked next. So there will be a second conditional in node 11. The conditional there will look something like this:
Ok. So at this point we know that the Tux has the proper amount of money on him, because this has been checked before and if Tux didn't have enough money, the dialog would never reach this point. Therefore we can now check for enough learning points available. If the Tux has the proper amount (5) lerning points available, then we can go to dialog node number 12, which will raise the skill. Otherwise we'll continue with dialog node 8, which will say something like you don't have enought lerning points (or experience) or somethink like that. Good. Now that should be almost all there is to say about conditionals ('on-goto-conditions') inside FreedroidRPG. The last thing to mention is only the following hint:
You will have noted there are a lot of diamond-shaped dialog nodes in this subdialog. As we mentioned in the section 4.2 concerning the 'disable' button in the first tab of any dialog node, the dialog options in question have been disabled like that. This makes sense and this is important. The Tux has clicked once to ask for the training. It should not be nescessary for the player to click anything else and it should also not be possible for the player to click the final result (like raising skills one level) without going through the checks for enough money and enough skill points first. Therefore it is sensible to disable those dialog options, such that they will not appear in the chat options of the player and such that the Tux won't say anything else when the on-goto-condition actually reaches the dialog node, but only the response from the chat partner is presented. That makes for a much better, more fluent and more sensible dialog.
Last but not least, I'd like to present two screenshots of dialogs, that might be worth inspecting: The simpler one is the Butch dialog. It makes use of another useful dialog element: auto-exectution on dialog startup: Look at the screenshot:
You see the filled black square inside one dialog option. That black square indicates, that this dialog option has the tick box Always on dialog start on the first tab of the dialog node activated. That means that before dialog start, this one dialog option will be executed already. What does it do? It will disable/enable some other dialog options, depending on whether some on-goto-condition is fulfilled. That way, the bender dialog can adapt, depending on whether the 'Cure for Bender' mission has been assigned already or not.
Another dialog might be interesting to inspect: The Spencer dialog contains some complex structure: When asked if the Tux has done enough missions to join the guard, Spencer will give a resumee on what has been accomplished already and what else is still open for completition. How is that done? You see it in the following screenshot:
The long chain of disabled dialog options contains the resumee of Spencer. This could be implemented with much more work if you use on-goto-conditions and don't recycle the existing on-goto-conditions, i.e. if you make it into a tree-like structure, you'll end up doing all the same work again and again. The important thing in this case is to use on-goto-conditions with both alternatives pointing to the next resumee part, such that the dialog will always continue there. This small trick saves a lot of work in this case.
Ok. Now you should have a fairly good insight into FreedroidRPG dialog organisation. Clever scripting can give quite inspiring dialogs. Of course new features not yet implemented will also be required. That's not a problem. Just mention it to the list and we'll add the nescessary new conditions/extras/options in no time.