Lay It All Out in a Table
Dev log for Project Amethyst from 9/4/18 to 9/11/18
What have I been working on since the last update?
First of all, you might have noticed that this is my first one week update. I usually only post biweekly because it often takes me that long to complete a major feature, but this week I went all in on the conversion of my dialogue system to pull from a csv sourced data table.
Most of the columns are self-explanatory save for maybe CommandInput. This is used as the “what” for the command (i.e. sword or 2x potion).
After a ton of fidgeting and several discussions with teachers, I settled on the layout seen above. The primary way this functions is through the use of string IDs while also containing some information that would otherwise have to be public variables on the NPC class. This allows me to truly modularize my NPC class so that I will never need to create a child class. This is what the variables look like on an NPC object:
This is actually made using a dictionary in an unorthodox manner. Each entry takes in a string condition(s) and the corresponding ID from the table. As of right now, the only conditions supported are global variables from the game instance class.
For the sake of not writing custom blueprint nodes, I had to make these a dictionary as well. Turns out that finding a variable on another blueprint by its name (a string actually) is not a built in functionality. Using a dictionary was the work around to that issue as you can see below. Anyway, those are all the major external components to the system, so lets get to the crazy bit.
This beautiful cluster of chaos is all the logic that determines which dictionary entry on the NPC should be used. The logic flows as such: 1a) get an array of all the conditions in the dictionary, 1b) split the conditions by a forward slash if needed, 2) check all the conditions for each dictionary entry against the global variables list, 3a) if they are all true, move on to the next entry, 3b) if any one of them fails, lock in the previous entry as the one to use and break both loops, 4) use the selected key to get the row ID and pull its info from the data table. This would be much simpler if it didn’t allow for more than one condition per entry, but I will absolutely need that functionality going forward. After all that is done, the outputs of this function get returned to the core blueprint of the dialogue component.
There is one big (potential) issue with this setup, and that is that the dictionary of conditions must be in ascending order of importance. This is because as soon as any one of the conditions returns false, the looping stops. If there is a good way around this, I have yet to find it. I don’t anticipate it being a huge problem at the moment, especially since I moved conditions like item checks that don’t lend themselves to being sort chronologically to command calls that can be called between string pages instead of before. I will just have to be careful to make all condition checks easy to sort.
This part is super messy right now and I still need to do a bit of work on it. The GetStringAtID function is identical to the bottom-most part of the other function so I didn’t feel it deserved its own picture. This is also the area where the main branch logic is handled, where the result of the choice is passed from the UI widget. The issue with this is that it currently doesn’t support more than one branch per conversation, though that should be a relatively simple fix that I will do next. Once that is complete, the dialogue system will declared “done for now.” Its also worth noting that the Commands referenced here and in the data table don’t actually exist at the moment as they will be a component of the inventory system instead.
What obstacles have I encountered?
The two big hurdles this past week were finding the best way to format the dialogue table and figuring out the logic for the conditions. Each of those tasks took me about two days to get to a state I was happy with. In a rare occurrence, the conditions logic came very close to working as intended on first run. I just had to change around the way I was setting the final ID to use and the Cleared bool. I will likely add more columns to the data table later to account for added/needed functionality.
What's next?
After I add the support for multiple branches I will move on to the next big piece: the inventory system. As I briefly mentioned last update, I have never written such a system from scratch. Thus, I expect this to take me upwards of a month for just the base functionality. I will continue to post regular updates on my Twitter and will still do my usual biweekly posts on here, but don’t expect any more big breakdowns for a while.
Until then, thanks for reading!