This is now implemented and live!
It works not only for the speech bubble, but for all NPCs, allowing for stories where an NPC can seem to “leave the room”.
First off, great work! I was about to suggest you implement it on NPC's too, depending on how it works, but you beat me to it :).
Now, it works great for the balloon, but I would suggest you change the order of execution for the NPC's if possible. Right now the disappearing option happens after the first dialogue is complete. It should happen after the last dialogue. This way you can have an NPC talk to you(or give you a task), react to what you did and then disappear, it's a small difference, but an important one I think, since it allows for extra interaction with the same NPC.
While on the topic of NPC's, there is also the thing about the "alternative dialogue" and the "yes/no dialogue". Right now if you have all 3 the execution is Dialogue 1, Choice, Dialogue 2. But in the editor it's 1,2, choice. So I propose either fix the order of execution, so the yes/no dialogue is the last to execute or change the order in the editor to make clear things go in that order. Probably the second one otherwise it may break something.
Oh and about the "yes/no dialogue"- I know I was one of the people suggesting it in the first place, but I think it turned out a bit too limiting the way it is. What I suggest is changing it to more general sign of acceptance/denial. Something like âś” and âś– (or đź‘Ť and đź‘Ž), while keeping the green and red border of the buttons intact. It shouldn't brake any existing games and would open possibilities for(slightly) better dialogues and quests in future.
So to summarize:
Balloon is great!
NPC's might need a change- disappear after last dialogue.
Might want to: rearrange order of actions in the editor, change "yes/no" for "âś” / âś–"
I'm sorry if it seems I'm just waiting for you to finish one thing to hit you with another suggestion or request. I really appreciate all the work you're doing, I just want to make sure the engine is as good as it can be.
Great suggestions, but theres one problem with the disappearance of NPCs happening in the “last” dialogue: there’s no way to know what is a “last dialogue”.
Suppose you have an NPC with default and alternative. The alternative happens when variable X is true. You’re assuming that once X is true and alternative is read, thats the last dialogue, but variable X can be set back to false (via lever for instance). What is someone wants to make a game where you have to set X back to false to read default again? In that case, default should be last and this developer would complain that they want the NPC to disappear after reading default the second time.
Or even yet, what if there’s an NPC with default, choice and alternative, where alternative is set by X being true, but the developer wants the NPC to disappear if the player talks to NPC while X is false, right after the choice. That would not happen if I consider alternative the last dialog, even if alternative is not triggered.
Or even: what would happen if we introduce unlimited ammount of dialogues (as has been suggested by the community)?
I think that by limiting disappearance to the first dialogue the engine just caps all divergent scenarious of “when should the NPC disappear”. It also caps possibilities, but (I think that) for a minimalistic engine, possibilities should emerge from creative workarounds, not by features.
I was considering one “disappear” checkbox per dialogue, but I also do not want the engine to look bloated and scare new users. (to me it already looks kinda intimidating, we’re actually thinking of ways to improve the UI).
Just implemented. Now it shows “✔/✖” instead of “yes/no”, also now the order executed is default -> alternative -> choice. I chose to change the executed order instead of the buttons, because that feels more logic than changing the buttons, since the alternative dialogue can be a direct sequence of the default dialogue if the default toggles the variable that triggers the alternative.
Default -> alternative -> choice is indeed the better choice if it's not breaking compatibility.
The implementation of “✔/✖” works great, but maybe put the checkmarks in green/red too. While those are mostly universal I seem to remember some countries like Japan use both ✔ and ✖ as a negative(as in "incorrect"), so putting them in green and red respectively should help clear that situation(if it arises at all- I might be wrong about the whole Japan thing).
Anyways, great work. The engine turned out pretty nice and while some elements like the reward systems can use some light rebalancing I can honestly say I'm pretty happy with the result. It's by far the best small RPG engine out there and definitely the most user friendly one.