Hello.
We're making a coop game and stumbled with one issue refferd to the dialogue system.
We have several players and any of them could trigger different dialogues at one time. And the problem is that I can define a player who triggered a LUA command in dialogue script.
For example,
- I created LUA command "HasInventoryItem()" in which I just check wether player has definite item ID in his inventory.
- I have dialogue which has brunch with condition : HasInventoryItem(42)
- If actor doesn't have such an item I instance it.
- And this dialogue can't work properly because I can't define exactly what player triggered the command.
Do you have any solutions here? Or if not, could you provide such interface? For example, before every lua script execution in dialogue, you can put actor in LUA.current variable.
Thank you.
Coop problem
Re: Coop problem
The name of the conversation's current actor is in the Lua Variable["Actor"]. Will that help?
Re: Coop problem
I'm not pretty sure. What if 3 players triggered 3 dialogues at the same time?
I guess in Variable["Actor"] will be the player who triggered last dialogue.
I guess in Variable["Actor"] will be the player who triggered last dialogue.
Re: Coop problem
Hi,
If it's same-screen local co-op (like Gauntlet or BroForce), then only one conversation is allowed to be active at a time. Otherwise you'd have a dialogue UI trying to display multiple conversations onscreen all at once. I'm working on a local co-op game like this which overrides the dialogue UI's ShowResponses method. It lets the characters vote on a response.
If it's online co-op where each player runs their own client (like Diablo), then each client runs a separate instance of the Dialogue System. Several teams are working on MMOs that work like this. In this case, in each instance there's only one LocalPlayer.
I hope that helps. If not, please describe your multiplayer design a little more so I can provide some more specific suggestions.
If it's same-screen local co-op (like Gauntlet or BroForce), then only one conversation is allowed to be active at a time. Otherwise you'd have a dialogue UI trying to display multiple conversations onscreen all at once. I'm working on a local co-op game like this which overrides the dialogue UI's ShowResponses method. It lets the characters vote on a response.
If it's online co-op where each player runs their own client (like Diablo), then each client runs a separate instance of the Dialogue System. Several teams are working on MMOs that work like this. In this case, in each instance there's only one LocalPlayer.
I hope that helps. If not, please describe your multiplayer design a little more so I can provide some more specific suggestions.
Re: Coop problem
It's Diablo like co-op but it differs from your second option: clients are just input source for server. And the server decides everything and then send information to clients.
So we really need an interface which could help us define what player triggered LUA command.
So we really need an interface which could help us define what player triggered LUA command.
Re: Coop problem
Here are two options:
Option 1: (recommended)
Even Diablo runs most of its work on the client. Run the conversation on the client, but write the Lua commands to contact the server for authoritative data. For example, modify your HasInventoryItem() function to run on the client and query the server. Since HasInventoryItem() runs on the client, it can pass the local player with the query.
This has some advantages: (1) For single-player games or debugging, you can register a local-only version of HasInventoryItem() at runtime. (2) Players can run simultaneous conversations, since each conversation runs on the client's instance of the Dialogue System. (3) Since the conversation runs on the client, it can use sequencer commands on the client to do things like play audio and activate GameObjects.
Option 2:
Run the conversation on the server, but trigger it on the client. For example, say the player must click on an NPC to start a conversation. When the player clicks on the NPC, the client can send a message to the server to start a conversation with the player and the NPC.
By default, the Dialogue System is designed to run one conversation at a time. To run simultaneous conversations, you must create a DialogueSystemController for each one, and then call that DialogueSystemController's StartConversation() method.
Option 1: (recommended)
Even Diablo runs most of its work on the client. Run the conversation on the client, but write the Lua commands to contact the server for authoritative data. For example, modify your HasInventoryItem() function to run on the client and query the server. Since HasInventoryItem() runs on the client, it can pass the local player with the query.
This has some advantages: (1) For single-player games or debugging, you can register a local-only version of HasInventoryItem() at runtime. (2) Players can run simultaneous conversations, since each conversation runs on the client's instance of the Dialogue System. (3) Since the conversation runs on the client, it can use sequencer commands on the client to do things like play audio and activate GameObjects.
Option 2:
Run the conversation on the server, but trigger it on the client. For example, say the player must click on an NPC to start a conversation. When the player clicks on the NPC, the client can send a message to the server to start a conversation with the player and the NPC.
By default, the Dialogue System is designed to run one conversation at a time. To run simultaneous conversations, you must create a DialogueSystemController for each one, and then call that DialogueSystemController's StartConversation() method.
Re: Coop problem
Seems the first option sounds pretty sensible.
Thanks for the answer!
Thanks for the answer!
Re: Coop problem
Happy to help! Option #1 has worked well for developers in the past. If you get stuck on anything, let me know if I can help.