Closed Bard09 closed 2 years ago
There are some better patterns for this kind of thing that we've blogged about on our Patreon, but broadly:
LIST Qualities = Surname, Age, Profession
// this function is your database === function getQuality(key, qual) {key:
// this only needs extending should you add a property, and it's a quick/simple pattern to extend === function selectQual(qual, val1, val2, val3) { qual:
Note the advantages of this are - should a surname change midway through the game, you can do that by putting the logic into the database function; not every entry has to be a list item, you can return strings, integers, even divert targets.
Thank you so much for the pattern! That is a much more efficient tactic than the switch-based approach I've pursued thus far and would aid my use case.
This is somewhat tangential, but I have been reliant on the official documentation and didn't think to look elsewhere, so discovering the Patreon posts was amazing. They're extremely helpful for more advanced programming scenarios like this-- is it possible to integrate some of their highlights into the documentation and/or even just provide a link to the Patreon posts on the Ink page?
Thanks again. I love the language!
I'm trying to store a List that can return multiple different types of variables depending on the selected List item (eg. the sort of data that would be returned in OO programming with an array of objects.
Imagine a List of Characters... I'd be like to use the list features (eg. LIST_RANDOM) to randomly select one of these three individuals, with the ability to scale to much larger quantities:
Given the absence of object arrays, I was hoping to create multiple aligned lists with identical counts, so that I could query each List by number and get the correct, relevant data, eg: nameList(2) & ageList (2) & professionList (2) to get the 2nd individual's data stored between all the Lists.
However, due to the deduplication feature of Lists, this isn't reliable-- anyone with a duplicate name, gender, age, or profession, will be skipped. Since there are only a handful of gender options in this hypothetical, that's easily the biggest limitation with this approach.
Currently, I'm using a workaround on top of the workaround with hardcoded switch statements in functions, along with hardcoded var statements for each list item eg:
This is definitely way more manual coding than I'd prefer to do, because every data point requires a named variable. I'm aware that Ink isn't a full OO system, but I think people who want to store data in this way could benefit from either an object array system, or allowing Lists to have a variant that allows duplicate data.
Thoughts?