Question about 'expanding dialogue tree'

+
Hi again,
I'm working on my map on which, the specific character should show additional dialogue options after completing other sidequests or dialogues with other characters.
What I mean, is that for example, one dude has assigned specific dialogue options, and after talking with someone else, his dialogue should contain additional dialogue options.
I'm not sure if I should perform it by doing one big dialogue tree with a lot of 'flow condition' nodes?
Or with similar duplicates of the dialogue tree duplications continuing along the quest line?

If You have played Witcher 1, it's like continuing expanding of dialogue options while talking to the priest of Eternal Fire on Wizima ourtskirt.
Where You received additional dialogue options after talking to additional, side-quest characters.

Cheers,
Goospo
 

Attachments

  • dialogue.png
    dialogue.png
    98.3 KB · Views: 295
Hey @Goospo ,

I am also not sure, and can't look it up, becasue I have no Red Kit installed right now. But I think if you design it logically and make a clear tree for your dialog options a fact based flow condition based approach would be more useful.
But I am not completely sure. The best advice as allways is to look at a certain quest/dialogue tree the developers made. Remeber a certain quest and search for the file and look it up.
Sorry for this poor advice I hope it was better than nothing.
Greetings Nemo
 
In my experience, it's easiest to work the questline(s) backwards. For example, if my quest will have 4 possible outcomes, I'll write in the last stage of each branch, and begin working it backwards to the next junction. Obviously, you'll need to know how the story is supposed to go, but it can be much easier to add triggers and flags from the conclusion back toward the beginning, as well as recognize things that are missing from the arc or definitely need to happen at an earlier point

That might not make sense when coming up with an idea for the quest, but you'll see it's far more efficient to enter the steps and stages into an engine that way.
 
The thing is that my quest would have only 2 outcomes which would be quite easy to prepare.
The beginning is much harder.

As I said, If You remember priest of Eternal Fire from Wither 1, Wizima .
He had some basic 5 dialogue options assigned. Lets call it 'dialogue section 1'.
If you took the contract for drowners near the tavern, an additional dialogue option appears so I need to make 'dialogue section 2', containing 'dialogue section 1' with one additional option.
If you have completed a quest for lighting the candles on 5 shrines, you should receive 'dialogue section 2' but with one option changed to resemble after-quest talk.
So we need 'dialogue section 3'.
Except, if you didn't take the contract for drowners. Then you shouldn't be able to talk about it when talking to the priest.
So it would be 'dialogue section 4', and so on, and so on...

I was curious if this is the only way or is there any better way to do it.
 
Hey,
I don't have redkit installed, but I think that at least in witcher 3, dialogue options could be added, so quick guess:
- try to actually output flow to two dialogue blocks at one time

Does editor allow something like this ?
Hack.png


Best of luck :)
 
The thing is that my quest would have only 2 outcomes which would be quite easy to prepare.
The beginning is much harder.

As I said, If You remember priest of Eternal Fire from Wither 1, Wizima .
He had some basic 5 dialogue options assigned. Lets call it 'dialogue section 1'.
If you took the contract for drowners near the tavern, an additional dialogue option appears so I need to make 'dialogue section 2', containing 'dialogue section 1' with one additional option.
If you have completed a quest for lighting the candles on 5 shrines, you should receive 'dialogue section 2' but with one option changed to resemble after-quest talk.
So we need 'dialogue section 3'.
Except, if you didn't take the contract for drowners. Then you shouldn't be able to talk about it when talking to the priest.
So it would be 'dialogue section 4', and so on, and so on...

I was curious if this is the only way or is there any better way to do it.

Sure. But entering the actual data into the engine can be surprisingly confusing. Generating the idea for a "simple quest" is, in fact, simple. Getting a computer to understand what's supposed to happen at any given step is far more challenging.
The player will talk to a farmer and get a magical coin to throw in a well as part of a local ritual. Upon reaching the well, a ghost attacks the player. Once the player has defeated the ghost, it speaks, begging the player to free it from its curse. The player needs to decide whether to a.) permanently destroy the ghost, or b.) assist the ghost and break the curse.

