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 .... :)

Development Continues ...

As I was working on the button puzzle mentioned in the last post, I discovered I needed similar functions I have used in a number of previous puzzles. So, I decided to move those functions into a new library and associate the new library with those scripts ... and all went smoothly! I just had to mention that after all the problems I had with the includes of late.

Other development has included continued work on the bestiary (adding info on the creatures that the first module includes); creating encounters (and reworking the way the encounter system works to allow for better response); continued conversation write up, and puzzle scripts.

That's all I can say this week, as it's all finishing doing what I have already talked about. But that's good right?

So, maybe this week can be one of open comments .... i.e. Is there anything you want  to discuss about the module that I can go into more detail in my next post? Anything you are not clear about? Just want to know more about a specific mechanic? Anything sound like it might be frustrating? Feel free to post your comments ... all welcome!