Perhaps some real programmers can help me here. I’d like a more elegant way to handle a case where I want only one boolean to be true at a time, based on an enumerator.
For example, I have an enumerator here with three cases (but lets suppose its variable). And I have a number of booleans (lets also assume that may be a changing number.)
I can of course just set this up manually - for each branch from the Switch node, set the right boolean to be true and others false. But I think there is probably a way to set things up so that it should be handled automatically? Meaning all I would have to do is add or remove booleans from some sort of list, and the rest would be taken care of?
I suppose I need to associate each boolean somehow with each enumerator, but as long as I can do that, I should be able to solve this problem with just like a single loop.
You’ve stumbled into the downside of the boolean pattern.
When you want to ‘upgrade’ from boolean, and you don’t want to be able to do more than one at a time, the next level is to make the behavior depend on a enum, which I think you’ve basically done.
But if it gets much more complicated, and you have trouble figuring out when you can do what, then the stage after this is a behavior tree. Which, handily, Epic have made for you
I’d say if only one is ever true and there are absolutely no cases where more can be true, and you already have an enum, why not just use an Enum variable instead of bunch of bools?
in this case only one can ever be true, so i think the next post is best solution. however this gives me a better idea what the purpose of the behavior tree is. So far i think my system is too simple to warrant using a whole new toolset, but good to have in back of mind.
Actually, I did need to use bools rather than the enum, because I do need to have all turned off most of the time. With enum there is always one active.
I still wouldn’t call it perfect because it does require me to have to make a note to remember to update the select nodes if i am changing the enums, but at least it’s easier to read.
i considered that but it would complicate things more than just having the booleans. Cause i use those enumerators to have a move-to target at all times. I mean it can work either way but it was just less redesign things overall to add a couple booleans to be used by the animation blueprint.
I don’t know if this will help you or if it even still matters but maybe for the next guy.
In my checkpoint system all of them are bools and only one can be on, true, active at a time. So how I achieved it was to have some code that fires when a new checkpoint is reached that sets the book value for all checkpoints to false.
And what I think is cool is that my level start point is just the first active checkpoint in the scene. Which can now double as respawn for the pits. Or be turned off when another check point is reached. And I can even “remove” it from the check point stack (so the player doesn’t reactivate it by mistake) just by turning off the checkpoint collider so the player can’t reactive it / deactivate their current check point by mistake.
these days I have been using gameplay tags a lot more. I use them for storing state, similar to how you would use a boolean or enums, except that because you can put them in hierarchy that adds some flexibility.
It also makes blueprint code more readable because you can use switch and select statements from it. (need a plugin on the marketplace for the select nodes (worth it!))
