Large set of boolean variables for defining game state?

[Slavq]

I'm thinking about creating a large set of boolean variables which would define if certain events happened or not.

For example, let's have an NPC named Bob. During exploring, player sees a tree with a big "BOB WAS HERE" carved in the bark. Then, after meeting Bob, we want to add a dialogue option "Bob, it's not nice to hurt trees! " - but of course only when player saw the tree! ... Imho the simplest solution would be a boolean check in dialogue options (enable only if "playerSawTheBobsTree" (bool)) - but where is the best place to store all these booleans? There would be quite a lot of them.

I'm not sure how to approach this. The only thing i have on my mind is a data-only Actor blueprint named AdventureState containing all those booleans and nothing more. Then, put a reference of AdventureState object in PlayerController. So when player sees the "BOB WAS HERE" tree, we just set PlayerController.AdventureState.playerSawTheBobsTree = true.
Is there a better way to do this? How would YOU approach this?

[_cDub]

There are probably way better ways to do this, but something that you could do is have an empty array of actors on your character or PC. Then when you approach the tree, have the tree add itself to the array. When you talk to Bob, be well check to see if his tree is in the array. If it is, give him the option and remove the tree from the array.

There is probably better ways of doing this, but at least it is a bit more modular.

[Slavq]

There are probably way better ways to do this, but something that you could do is have an empty array of actors on your character or PC. Then when you approach the tree, have the tree add itself to the array. When you talk to Bob, be well check to see if his tree is in the array. If it is, give him the option and remove the tree from the array.

Thanks, array of actors seems like a cool idea, but:
1. Not all "game states" would be related to specific actors + What if a tree would have an extra spot to investigate, allowing player to notice another carving, "Bob + Eva <3"? + I don't know how it would behave when changing levels, if a tree would be placed only in level 1, probably it would be unloaded (destroyed?) after loading different level?
2. I store my quest/dialogue data in CSV file (importing into Data Table) - and determining availability of certain dialogue by simply putting "playerSawTheBobsTree" in "Requirement" column would be handy...

I wonder how it's done in most of the games...

[_cDub]

What about an array of strings? Kind of like a password.

It would be nice if someone with a better programming background than me would chime in. Lol

[vegetamaker]

There are many possible solutions for this. I don't have many experience creating games, but in my opinion you should just save all needed variables in a file. Let me be more graphic:

* Player see Bob's tree -> Store boolean state in the game file.
* Player meet Bob in XXX place
* In BoB blueprint -> Event Begin -> Load Bob's tree boolean state from file and store it in a "temporal" boolean.
* Check that variable when needed.

At least that's how I try to do it.

If the options are very limited and can't be handle between them (per example if you meet Bob before see Bob's tree then you will never have the option of to do other thing. I guess you get the point). There could be then a simple "int" with switches.

= 0 you don't meet BoB and never found his tree
= 1 you found the tree but still never met Bob
= 2 you met BoB but not found tree

In this case the code could be very "clean" but the options are very limited in a sequence that, anyway, you must check in someway.

So... The many booleans isn't a problem really, just remember note them in a document and for what you created them.

And, of course, you MUST do a diagram of events. That is VERY important. A bad order of booleans check could result of that you can access to content that players should not have access

[NDFJay]

Personally I'd store all the bool values in a struct within the game instance and just reference it from which ever actor is needed, for example

BoolstateStruct -> Game Instance
Bob Blueprint -> cast to Game Instance -> Get Boolstate Struct -> Expand struct -> branch off Player see bob's tree -> Execute relative code

Blueprint representations

[Slavq]

Thanks for the hints guys! So... Basically you say that a little army of Booleans is not that evil?
@vegetamaker Of course, some list of all booleans with description (+ diagrams in more complicated cases) would be neccesary.
Well, probably a Structure in a Game Instance would do the job, as GameInstance is persistent, and Structure is a comfortable place to store all the booleans. Cool!

PS. Bob says he'll never hurt trees again.

[vegetamaker]

@NDFJay Very elegant solution! and very clear! Thanks for share it, I didn't know that option