FreedroidRPG Dialogs and the DialogEditor program

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.

./Ewald.dialog

./Ewald_tutorial_finshed.dialog

./Sorenson.dialog

./subdlg_Sorenson.dialog

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.

Introduction and Overview

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

1. (optionally) a question/statement of the Tux (optionally) with a voice sample too

2. (optionally) zero, one or more reply sentences from the dialog partner, optionally again each of these can be accompanied by a voice sample

3. (optionally) a list of other dialog nodes, that should be made available inside the dialog once the present node is selected

4. (optionally) a list of other dialog nodes, that should be made unavailabe inside the dialog once the present node is selected

5. (optionally) some "ExtraCommands" that should be executed once this dialog node is selected. This can be simple stuff like adding or removing an item from the tux inventory, giving gold or experience, breaking off the dialog and the chat partner turning hostile, raising a certain skill, ...

6. (optionally) a conditional "OnGotoCondition", that will be checked and if true, a (pointer to a) second dialog node, that should be executed immediately after this one (without player interacting) and also a (pointer to a) third dialog node, that should be executed immediately if the condition was not fulfilled (again without waiting for player interaction). Examples of OnGotoConditions are if the Tux gold exceeds a certain level, if a certain item is present in inventory, if a certain "Cookie" has been planted, if the Tux has some learning points left, ...

7. some extra properties, like if this dialog node should be executed automatically on dialog start or if it should stay available once it has been selected

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:

Figure 17: A very simple dialog, viewed with the DialogEditor

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:

Figure 18: A small tooltip shows the name of the dialog option inside the game

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:

Figure 19: The first page of three when inspecting a dialog node closely (right mouse button)

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:

Figure 20: The second page of three when inspecting a dialog node closely (right mouse button)

and

Figure 21: The third page of three when inspecting a dialog node closely (right mouse button)

Ok. So much for an overview. The next section should explain in more detail with editing the pure text of a dialog node.

Editing the dialog text of a 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:

Figure 22: The text that will appear in the selection menu of the user is highlighted with red color now

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:

Figure 23: The file name of the voice sample that will accompany the text when selected by the player is highlighted with red color now

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:

Figure 24: The reply texts of the chat partners reply can be entered in the seven text boxes highlighted with red color

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:

Figure 25: The file names of the voice samples, that are to accompany the reply texts of the chat partners reply can be entered in the seven text boxes to the right which are highlighted with red color here

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:

Figure 26: The effect of the disable button

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:

Figure 27: The disabled dialog node has changed to a diamond shape

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.

Editing the connections between 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:

Figure 28: Ewald dialog with newly inserted dialog option

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:

Figure 29: Ewald dialog with marked 'Hi! I'm new here.' node

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

1. a new blue connection arrow from the marked node to the clicked node, if there hasn't been any connection arrow before
2. a red connection arrow from the marked node to the clicked node, if there has been a blue connection arrow before
3. no more connection arrow from the marked node to the clicked node, if there has been a red connection arrow before

Red connections

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.

Blue connections

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:

Figure 30: The new dialog node, that somewhat competes with the other node, that asks 'How is the business going', could look somewhat 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:

Figure 31: Ewald dialog with new dialog option that competes with the other dialog option, as indicated by the blue arrows

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:

Figure 32: Ok. Now the dialog seems finished. The 'END' option will re-enable the main dialog options we want to be availabe when next entering this dialog

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.

Using extra actions inside of dialogs

Using subdialogs

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:

Figure 33: Ok. Now we're looking at the Sorenson dialog, and amazingly, it looks so simple! What's going on?

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:

Figure 34: Here is the trick: A subdialog is invoked as soon as the player selects the 'What can you teach me about mental abilities?' 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:

Figure 35: This is the subdialog invoked from the main dialog. In fact it's more complex than the whole main dialog of Sorenson.

So the real work happens inside the subdialog invoked from the Sorenson main dialog.

There are some things to consider when working with subdialogs:

