Hello again!
In the last post, I touched briefly on some of the lessons I learned from scripting the dialogue system for Boardwalk Gulch. In the summary, I went back to the old system to clean it up; it was a good experience, but nevertheless I really wanted to use what I'd learned about dialogue moving forward. Thankfully, I got to do just that during a new project. With the added benefit of this new project not being a solo task but rather a group effort, I got the added challenge of creating a much-more standalone system then one I'd previously created. In this post, I'll be going over this new system, the changes from the previously created dialogue interface, and some major improvements I was able to make!
First Improvement: the Master Audio Handler
By far, one of the biggest changes from the Boardwalk dialogue system was the segmentation of the entire audio system into a single blueprint class rather than part of the larger game instance. This was by far one of the best changes made for this system. In addition to being a lot easier for the main coder on our team to implement and being nicely standalone, it was nicely convenient to have all audio-related variables and functions in one place rather than spread across multiple BPs.
One of the best advantages to this method was that it allowed me to easily alter the levels of the ambient noise during dialogue playback. Being able to temporarily lower and raise the volume of the ambient radio while playing dialogue was a nice addition made possible with this change.
Second Improvement: the BPI
In addition to the main blueprint for the master audio handler, I created a secondary blueprint interface for calling the master's functions. This was a much, much more versatile choice than the previous "cast to game instance" required for the Boardwalk system as it allowed for a lot more freedom to message and trigger functions for the audio from other blueprints.
Third Improvement: Randomization Handling
One of the biggest drawbacks of the Boardwalk system was its clunky way of randomizing what line was being played. Instead of this, I broke the randomization into two functions that utilized a specified tag from the BPI message. The tag array built corresponded to the audio array (ie, index 1 of the audio array is a generic exclamatory phrase and index 1 of the tag array is "exclamation"). When messaged, the "GetPossible" function was called, which looped through the tag array to find all the entries matching the specified tag, then added their index numbers to a temporary "matching entries" array. This array was then used to get a random line from that group of selected indices. The results are functionally similar to the Boardwalk system, but allow for much greater iteration and expansion than the former.
Conclusions:
Overall, this system was a great experiment in taking what I'd learned from a previous system to rebuild a better, newer version. This system is a heck of a lot cleaner, and as such, I was able to quickly and successfully integrate it into the main project file.
Thank you for reading this post! Next time, I'll be getting back into more completed blueprints!