The deeper I get into any project I start running into an issue where I have statements that just require a ton of condition checks and I’m curious if there’s a better way to handle them. Basically, is there a better way to do something like this:
I suppose I could just have a canMove bool or something but that sounds just as, if not more so, tedious and sloppy because now I have to set and manage it everywhere too.
i think it is better to not make variables which just act to consolidate other variables because you’ll end up changing things and then it all becomes confusing fast. you get left with a lot of cruft.
I think its better to make a pure function which can be called something like “CanMove?” and then you can update the contents of it iteratively.
it may be worth considering if a state machine pattern could help make things more understandable.
this is blueprint code but demonstrates the idea:
i try to keep it so that i can debug from a top level where i can see entire execution flow in one graph. At this high level i dont want to have to translate any code at all, just read function/macro/collapsed graph names so its like reading a checklist.
I am using a state machine pattern where an enumerator stores the current state. You could determine state via conditions but then it can be a lot of trouble to ensure you are in the right state, whereas if we have it consolidated to an enum then can search references for enum and easily find all the points where state is changed.
(only reason to put a simple if/else branch into macro is just for blueprint readability. makes graph smaller so i can more readily view entire thing on one screen. but it also makes it a half second quicker to discern what is going on.)
within a function which outputs some condition - this way we can change how condition is determined a million times and it won’t build up too much cruft in the project. Also it keeps the problem space smaller so it feels easier to move around during debugging without becoming like a shark trying to catch one fish in a school of millions.
So you’re basically saying make a function that gets called and iterates through all the possibilities? Am I understanding that right? Like a “bool CanMove()”?
yeah, just as a way to consolidate your conditions so it can be read more legibly. and then if you need to change conditions that contribute to movement it is pretty easy to find the right place, compared to if you have loose condition checks all over your code.
Honestly, didn’t really think about how the issue is primarily organizational but it has to be because those checks/that information has to occur at some point somewhere.
yeah i think the main thing is just that you want to be able to find the problem spot quickly without having to memorize anything too specific, and then if you can view the problem spot in isolation that just makes things mentally more easy.
so if most or all condition checks are wrapped into functions that have a easy name to recall then it makes life easier in future. If you have a bug related to movement and you search “move” then the function appears and you didn’t have to remeber which exact variables are involved and all the places they are used. its all just in the one spot. so you can double check function, then if it is all good you can search where function is used in code and start expanding out from there.
At least this is how i am thinking about organization so far but it seems to keep me pretty productive with maintainable code for a solo developer.
My question was kind of spontaneous and random. I was working on something completely different and just had the thought that it was an improper way to handle the issue so figured I’d just throw the question out to get a different perspective. After your response I thought about it further and realized there’s no way around the need for those checks in some way, shape or form. Once framed as an organizational problem the options kinda become clear.
I also went down a bit of a state machine pattern rabbit hole. I don’t think it’s appropriate in this specific instance but gave me an idea for other problems in other projects.
