Advice on storing data for a branching path game

[wicked fractal]

I'm having hard time thinking of a good way to store info for this branching choice game I'm planning atm
What I'm currently thinking of doing is storing the choice info in a dictionary var with an id and class holding that choice's info such as what the choice is and whether the player has done the choice and then saving this info onto a json file
Is there a better way to store this info than this approach?

[pseudo drift]

in my game i have a dictionary of “flags” which can either be on or off. these are things like

• talked_npc1
• trigged_lever_secret
• killed_boss_dragon
  etc. they can be local to a level (reset upon leaving) or global to the entire game. No need to store in a json file, you will likely have a class to serialize data to, just make an array with all the active flags in there.

[wicked fractal]

How would save the progress if you are not saving it to a file or playerprefs?

[pseudo drift]

you serialize the class to a file

[wicked fractal]

K 👍 will look more into that

[pseudo drift]

research how save/load systems work, my preferred method is a binaryformatter to turn a class into raw binary data

makes it easy to store data

[hushed plover]

doing it via a dictionary is fine, especially if you need other classes to dynamically get/set these branching choices. what are you thinking of using for the ID? a string?
I would just write it using JSON so you can see it in a human readable format and verify your output works correctly if you arent familiar with file IO already

[hushed plover]

flags in c# refer to enums with the flag attribute. i assume you just mean a dictionary of bools

[pseudo drift]

ah, yeah

event flags

[wicked fractal]

Ye I'm planning on making the id a string and doing a naming scheme based on the path of the choice
Like [Route]_[Choice Num]_

[feral vale]

This is no longer recommended by Microsoft after a lot of issues with the binary being hacked, serialize to JSON is generally better

[feral vale]

You could have them as Enumerable, so optionA, optiomB, optionC etc
Then do check against the enum state

[wicked fractal]

For the ids?

[feral vale]

Well in general string comparison isn't amazing. But you could have it check example <string, enum>
or <string, int> and be like "if(type is ExampleType.A)" then code
Or check against your integer values stating that start text offers 3 options, if <string, 1> then you want the first of the second batch of texts, else if <string, 2> you want the second. Etc

[pseudo drift]

binary being hacked? like they can figure out how to modify the data?

honestly thats not a big deal imo

[feral vale]

www.learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide

[pseudo drift]

for this it really doesn’t matter. no check for global story event paths should be performance critical

the only issue with strings is its easier for them to be lost, misremembering which strings exist and what they mean. something like an enum takes extra effort to add to and manage but its easier to select in the inspector and u can comment it

[feral vale]

As a reference if people want to read it

[pseudo drift]

ok i see, fair enough

[wicked fractal]

Not sure storing the options themselves as a enum would work with the info I need to store but that did give me an idea on a way I could store the state info for the choices and achievements

[hushed plover]

storing the IDs as an enum would be a bit less fragile. the "choices" themselves make sense to be a class or even SO if you need complex logic handled by each choice

[feral vale]

public class TBD : MonoBehaviour
{
    [SerializeField] public DialogueExample example;

    private void Start()
    {
        if (example.option is DialogueExample.Options.A)
        {
            Debug.Log("OptionA");
        }
    }
}

[Serializable]
public struct DialogueExample
{
    public enum Options
    {
        A,
        B,
        C
    };
    [SerializeField] public Options option;
    [SerializeField] [TextArea] public string dialogueBox;
    [SerializeField] public string speakerName;
}

example i threw together to show you an option you can obviously put these into a list or array

[wicked fractal]

Hmmmm
If I do store the ID as enum it would make it faster to access them, though would require abit of effort setup
I think I may look more into that

[feral vale]

plus you get to use my favourite comparison - is :>

[hushed plover]

its not about speed, you could run the code 100k times and not visually notice a difference between string and enum there. its just so you dont mess up when trying to reference something by its ID.
If a component wants to reference an ID, you just select it from the enum rather than typing it in and possibly misspelling it

[wicked fractal]

That's what mean
I wouldn't have to consistently crossreference a list of ids to ensure I didn't make a typo and break something
I could just have a single list I could pull up more easily

[hushed plover]

ah

a string would be fine too if you go with the scriptable object route for the actual choices. The SO could hold its own ID field which gets assigned randomly