But first, some housekeeping…

Alright, I’m removing the “Day X” part of the title post. The point of the Day X posts was to keep myself working every day. It made sense when progress was happening fast and huge decisions were being made daily. I’m progressing into features that are taking longer than a day, I’m finding that some days I don’t have enough time to make meaningful progress on something, and I don’t want to waste everyone’s time writing posts that just say “No meaningful updates today teehee lol xd”… So anyway.

Onto the main event…

Authoritative Nodes

Last time, I talked a whole lot about why the server needed to be able to traverse our dialogue nodes alongside the client. The server isn’t actually going to be displaying the dialogue to anyone, but it has to know which nodes the player is going down so that they don’t try to do anything untoward with regard to getting items or progression from dialogues.

Well, that’s fully implemented now! Whenever the player tries to start a dialogue, the server checks to make sure it’s okay, and then the dialogue begins. The client is pessimistic during this part, meaning it waits to start the dialogue until the server says it’s okay.

As the user steps through nodes, it sends a signal out to the server to let it know that it should also step through nodes. As branches are chosen, a signal is sent to the server to let it know that it should also choose a branch.

During the dialogues themselves, the client is optimistic. It steps through nodes, and lets the server know what it’s doing as it does, but doesn’t wait for the server to send a signal back telling it that it’s okay. To keep dialogues snappy, it just assumes that everything will be okay. If at any point, the server realizes the player is doing something suspicious, it sends a signal back to the client that immediately terminates the dialogue and displays an error message.

Once the player gets through the dialogue successfully, it sends a signal out to the server letting it know that it wants to end the dialogue. It’s pessimistic here, too. It stops and waits for the server to give it the thumbs up. Only after it gets the thumbs up does it actually end the dialogue – which then also fires off any events from the dialogue. These would include things like granting items or experience, or setting progression flags.

The idea there is to make sure the player can’t just rocket themselves through a dialogue and grant themselves items they don’t qualify for while the server is still trying to catch up with all of the requests.

Authoritative Checks

There’s a lot of checks that need to be done on the server side too. Some nodes have checks on them which say “You must have this item to see this node”, or “You must have this progression flag set to true to see this node”. If the check isn’t passed, it will move onto that check’s “Fail Node”, which is usually an NPC saying something like “You don’t have enough of those,” or “You haven’t saved my cat from the tree yet.”

For cases where there are dialogue options to be chosen, some of those have checks as well. For example, you can only say “I’ll give you a potion” if you actually have a potion. In those cases, the options will just be disabled.

The server does those checks independently from the client. The intention there is to make it more difficult to cheat the system. Even if the client sends a signal saying “Hey, the player chose option 2,” we can’t just trust the client. We have to check to make sure option 2 is a valid choice on the server side as well.

Authoritative Events

The last piece of the puzzle is making the dialogues actually do stuff for the player. If an NPC thinks you should go talk to his cousin Josh, then we have to set the HasTalkedToJosh flag after you do it. If an NPC wants to give you a potion, or take a potion away from you, then we have to add the potion to your inventory, or take it away. Those are called events. As you traverse down the dialogue tree, the server collects up all the events you’ve triggered along the way. When the dialogue ends, the server does a final round of checks, then does some checks on the events, and then runs the events. Then it sends a signal back to the client to tell it to run the events too.

Putting It All Together

Now we’ve got a server that can do checks and traverse nodes, and it can execute both checks and events on its own without listening to a word the client says! Stupid client. So if put that all together, it looks a bit like what you see in the video below… We can talk to a character, who has something to say. Then we can go talk to another character, whose dialogue sets some progression flag (both on the server and the client). Then we can go back to the first character, and they’ll have something completely new to say!

Putting It All Even More Togetherer

But if you’ll recall, there was a reason I did all this.

See, a while back, we wrote ourselves an item system. We gave ourselves usable items, taught the client and the server how to use them…….. but then had to hack ourselves the item because we had no method for actually getting items.

Well, since dialogues can now award items, and since dialogues and awarded items are both server authoritative…

We get to hook these systems into one another fully now!

So here’s another video, and…

I have to admit, it’s moments like these that make gem dev shine for me. Here we have a character talking to someone, who does nothing… Then talking to someone else, who flips a progression flag… then talking to the first person again, who now gives us an item. And then, we can use that item on ourselves, and not only does it actually work, it’s also reflected in the UI.

And as a bonus, that new state is persisted in the database permanently – so every time I record a video from now on, I’ll actually be at full health again!

Well, that’s maybe not true, actually

Because working on this dialogue system gave me a lot of ideas for how to handle the battle system. I have a feeling I’m going to be taking a lot of damage soon.