[Tutorial] PC RPG Style Mouse-Driven Interactions (Baldur's Gate, Fallout, etc)

Keldryn

Part Three: Example NPC Conversation

This "conversation" consists of a single sentence in one dialogue panel, but we already know how to handle the flow of a conversation anyway.

For this, open up the moveToInteractionPoint event and Save As moveToNPC. We're only going to make one change here, but because NPCs will often be moving around, it is quite likely that we will eventually need additional logic in the Move Event.

Here's what the event looks like:

So you can see the only thing we've changed is the value in the CheckRemainingDistance step. With stationary objects, it is useful to have an Interaction Point offset so that you can line up character animations properly. Since we're not using this event to physically interact with another character, we're not going to use an Interaction Point child object on the NPC prefab; we'll just use the root. 2 to 2.5 seems like a comfortable distance to have the character stop to talk. We'll ensure that the NPC rotates to face the player by the end.

We'll create the testConversation event (or whatever you want to name it) by modifying the useContainer event that we created previously.

This is what it looks like:

I'll outline the differences here, rather than going through step-by-step again.

The Event Settings node.

We want to check Block Actor Move AI so that the NPC we have clicked on stops moving immediately. Don't block all of the Move AI yet, or else the whole world will stop to watch the player walk over to the NPC.

We only need to actors for this event (the player and the event object).

Start rotating the NPC to face the player. I've set it to fade over 2s, but eventually we would want to do a distance check and turn the NPC around faster if the player is closer.
The Transform to Variable step.

The only difference here is that we are getting the transform of the Event Object and not of the Interaction Point child object (which isn't needed on the prefab).

Block Move AI and Block Player Control

We don't want these turned on for the whole event, but we do want them turned on once the player has finished moving and during the actual conversation part of the event.

After all of the movement has finished, we'll rotate both actors to face each other, fading over 1s. This is just to make sure that we don't have the NPC facing the player's side because it took longer for him to stop moving than we anticipated.
The Play Mecanim Animation step

This is just a short "talking" animation that I have playing (once) on the NPC. Note that because we're using the Play function and calling a state in our Animator, we don't need to set up any parameters for it or connect the state to any other animation states. So we don't need to clutter up ORK's Animations list with these sort of animations.

Unblock the Move AI and Player Control
Clean up our variables. The image makes it look like Reset Variables leads to Block Player Control, but that's just because I forgot to move the node lower in the graph. The "Exit Interaction Event" path doesn't touch the Move AI and Player Control steps.

So this works pretty well, but I don't like the idea of having all of this logic in each conversation event. Sure, we can copy a base event and just change the conversation within, but that becomes a nightmare if we decide we need to make changes to the logic that gets us to the conversation.

I've done some quick tests with using Makinom schematics to see if I can pull most of that common logic out of the conversation and interaction events and have a more modular system. It's looking good so far. :-) I'll post that version when I've got it all figured out.

Keldryn

Part Four: Makinom Implementation of the Container interaction

This is going to be fairly brief for now; I can explain in more detail if anybody wants me to.

I replaced the MoveToInteractionPoint Move Event with a Makinom schematic (NavigateToInteractionPoint):

The logic is pretty much the same, but a major advantage here is that I can pass both the Player and the Event Object as actors to the schematic, whereas I could only pass the Player to the Move Event. This solution also avoids using any global variables.

Because we can pass in the Event Object as well, we can get the transform of the Interaction Point directly from the object and store it in a local variable.

Makinom already has a Check NavMesh Remaining Distance step, so I used that.

I set the continueInteractionEvent as a local variable on the schematic, and as the final step, I set that bool value as an Object variable on the Event Object. No global variable middle-men here.

The useContainer Game Event used to look like this:

Now it looks like this:

The primary difference is that I was able to simply run the Makinom schematic and skip the whole loop of checking to see if the Move Event has completed. The calling Game Event waits for the Makinom machine to finish running the schematic. Then I simply check the Object variable that I had the NavigateToInteractionPoint schematic set for me. The rest of the event is the same, but I scrapped the final Reset Variables step, as I'm only using Object variables and I'm initializing those every time the event runs.

It's a nice little bit of streamlining, but can it help clean up the version for starting conversations with NPCs?

I'll let you know as soon as I find out. ;-)

Keldryn

Part Five: Makinom Implementation of an NPC Conversation

I replaced the moveToNPC event with a new Makinom schematic:

This one is a bit more complex than the one for moving to an object, as we want the NPC and the player to be facing each other when the conversation starts. But it uses pretty much the same logic.

With this schematic, I was able to replace this conversation event:

Here's the new one:

So yes, it does really help streamline the conversation events. We want our events to be as re-usable as possible so that we're not stuck copying-and-pasting all of the basic interaction nodes.

In this new one, I'm using a StartConversation step for Pixel Crushers' Dialogue System in place of the Show Dialogue step in the original. The step simply requires a string value for the name of the conversation in the database. So we can streamline this further by taking the StartConversation step as a basis and writing a new one that can take a string game variable instead of requiring a specific value in the event. Then we can move the name of the conversation into an object variable on the NPC, and we can use a generic talkToNPC event to load up the conversation!

I haven't done that yet, but it's on my to-do list. ;-)

Phesant33

Hi @Keldryn, Up to implementing this stuff now and had some questions

Can't seem to get the drop box link to work for the custom step
Does makinom do this out of the box? (move to click, move to interaction, i.e. loot and click to attack an enemy?) Thanks.

Keldryn

@Phesant33,

Yeah, that custom step is gone. I listed the steps to use instead of it further up this page, in one of my Jan 28 posts. I should probably dig up the source code for that event node and post it, as it doesn't have to be in a .DLL (which I thought at the time).

You don't need to do any of this for interacting with stationary objects. Just use the built in Move to Interaction for that (it was added after I wrote this).

For talking to NPCs, you may still need this, as Move to Interaction will move you to where the NPC was standing when you clicked on him. So my example above gets around this by updating the NavMesh destination with the NPC's current position each iteration of the loop.

Makinom also does Move to Interaction out of the box, but it doesn't do the other things you mentioned without writing a schematic for it. As you can see in one of my examples above, using a Makinom schematic for the movement component streamlines things a bit and allows for easy re-use of that functionality.

Phesant33

Thanks heaps @Keldryn

« Previous Page