Complete Dialog System / Subtitles / Speech Bubbles

[Droggelbecher]

Before implementing spend some thoughts on the structure of the dialog system i.e. it should be possible to choose between different frontends for displaying spoken sentences and for selecting ones

[ghost]

Does anybody have any ideas of what is the best way for this to work. If you look at the dialog branch, actors have pointers to all of their queued dialog lines, and at render time they get checked to see if they are currently speaking and if so their current DialogLine is gotten. Is it effective for the default dialog frontend to create a new Text object each frame based on what the actor is saying, and render that? Or should the frontend have a register of Text objects linked to DialogLines? Sorry if this sounds confusing, might make more sense to look at the code.

[Droggelbecher]

I think it would be best to avoid allocations that happen each frame and rather "cache" the text object, updating it only when the text changes, ie. hold a text object and remember the text it reperesents (or the text object could do that itself if it doesn't already)

[Droggelbecher]

I just looked it up: Text has a method setText() that will only re-render stuff when the text actually changes. So all you have to do is keep a text object per character and update it. Although it probably wouldnt be wise to keep that object in the character (as it is a matter of the dialogfrontend).

Maybe one could use a std::map<Character, Text> or something along those lines? I also send you the old indiana code, but don't have the time to look into it now. Dunno what I did there back then but maybe you can use some of the ideas (D should be really easy to read for a c++ coder so don't worry)

[ghost]

Yeah that sounds good.

So I'm thinking maybe the frontend can have registerSpeaker(Actor) function which maps a speaker (by name?) to a Text object. So the mainloop can check if an actor has dialog queued and if so registers them with the Frontend which then renders their current dialog line in a way defined by whichever frontend is being used. If the character is not speaking unRegisterSpeaker(Actor) can be called to remove not currently speaking actors from the map.

Does this sound ok?

[Droggelbecher]

Hm I'm not sure if that registering step is actually needed. How about this (as a rough idea): Actor.say(text) calls (maybe with some necessary indirection) dialogfrontend.say(String text, Actor *actor); the dialogfrontend manages a map that assigns the adress of the actor to a queue/list/whatever of sentences it has to say, if the list is empty, the entry in the map is removed completely, if say() is called for an actor that is not in the map, the entry is created, if the actor is in the map, the sentence is appended to the "to say" list of that actor.

this still leaves open who will check those sentences and display them, probably a dialog frontend base class or similar, or a task.

[ghost]

I have committed a rough implementation of this. Hope it's ok.

[ghost]

I'm just thinking about what is the best way to position the speech text in relation the the actor, as getPosition() returns a a position at the actors' feet, and I can't see a way to determine a position above their heads. Actor has a method getUpperLeftCorner() but this is protected. Should I make this public? Or do you have any ideas of the best way to do this?

[Droggelbecher]

Good question, i'll have to spend some time looking at the code to remember if I had a reason to make it procected (and what that reason was). Probably easier to do in any case would be a subtitle like speech system, or what do you think? (I.e. displaying all text centered at a fixed position on the screen (e.g. centered at bottom))

[ghost]

Cool. Ok, I'll start working on a subtitle frontend instead for now, yeah this should be easier

[ghost]

So the subtitle system is pretty much done.

I guess the next step is to create a speech bubble system? Or move on to something else entirely.

[Droggelbecher]

You can of course do, whatever you want. Speech bubbles would be nice of course and also talkie support (i.e. play sound files with recorded texts)