There’s a difference between “who is saying what” and “how do you present dialog.”
For example – if you were to make this game for blind people, “presenting the dialog” would mean reading it out with text-to-speech, rather than in a GUI widget.
Thus, it makes sense to keep “what is this character saying” in the character blueprint, but keep “how do I present this?” in some other system.
I would probably add an interface on the player character that is “dialog perceiver” and in turn have the player character forward perceived dialog to the player controller, and then have the player controller control the GUI. The “dialog perception” hook/event/function would perhaps be triggered with an on event overlap, and it would forward both “who is saying it” (actor reference) and “what are they saying” (text, and possible dialog options) as part of the event/function. The player controller can then figure out how to present it (it might place it close to the actor on the screen, for example) and how to react to it.
Another option would be to place a 3D world widget component on the speaking actor. This would let the text “float in the air” around the character. This would also keep presentation of the dialog in question on the actor, which is simpler (like you wanted up top) but doesn’t allow as much “understanding” of what is going on with dialogs – and, especially, interacting with the dialog becomes more intertwined between player controller/character and NPC.
The widget BP doesn’t need much logic – “text to display,” and “possible options” (which might only be “acknowledge”) and an event callback for “player chose an option.” The logic for how to interact with a displayed dialog utterance should be in the player controller IMO, and the logic for how to carry the dialog forward would then in turn be back in the character BP.
Why should I split interaction logic? I don’t know much about OOP, but I thought it’s the best practic to keep related logic incapsulated.
For now, I just want to at least solve 1 and 2 problems I’ve mentioned before, and I hope I’ve provided all necessary information about it. I just can’t understand why it’s not working…
The issue is that your logic is nested; you have to keep switching between pages to find what each function means. That might be why you have trouble remembering what each thing does; it’s not right in front of you.
I’m not in your mind, so I do not know.
However, I would, personally, NOT encapsulate dialogue. Ever. Unless it’s completely canned (Default greetings, expressions, etc.).
If you mean to have to characters talk to one another, I think you should see the dialogue printed right in front of you:
Also, @jwatte , I agree with, with regard to separating HOW dialogue is presented and WHO (anagrams!) is speaking it, unless you only have ONE NPC character in the entire game.
It’s annoying at first, but saves time later.
I mostly used RYAN LALEY’s tutorial, however, when he started using FOR LOOPS, I was like, NOPE. So, do what works for you, unless you have absolutely no idea on how to do something.
