Pixel Crushers Forum

Hi,

My game is a co-op 3D top down game with 2 player so we have decided that we want the dialogue to be pop ups like bark but a full conversation with choice option from player or something. I have gone through most of documentation and video tutorials. However, I am struggling to figure how this entire thing will be implemented and I am also unsure whether to commit to coding or is it possible to do it via the inspector entirely. It would be extremely helpful if there is a prior thread you can point to or suggestion for an approach that can solve this.

For example, I want it to behave similarly to this but a full conversation with choice options for the player.
https://drive.google.com/file/d/10YpBIk ... sp=sharing

I would like to also ask what is the best solution to this when there is two player? Since a player might trigger the convo before both is nearby. Do I customize the trigger with another script to check for 2 players in the proximity before allowing the conversation to trigger?

Thank you,
Belida

Hi,

I recommend using a conversation with overhead bubble subtitle panels. Please see: How To: Show Overhead Conversation Bubble Text

Duplicate the prefab mentioned in that article and use your duplicate. Replace the Text UI elements with TextMeshProUGUI elements (see TextMesh Pro Support) so you can use Text Animator to get the nice bouncy text effect.

Hi Tony, thank you for your help.

I got much of the bubble conversation going.

There are a lot of things I want to ask regarding the entire direction of what I want so I hope you can help me with these as well.

As mentioned above, my game is 3d coop. I should also mention that it is 2 player split screen. Due to this, I want to ask your opinion on the design choice. There is two main choice I can think of:

1. Just have player 1 handle all the conversation with the npc, this will reduce alot of the implementation as we have to only mind a single player now. Though this is cut alot of the narrative and engagement from the second player which I rather not commit to if the second solution is actually doable.

2. The second solution would be to include both players and I will have to assign the actor in dialogue actor at runtime so that player 1 will be player A and player 2 will be player b. I cannot assign these in a prefab ahead of time due to character customization and the input system will pick up which ever controller to input first to be the first player.

Another issue is the matter of checking the conditions for when to trigger the proximity selector. I can check for both players are in the area first, or only trigger the from one player and then teleporting the other player to be in the convo,

I hope to list out all my issues in one go so that you can answer or provide links to previous treads that provides tutorials or solution to these issues. Especially assigning or scripting at runtime.

Hi,

It sounds like you already found this info, but just in case I'll include these links:

• How To: Bypass Response Menu When Player Has One Choice
• Bubble Subtitle Example (direct download) on Dialogue System Extras page

There are two common ways to assign instantiated actor/conversant at runtime:

1. Leave the conversation actor & conversant fields unassigned in your Dialogue System Trigger (or pass null if you're using DialogueManager.StartConversation() in C#) and rely on Dialogue Actor components on the instantiated characters.

2. Or pass the instantiated actor & conversant to DialogueManager.StartConversation().

For both, please read: Character GameObject Assignments

It contains important information that explains how GameObjects are used in conversations.

Hi tony,

Can you please reread my previous reply. I was editing it to not spam the thread. Thank you again

Hi,

Both of those choices (and others) have been done before, so we can get either one working.

First, about triggering conversations: If you want both players to be near the NPC before they can start the conversation, you could make a subclass of ProximitySelector that checks that both players are close, or bypass ProximitySelector entirely and use your own interaction code instead. In this case, just call the Dialogue System Trigger's OnUse() method (or the DialogueManager.StartConversation() C# method) manually in your own code.

Alternatively, you could play different conversations depending on whether both players are near the NPC or only one player is near.

About running the conversation with both players: Create two player actors in your database, for example named PrimaryPlayer and SecondaryPlayer. Write your conversation using these actors. Example:

Conversation Title: "Dragon's Cave"

• NPC: "How can I help you?"
• PrimaryPlayer: "Where can I find the dragon's cave?"
• SecondaryPlayer: "Also, is there gold in the cave?"

Set the conversation's Actor to PrimaryPlayer and Conversant to SecondaryPlayer. To set the conversation's Actor & Conversant in the Dialogue Editor, select Menu > Conversation Properties. The NPC will be a third actor involved in the conversation.

Then let's say you have references to both instantiated player GameObjects in C# variables named player1 and player2.

If player1 initiates the conversation, use this C# code:
but if player2 initiates the conversation:
In this latter example, since you've passed player2 as the conversation actor, all dialogue entries assigned to PrimaryPlayer will be spoken by player2. Since you've passed player1 as the conversation conversant, all entries assigned to SecondaryPlayer will be spoken by player1.


If you plan to have response menus, you'll need to decide how you want the player(s) to respond. You could leave it up to the primary player (i.e., the one that initiated the conversation), or allow both players to choose a response first-come-first-serve, or use this approach that I used in a jam game long ago that I haven't seen used much elsewhere: When the response menu appears, allow both players to select their preferred response. If they both prefer the same response, use that response. If they choose differently, either randomly use one of the choices or don't allow them to continue until they choose the same response. This alternate approach requires making a subclass of the dialogue UI's StandardUIMenuPanel class to handle the extra logic.