State machines quickly become burdensome if you hardcode each case in a giant case statement. So you need state-handlers, which load the user's current state for a given quest or conversation id, and handle the transition to the next state.

Each game tick (or time round the game loop, or event) you pass any queued or incoming state change requests to the relevant state-handler. So when in the client you click an option, your client will call the server API with the id of the spoken-to NPC, and the id of the selected conversation item.

The server will validate that the player is  currently conversing with the NPC, and that they are at a state where that selected conversation item was available, then process that selected conversation item (displaying a response, giving items, etc), then update their stored state.

6 minutes ago, DewiMorgan said:

State machines quickly become burdensome if you hardcode each case in a giant case statement. So you need state-handlers, which load the user's current state for a given quest or conversation id, and handle the transition to the next state.

Each game tick (or time round the game loop, or event) you pass any queued or incoming state change requests to the relevant state-handler. So when in the client you click an option, your client will call the server API with the id of the spoken-to NPC, and the id of the selected conversation item.

The server will validate that the player is  currently conversing with the NPC, and that they are at a state where that selected conversation item was available, then process that selected conversation item (displaying a response, giving items, etc), then update their stored state.

Is there any "code" example of such handler ? I'm currently reading and working with state machine sample and i would love to see how others are implemented it.

On 7.8.2017 at 6:25 PM, hplus0603 said:

Typically, you'll run all world updates in a single thread, so that you don't need to implement locking. It's very uncommon for a full world/zone to be so complex as to overwhelm a single core, unless you also do physics simulation, which may need a multi-threaded implementation.

There is one difference to single player games! In a single-player game, you will have two entities that matter: The player, and the NPC. If the player says something to anger the NPC, the NPC may change its own state to "angry," start to attack, and so forth; this state can easily be kept on the NPC.

In a multi-player game, there are actually three things that matter: Each player, each NPC, and each relation between specific players and specific NPCs. This separate player/NPC relation is actually a different "thing," and you'd probably do best to keep it separate in the game, although you'd want to store these states keyed on the player in your database.

So, the scripting callback from the player talking to the NPC might contain five arguments:

 

def onInteraction(self, world, playerInteraction, playerRelation, player):
    if player.faction != self.faction:
        self.tell(player, "You are not my kind!")
    elif playerRelation.state == None:
        self.sendDialog(player, self.initialDialogTree)
    elif playerRelation.state == ON_FETCH_QUEST:
        if (playerInteraction.action == OFFER_ITEM and playerInteraction.item == SMALL_GRAY_ROCK):
            self.tell(player, "This is great! Here is your reward!")
            player.addInventory(FLAMING_SWORD_OF_FIRE, 1, self)
            player.removeInventory(SMALL_GRAY_ROCK, 1, self)
        elif ...

 

 

This is actual event you are talking about, OnInteract, right ? Does your clients subscribe to NPC or in larger event manager thing ?

That is what i'm ultimately asking, i need to write handlers after all. I will try to look information from google for it. Thank you.

I still think there's a risk of making this whole process sound more complex and mystical than it really is. If the player wants to do something to an NPC, such as speak to them, they call a function which can query the current state of the NPC, and respond to the player accordingly. The only things that have to differ when your game is networked is that the function calls go across the network and need checking for correctness - i.e. is this player actually able to interact with the NPC?

The key to making this manageable is understanding that the process of getting messages from a client to a server has nothing really to do with the process of handling game logic and interactions on that server. Once the message is received from the client, you can call OnInteract the same way you would on a single player game. And once the server decides what the result of that interaction is, it tells the client to display something, the same way that it would on a single player game (but that eventually goes via the network).

If it helps:

client input   -> convert input to net message  -> .... internet ... -> net message to game logic request -> server game logic
                                                                                                                     |
                                                                                                                     v 
client display <- convert net message to output -> .... internet ... <- state change to net message <- game state changes
                                                                      \ game event to net message   <- game event notifications

If you keep clear separations between input, networking, game logic, and output, then things stay simple, providing you remember that all actions are asynchronous.

3 hours ago, Kylotan said:

I still think there's a risk of making this whole process sound more complex and mystical than it really is. If the player wants to do something to an NPC, such as speak to them, they call a function which can query the current state of the NPC, and respond to the player accordingly. The only things that have to differ when your game is networked is that the function calls go across the network and need checking for correctness - i.e. is this player actually able to interact with the NPC?

The key to making this manageable is understanding that the process of getting messages from a client to a server has nothing really to do with the process of handling game logic and interactions on that server. Once the message is received from the client, you can call OnInteract the same way you would on a single player game. And once the server decides what the result of that interaction is, it tells the client to display something, the same way that it would on a single player game (but that eventually goes via the network).

If it helps:

client input   -> convert input to net message  -> .... internet ... -> net message to game logic request -> server game logic
                                                                                                                     |
                                                                                                                     v 
client display <- convert net message to output -> .... internet ... <- state change to net message <- game state changes
                                                                      \ game event to net message   <- game event notifications

If you keep clear separations between input, networking, game logic, and output, then things stay simple, providing you remember that all actions are asynchronous.

That actually is best answer so far ! You are right when you say it's "more complex and mystical than it really is" because i know it's simple but it takes some little steps before you get it right. Now i know what i'm gonna do ! Thank you for this lesson !

I'm programming own server so this information is very critical as i want to make sure i'm implementing stuff the right way. Awesome stuff above this comment