thank you! I'm glad you enjoyed the depth and pacing. Worked pretty hard on that!

The decision to separate the dialog data and the dialog functionality was a very deliberate one as I don't really want dialog in my code. I also considered a system that could just output the dialog as they are ordered in the container which would mean I wouldn't need to look up and push indices. The downside with that is that not all dialog is sequential. However, I did create a PUSH_DIALOG_RANGE function (can't remember if i briefly mentioned it in the video or not) which can easily push a range of uninterrupted dialog that was ordered in the container. As for what will happen when there is more dialog: that is where the containers come in! Since the containers will only have a very small subset of dialog that I will be working with, it makes it really easy to find the relevant dialog and implement it.

Best of luck! I'm rooting for you!

I considered this too but I feel that it just moves the goal posts around. Right now the indices don't *have* to be in order so re-ordering isn't completely necessary and can handle last minute additions by just appending them at the end of the container but add them earlier in the code. For blocks of dialog (not interrupted by pauses or actions) I can use PUSH_DIALOG_RANGE to push a range of dialog regardless of order and so inserting new dialog and extending the range works great here. Using entry names would involve coming up with meaningful names, spelling them correctly, and if the content of the dialog changes then i might need to change the name and then change the code anyway. So names does solve the re-ordering issue, but currently I'm not seeing how it would meaningfully improve the workflow overall. Thanks for the feedback!

@@jembawls Fair enough! There are pros and cons to both. In particular my own system doesn't work too well with adding more lines of dialogue into a cutscene block - it certainly works but not as easily as yours. Your video has given me some ideas!

I guess one benefit would be to easily see the dialog contents directly in the editor, if there were meaningful names. Could be useful when you a couple of months later edit the files. Could a plugin give annotations in the editor? Show the actual content. Would be really cool.

First point: No, actually! And this is a great point and a big oversight on my part - thank you! It would be great to embed some information regarding that. Perhaps I can hook the portrait/emote name into the translator comment that might help a bunch. Second point: The system itself took a couple weeks worth of work to design and set up but i was also learning the engine at the same time so a lot of time was spent lost on that. The plugin was about a week or so to learn and implement. Third point: non-modal is definitely something that is also on the to do list and i also forgot to mention in the video. I'm still undecided if I want all dialog to be in a big, traditional dialog box or floating over people's heads. But if I go with the traditional box, I would still like some overhead stuff for emotes or short phrases that don't interrupt the game flow. Thanks for the feedback and also great questions!

Indeed! The current system does allow for the wildcards to be repositioned when localized.

Thanks! Glad you like it! As for the string IDs: The short answer is I don’t think I like the workflow of coming up with string IDs every time I create or meaningfully edit a dialog string is appealing to me. It’s true that having the string ID would add more context to the code, but the code is already filled with context (dialog container, function/event/cutscene name, comments) so I’m not sure if the trade away from indices is worth it. But my mind is open, and I’ll keep it in consideration as I continue to work on the game in case i can see more value in it. Thanks for the comment!

This is what I had initially intended actually but very quickly realised when it came time to implement dialog that tracking only by NPC doesn't really make a lot of sense. First of all: which NPC should the chips on the shelf be allocated under? 😂 Secondly, if you have 2 NPC's talking to each other in 1 cutscene - which NPC should the dialog be under? Their respective text could of course remain under their own NPC containers, but that then means loading 2 containers and trying to find the right dialog in 2 different locations, which may be very tricky because NPC's will have different amounts of dialog and their dialog will be paced differently. I find it makes the most sense for the containers to represent ~~whatever makes sense~~. So containers can be a location, an NPC, or a cutscene - whatever makes organising and executing that text easiest.

@@jembawls You are absolutely right! I did not consider those situations! I do have to say from my experience with these kind of "document" Organisations having a good system set-up at the start will save a lot of pain points down the line! Maybe you could introduce tags for each NPC to quickly find specific ones. That way you could even tag a single dialogue with multiple tags such as NPC 1, npc 2 and active quest / situation. That way saving them in folders based on location gives you two search angles so to speak. But in the end it needs to work for you so as long as it does whatever works works! Really like how transparent you are making the whole development process! Keep up the good work :)

In this case I can regenerate the .POT file and distribute that to translators. They can then update their .PO files using the .POT file and continue translating. As far as I can see, the edited strings get updated via their context and flagged as needing review in Poedit.

I love CrossCode!

So plural support is to swap out translations based on a number you provide. So for example: if j have a wildcard string “I have {quantity} banana”. If we have 1, we would show “I have 1 banana” but if I have 2 it would show “I have 2 bananas”. gettext (according to my research) can also has support for language specific pluralisation. Some languages (Japanese, for example) don’t have plurals, and so the Japanese translation file won’t have required entries for plurals. But there are other languages that have multiple forms of plurals depending on the quantity. Hope this helps!

@@jembawls thank you! Yes, different languages will require different number of strings when there are placeholders standing in for numbers from (typically 1 to 4). Hungarian for example only needs one because although it does have plural forms, it uses singular noun for all "number" + "noun" structures. It's great that your system will be able to handle more complicated scenarios as well as context help for translators. I have seen it happen that even though the system is ok to handle plurals, the info on which string covers which cases is too general or doesn't go all the way to the people who work on the strings. So if the context strings can help with that, this issue won't happen here.

The plugin is DEEPLY tied to the rest of my system which I don't think is suitable as a general-purpose dialog/localization system, so I don't think I will unfortunately. Maybe as I work on the game and develop more features for system it might become more worthy of generalising and distributing.

The IDs being numerical come with other advantages (such as pushing ranges) while at the same time not actually needing to be ordered (unless pushing ranges). They also don’t require coming up with a named constant every time I create or insert a new dialog string, or when meaningfully editing a string such that it’s constant is no longer contextually accurate. The nature of using the containers also means that unordered dialog (or re-ordering dialog) in an event is not very hard to do and won’t have knock on effects elsewhere so it’s not that error prone - EXCEPT when I opt to use location-based containers (where different events may share the same container) in which case I’ll need to be careful, or just split up the events into their own containers in a sub-folder. I can maybe see some value for potentially adding an optional tag value to the dialog strings that I can look up and increment from (or something like “add dialog up to a tag”) but I won’t embark on that journey unless I really feel the workflow calling for it. But a few people have suggested named constants so I’ll keep it in mind as I work with the system and consider it as a solution if (WHEN! 😂) I run into issues. Thanks for your comment!

PUSH_DIALOG( "Because I'm using all caps functions help distinguish global helper functions from regular code");

Editor here, I'm sorry you had that reaction :( I even put an audio filter on the background music so that the higher-pitched elements weren't as loud. I'll consider music with less high-pitched melodies in the future. I find it annoying as well, so I try to make it blend as well as possible.

@@MasonzeroDigitalWorks thanks 🙂. It wasn't so bad once I realized it.