1. Never start a subdialog from inside a subdialog! The engine currently can't deal with that and would get pretty confused if that happens. Of course you can start one subdialog from the main dialog and then start another subdialog from the main dialog. But starting a subdialog from inside a started subdialog is a bad idea.
2. It's often good to disable the '0' dialog node of the subdialog. In fact some text option has been clicked by the player in the main dialog, so there is no need for the subdialog to start up with a 'Hi' or similar message. In fact it might be better to use the disabled '0' dialog option to open up all the subdialog options, like in the previous screenshot: All the available training options should be made clickable.
3. There should be a 'BACK' dialog option inside the subdialog, typically with the number code 99, which always indicates the exit option. After clicking that one, the subdialog will return to the main dialog. The main dialog should then return to the state before entering the subdialog.

Other Extra Actions

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:

Figure 36: Here we see the range of 'Extra actions' we can choose from

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:

UNUSED EXTRA

This is for those extra actions that aren't used. As you see, you can use a maximum of 8 dialog extra actions per dialog node, so there should always be some that are not really needed. Those should be set to UNUSED EXTRA.
Parameters: none

BreakOffAndBecomeHostile

This extra action will immediately quit out of the current dialog. Apart from that the dialog partner will then turn hostile. This is useful if some negotiation has failed, a spy is being uncovered or someone feels insulted. Currently we're using it e.g. to make Bender turn hostile.
Parameters: none

IncreaseMeleeWeaponSkill

This extra action will increase the Tux melee weapon skill by one level. Of course this option will be useful for melee trainer characters. Currently, e.g. Pendragon makes use of this option.
Parameters: none

IncreaseRangedWeaponSkill

Similar to the increase melee version.

IncreaseSpellcastingSkill

Similar to the increase melee version. Sorenson uses this.

IncreaseExtractPlasmaTransistorSkill

Adds the 'extract plasma transistors' skill. Darwin offers this.
Parameters: none

IncreaseExtractConverterSkill

Similar to 'extract plasma transistors'.

IncreaseExtractInverterSkill

Similar to 'extract plasma transistors'.

IncreaseExtractCondensatorSkill

Similar to 'extract plasma transistors'.

GiveItem:

This is a very useful extra action, especially for rewards, special (non-shop) deals and quests. The Tux will be given an item, i.e. it will appear in the Tux inventory. This extra action is used e.g. by Bender to give the Tux some strength pills in return for the antidote.
Parameters: the item code for the item to be given to Tux
Note: However, you have to enter the number code of the item you wish to give. Like e.g. for giving the strength pills use code 76. Those codes can be seen via the ItemEditor program or by inspecting the file map/freedroid.item_archetypes manually.

ExecuteActionWithLabel:

This dialog extra can be used to trigger predefined 'actions' inside FreedroidRPG. This is useful e.g. for map manipulations or for teleporting the Tux somewhere. E.g. opening the unlocked doors to the maintainance tunnels by Dixon is done via triggering a predefined action.
Parameters: the label of the action you want to execute

PlantCookie:

This dialog extra is very useful for storing information and accessing information from other dialogs previously done. A cookie is basically a keyword that will be stored with the current game. It can then be used inside conditionals, such that a (remote) character's dialog can then act differently depending on whether the Tux has had a certain conversation with someone somewhere else.
Parameter: The name of the cookie in question.

InitTradeWithCharacter:

Whenever a character has a trade menu to offer, it can be triggered with this extra action. The trade menu must be defined in advance. Currently this happens via a list inside the code. Any character that has a trade can enter the shop interface and do the trade as soon as this dialog extra action is invoked. Parameters: ???? should be none, right?

AssignMission:

Characters will frequently assign the Tux some mission. This dialog extra can be used to assign the mission.
Parameters: The parameter is the number code of the mission in question.
Note: What is the mission code? It's a number. The list of missions is contained in the file map/QuestList. The numberin in this file starts with 0, so the first mission listed is code 0, the second mission is code 1, the third mission is code 2 and so on. Be careful however with deleting missions from the list, as that would shift the mission code numbers a bit, and then all the dialog extras suddenly point to the wrong missions. (I know that's a bit of an unconvenient handling. Maybe later we can rewrite the code to work with labels instead of with mission codes...)

MarkMissionComplete:

This dialog extra can be used to close a mission and mark is as completed.
Parameters: The number code of the mission in question. The same Note as above applies.

AddExperienceBonus:

This will award some experience points to the Tux.
Parameters: the amount of experience you want to give

