Conversations (Advanced Application)

I realised a better way of writing conversations in the NWN2 editor this week ... or rather, I reminded myself of a way of writing conversations that I meant to blog about before, but forgot to do so. It involves using a "non-accessible" entry on the conversation in question, and is why I thought this might be considered an "advanced" application when writing conversations. After I have described what it involves, this may be something you have always done, or something quite simple, but it does go against the norm for me and is why I am blogging it. It may also be helpful to others.

Natural Unreachable Nodes

The whole concept basically relies upon what I have defined as "Natural Unreachable Nodes" (NUN for short), which basically means having lines of conversation added to a conversation file on nodes that cannot be accessed by any "normal" means during a conversation. I will try to explain that a bit more using a diagram:

Natural Unreachable Nodes

In the above conversation, the large boxed section at the bottom is what I call the NUN. Notice that I have made sure this is the case by adding the gc_false script as a condition. (See point 5 above.) i.e. It can NEVER appear in a conversation by any "natural" flow of events.

Now this NUN section can be accessed by the main conversation at any time with any normal conditions required. Note, in the conversation nodes just above the boxed NUN section, you can see three greyed lines (the first being "Be more demanding!"), each of which jumps the player into the NUN section of the conversation.

What's The Point?

It may be that you can see the advantages of this already, but in case you don't here is the advantage of this type of structure:-

If I wanted to make use of some (or all of the nodes) that are further down the conversation with some of the nodes back up the chain (and without offering the same group again), not only can it get very complicated to keep track of lines in the first place, but can also get complicated with any variables we are trying to keep track of along the way (even if we use the "show only once per game" option for a node).

AN EXAMPLE: In the above, the player first gets the option to choose "Be more demanding!", "Be more persuasive!" or "Be more Diplomatic!". (See points 1 and 4 above.) Once they have selected any one of these, then the link can be to the same node regardless of the player's choice. i.e. If the player chooses "Be more persuasive!" instead of "Be more demanding!", the connected link can be to the same node. i.e. Whatever the player chooses from the first option always goes to point 2 in the diagram; and whatever they choose after that, always goes to point 3 in the diagram above. However, the builder can track variables more easily by noting the "path" the player takes through the choices they make along the way.

If that still does not make sense, below is an exercise you can try to do that (I hope) will demonstrate the point I am trying to explain. Try to design a conversation where the player starts with three choices such as:-

"Be more demanding!"
"Be more persuasive!"
"Be more diplomatic!"

Now, from every one of those options have the possibility of each having three more options that offers the player three new alternate paths. i.e. Every node above should have:-

"More demanding!"
"More persuasive!"
"More diplomatic!"

And from every one of these nodes, yet three more nodes for each node above, such as:-

"Even more demanding!"
"Even more persuasive!"
"Even more diplomatic!"

You should see that the number of lines required quickly escalates, and how controlling access to these lines outside of the natural flow of the conversation is easier to control.

Limitation (Minor)

This system does have a limitation, in that in relies on the response from the NPC or object being the same for each option the player may choose. However, this is NOT necessarily a limitation, for in these kind of situations, we are usually just looking for the "choice of path" the player is making, which can check variables along the way and eventually determines the final outcome based upon those variables on the player's chosen path.

That's all again for this week. I did consider uploading a video to demonstrate something I have worked on this week, but felt it was too much of a surprise spoiler, so decided against it. The good news, it's another step closer to finishing .... :)