Today was an “under the hood” kind of day.

Yesterday, I implemented the basics of the display part of the dialogue system. After all, it doesn’t do us much good to have a fancy editor if we can’t use it to build things that actually work.

Today, it was time to make the whole thing server authoritative. So what needs to happen here is that when the user starts a dialogue with an NPC, the server needs to do a bunch of checks to make sure it’s okay for that to happen. Some of these checks include: Is the user already in a dialogue? Is the user standing close enough to the NPC in question to start the dialogue? Does the ID of the dialogue the user is trying to start match with the ID of the dialogue on the unit they’re trying to start it with? Does the unit exist in the current zone? Does the user pass all of the requisite checks to begin that dialogue?

It may seem like overkill, but it’s entirely necessary. There’s a common tactic for hacking that involves trying to start a dialogue with an NPC, then altering which dialogue is being started by changing the ID of the dialogue that goes to the server. Sometimes that allows you to skip ahead in the story’s progression, whisking you off to another area for a cutscene, or granting you access to an item you’re not supposed to have access to yet. To prevent cheats like that, the server has to do a ton of checking. Only when all those checks pass are you allowed to begin the dialogue.

But if your client had to wait for all those checks to happen, there’d be a real delay between clicking the NPC and actually starting the dialogue. That’s why I’ve coded the client to be what we call “optimistic.” This means the client operates assuming the check will pass. If it gets alerted that the check failed, it will simply force cancel the dialogue and the user will be banished to the shadow realm.

But that’s not all it does.

Traversal

Every time you click to advance the dialogue, we have to reach out the server too. You advance a line of text, the server advances a line of text. This was the entire reason why I needed to rip out the dialogue library I was using and write my own. This part was impossible. But now it’s possible. Actually, it’s not just possible. I’ve made it happen.

Every time you advance a line of text, a signal is sent to the server so it stays in sync with you. Every time you choose a branching dialogue, a signal is sent to the server so that it also chooses that branch of dialogue. You may, again, think this seems like overkill. But again, there’s a common hack where users can edit their local save data to make it seem like they have more permissions than they do.

An Example

Consider you have a character called Ben and a character called Starr.

(I’ve come up with those names totally at random)

Ben just says “You need to go talk to my good buddy Starr” until you’ve gone and talked to his good buddy Starr. But Starr is far, far away, in the distant land of Chicago Illinois, and you don’t want to go that far. No problem, you just search through your save game file until you find a line that says “hasTalkedToStarr: false” and you change it to “hasTalkedToStarr: true”.

Now when you talk to Ben, he says “Great job, you truly are a final fantasy, here’s the ultimate weapon.”

And then he hands you the ultimate weapon.

The server needs to be able to say “No, wait. You didn’t actually go talk to Starr. You don’t get to just have the ultimate weapon.” The only way to really do this is to have the server also open the dialogue, and also make the requisite checks. See, you only edited “hasTalkedToStarr” on your side. The server doesn’t fall for your tricks. It doesn’t even have a way for you to edit it. It sets that flag on its side only if you actually go talk to Starr. When the server opens its copy of the dialogue, and does its round of checks, it says “No, no, no, I don’t think so.”

I mentioned before that the client is optimistic. It operates assuming these checks will pass and then goes on with its life. So if the user is fast enough and hammers through the dialogue, can’t it send the request to receive the item before the server side finishes its checks? Wonderfully enough, no! Because item granting is also verified on the server, the user doesn’t actually receive the item until the server says it’s okay. And since our server is in lock-step with our client, the server not only verified that you didn’t have access to that dialogue branch, but it also verified that you don’t qualify to receive that item!

And it serves you right for trying to cheat my game.

Off to the shadow realm with you!