AddBigScreenMessageBUT_WITH_TERMINATION_CHARACTER_PLEASE:

When something important has happend, there are sometimes big news items displayed directly on screen. You can make such a news item appear via this dialog extra. The news items will then become visible on screen as soon as the dialog is finished.
Parameters: the text of the screen message

AddBaseMagic:

A character might offer some training, that will permanently raise the stats of the Tux. To raise the magic stats, this dialog extra can be used.
Parameters: the amount of magic points to give

AddBaseDexterity:

Similar to 'AddBaseMagic' but with dexterity stats instead

SubtractPointsToDistribute:

When the Tux does some training with a teacher and raises some skill, that should also reduce the number of skill points the Tux has still left. This dialog extra can be used to take away any number of remaining skill points the Tux might still have. It might be sensible to check first, if the Tux has that many skill points left at all.
Parameters: the number how many learning points or skill points (or whatever they are called) should be taken away from the Tux

SubtractGold:

If the Tux has bought something or gets robbed or whatever, the amount of gold or cyberbucks (or whatever they are called) should be reduced. This dialog extra can be used to deduct any amount of cyberbucks from the Tux current credit. However it might be sensible to first check if the Tux has that many bucks left at all.
Parameters: the amount of bucks to take away

AddGold:

This is just the reverse of the 'SubtractGold' dialog extra.
Parameters: the number of bucks that should be added to the Tux current funds

DeleteAllInventoryItemsWithCode:

If e.g. the Tux was assigned a mission to bring back some item, the item should be removed from the Tux inventory when the item is delivered to the character in question. This dialog extra can be used to strip the Tux of any particular item type.
Parameters: The inventory number code of the item type to take away from the Tux inventory. Again this refers to the number codes, see the previous notes concerning these item codes.

DeleteAllInventoryItemsOfType:

This is much like the DeleteAllInventoryItemsWithCode extra, but here you specify an item name. Alas, at present, only certain items can be specified here, like Dixons toolbox or also the red dilithium crystals for the cook mission. However, it should be easy to add new stuff.

ExecuteSubdialog:

This dialog extra is already known to us. Typically it's used to enter a subdialog. We need to specify the subdialog that should be invoked. The subdialog will not affect the currently available/unavailable dialog options in the main dialog, so once the subdialog returns, the main dialog will continue quite normally.
Parameters: the name of the subdialog file must be given. Typically that should be something like subdlg_XXXXX, where XXXXX is the name of the main dialog.

EverybodyBecomesHostile

If the Tux has offended the whole Town (or in fact the whole world) by saying something really stupid, every character in the game might turn hostile. This can be achieved using this dialog extra.
Parameters: none that I would know of...

MakeTuxTownGuardMember

The Tux might become a member of the Town guard. This dialog extra will declare the Tux a town guard.
Parameters: none

IncreaseHackingSkill

Parameters: The hacking skill can also be raised via training. This dialog extra will raise the corresponding skill by one level.
Parameters: none

ForceBotRespawnOnLevel:

E.g. the arena master might want to force a respawn of the bots in the arena, so the next customer can go down and have some fun. This dialog extra will force such a bot respawn on any particular level.
Parameters: the level number that should be the target of the bot respawn

CompletelyHealTux

Some healer characters like the Doc in town can fix the Tux. He does it for free. Other people might charge for such a service. Anyway, this dialog extra will fix the Tux completely.
Parameters: none

Using conditionals inside of dialogs

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:

Figure 37: The option to improve the spellcasting ability by one level is easily found

What we need now is the third tab of this dialog node. There we will find everything we need concerning on-goto-conditions:

1. The condition to evaluate
2. Where to go in case the condition is true
3. Where to go in case the condition is false

The third tab now could look like this:

Figure 38: The first on-goto-condition inside the Sorenson subdialog

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:

Figure 39: The second on-goto-condition inside the Sorenson subdialog, that will only be reached if the check for enough money has already been passed successfully

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.

An example of a complex dialog: Butch and Spencer

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:

Figure 40: The bender dialog uses auto-execution on dialog startup to disable/enable some dialog options from the start, depending on whether his mission has been assigned or not

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:

Figure 41: The bender dialog uses auto-execution on dialog startup to disable/enable some dialog options from the start, depending on whether his mission has been assigned or not

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.