a.) The player continues the fight with the ghost and destroys it forever. The player then returns to the farmer with the news that the the curse broken and all is well. The farmer responds with gratitude, and awards the player 300 gold. The quest ends.

b.) The player dives into the well and gathers up 10 "cursed" coins. He confronts the ghost, who is now freed, and the ghost expresses gratitude. The player returns to the farmer who is terrified that the ghost is loose, and refuses to pay the player. The quest ends.

To build this into the game, I'll do it backwards, beginning at the ultimate conclusion of each quest-line.
b2_true_farmer) 'You don't realize what you've done [Player]! Get out! Get out of here!'
ENDQUEST "The Cursed Well"

b2_true_ghost) 'You've freed me. Ahhhh...' REMOVE "Ghost"
_

b2_false_ghost) 'No, [Player]...there are more...'
INPUT:
1. 'Very well.'
GOTO "b1"

2. 'I'm done with this -- you die!'
GOTO "a"
_

b1) CHECK: Player has Cursed Coins(10), true/false /
IF "true" : GOTO "b2_true_ghost" /

IF "false" : GOTO "b2_false_ghost"
_

b) 'Finally...an end to my torment! Gather 10 cursed coins from the well...then return...'
GOTO "b1"
_

a3) "Thank you, [Player]! You've saved us!"
GIVE Gold(300)
ENDQUEST "The Cursed Well"
_

a2) 'You return, [Player]. What happened?'
INPUT:
1. 'The ghost is gone. You're safe now.'
GOTO "a3"
_

a1) DISPLAY_TEXT 'I should let the farmer know the ghost is banished.'
GOTO "a2"
_

a) 'May you suffer eternally, [Player]...'
"Ghost" = SET_HOSTILE /
WHEN "Ghost" HEALTH=0%
GOTO "a1"
_

5) 'Lift my curse...I beg you...'
INPUT:
1. 'No, this ends here!'
GOTO "a"

2. 'Yes, I will help if I can.'
GOTO "b"
_

4) CHECK: "Ghost" HEALTH<50% = SET_PASSIVE
GOTO "5"

_

3) CHECK: Player has Farmer's Coin(1), true/false /
IF "true" : SPAWN "Ghost" = SET_HOSTILE
GOTO "4" /

IF "false" : DISPLAY_TEXT 'I must have dropped the farmer's coin. Damn.'

_

2) 'Bless you! Be cautious, that well is evil.'
GOTO "3"

2_no) 'Then the darkness take you!'
ENDQUEST "The Cursed Well"
_

1) 'Save us, [Player]! Take this coin and throw it into the old well on the hill. It must be done, but I can't make myself go. Please!'
INPUT:
1. 'I will do it.'
GOTO "2"

2. 'I cannot help.'
GOTO "2_no"

STARTQUEST "The Cursed Well"

Do note that on the screen, I'll do this right -> left, or bottom -> up, so reviewing what I've got will look much more sensible. Not convoluted, like it does here. (Also, I'm completely making up the commands -- I've no idea how TW3's system actually works. This is just an example of the technique.)

It's simply that doing it backwards makes it much harder to miss steps or create glitches. It forces me to check myself at every step. For example: "How does the game know to spawn the ghost at the well? Oh -- shoot! I need to create a check to see if the player has the farmer's coin! ... How, exactly, does the game know that the ghost is freed? Oh! Shoot -- I need to create a check to see if the player has 10 cursed coins!"
 
Last edited:
I'm not sure if anybody beside me is still digging in RedKit but I've finally found the functionality that I wanted.
Somebody might find it usefull so I decided to write it here.

Instead of creating 20 condition nodes that will check which dialogue choice should be chosen this time, You can assign Fact checking condition to each choice in Dialogue Choice section, as questCondition parameter (they will change color so you can immediately see which dialogue options are fact based and which aren't).
After doing that, You just need to add Fact node (like 'FactDB Change' or 'Script [QAddFact]') after specific actions in quest structure, that will set additional dialogue option visible.
With that, instead of creating multiple dialogue choice sections in your dialogue file, you can create one big choice hub and assign fact condition to any choice option so they appear when they should, and dissapear when they should not be visible anymore.

1569360120590.png
 
Top Bottom