Pixel Crushers Forum

Hi, I would love some DSU architecture advice please, first time using the asset. I believe my system is quite simple, and I see that most of the tutorials are aimed towards many complex dialog trees with many actors, which is not my use case.

Context: Poker/card-based title, single player.

Core goal: Dialogue similar to "Poker Night at the Inventory." / "Poker Night 2". This means:
* Frequent, contextual barks from AI opponents (barks if they have high chips, are winning, etc)
* Character-specific banter and interjections that reflect personality.
* Dialogue triggered by game logic events rather than traditional NPC interactions -> For example, if a AI NPC is a bluffer, he will taunt the player based on the cards he have.

I'd love if you could offer any high-level architectural advice or point towards specific DSU features/patterns/HOWTOs you'd recommend for structuring such a system. Mostly:
* Efficiently triggering many small, event-driven dialogue lines/barks (based on cards, odds, chips, state of the game, etc)
* Managing conditions based on numerous game variables (player stats, current game phase, etc.).

I'm looking at features like Signals and Lua conditions, but any guidance on how to best combine these for a "Poker Night" feel in a complex poker environment would be great.

I thought about having a huge database and calling all barks using DSU signals, not sure if it's a dumb idea.

Thank you!!

Hi,

You might be interested in the two replies to these posts:

• Beginner trying to understand Conversations & NPCs talking to Each Other
• Dynamic Conversations without too many variables?

They're both about card games, and they discuss similar ideas. If you have any questions about them, or if other questions or ideas come up, please let me know!

Thanks for pointing those out, they really helped! They were incredibly helpful and provided a lot of clarity.

a) Architecture
Based on those threads and more research we did, this is our architecture draft then:

1. Bark Management: We'll create dedicated "Bark Conversations" for each character (e.g., `WildCowboy_Barks`, `BigBilly_Barks`). Inside these, the `START` node will branch to many barks. Each bark entry will have its Lua `Condition`, text/audio, and we'll add custom fields like `Priority` (Number) and track play counts/cooldowns using DSU Variables and Lua in the `Script` fields for repetition control.
2. Dialogue Event Manager (DEM): A central C# script will subscribe to our game's C# events (e.g., player folds, pot changes, chips changes, etc). When an event occurs, this DEM will:
-> Update relevant DSU Lua Variables (`DialogueLua.SetVariable()`).
-> Trigger the appropriate character's "Bark Conversation" using `DialogueManager.Bark("Name_Barks_ConversationTitle", speakerTransform)`.
3. Longer Interactions & NPC Banter: For multi-line exchanges or NPC-to-NPC banter, we'll use standard DSU Conversations with auto-continuing nodes, triggered by our DEM.
4. Conditional Logic: Primarily rely on Lua in the "Condition" fields of dialogue entries, checking DSU Variables set by C# game logic. We'll register custom C# functions with Lua for more complex game state queries if needed.
5. Expressiveness: Use DSU's custom fields on dialogue entries ("Mood," "Intensity") to be read by C# (`OnConversationLine`) to influence audio delivery or character animations.

Any last minute feedbacks? This sounds perfect for us (we're only two people so sometimes we overthink to avoid some refactoring later on).

b) INK - yes or no?
And another question please: After researching here and on other forums, some people suggested using Ink as well. Do you think it's a good idea? I believe it will only add extra overhead but my partner believes it will make it easier to write.

We're trying to decide if the potential power of Ink for complex conditions or narrative flow would be a major boon, or if it might add unnecessary complexity when DSU's own tools are already quite capable for our described needs. For me, Ink would be a terrible idea (I'm the only programmer). For my partner, it will help writing.

Thanks a ton and sorry for the wall of text, your feedback is invaluable.

Hi,

Since you're going to have a lot of barks, I recommend against Ink. Ink is good for long flows, but it's not so great for barks. And, as you said, it's another moving part to keep track of.

Consider naming your bark conversations `WildCowboy/Barks`, `BigBilly/Barks`, etc. or `Barks/WildCowboy`, `Barks/BigBilly`, etc. The forward slashes will group conversation dropdowns into submenus, making it easier to find and select conversations.

It does take time to check each dialogue entry's Conditions, so please see: How To: Use Group Nodes To Reduce Condition Checking Time. You can also pass a specific dialogue entry ID to DialogueManager.Bark() if you want to bypass condition checking and just show a specific bark immediately.