Hey there @cl_fabula! Depending on how scalable and modular your game is, this could range from rough to totally fine. If all of these things MUST be checked/parsed every landing, and it’s not going to need any changes, then it’s not really too bad in my opinion. I would clean it up by changing the events to functions, making the function names the actual action for readability, and maybe a sequence node for ordering but since your action is all one logical chain this would also just be for readability and maintenance.
Oh i see, so i would create functions and place everything i have in my separated graphs in different functions and simply call theses functions after On_Landed ?
Its kinda hard to find a good workflow, at first i was simply collapsing my graphs to have a single view with all the collapsed graphs inside, then people told be that collapsing graph was bad and it would be better to create new sub-graph…
But now i realise that sub-graph are annoying to work with due to the simple fact that i can’t reorder them as i want in the list, i also have to do : right click → open in new tab everytime, its making the process of finding what i need pretty annoying.
Maybe functions are better for what i need, its hard to tell.
No worries! You’re going to run into differing opinions on what is “clean code” or “standard” in cases like this between individuals. This is compounded by the fact it’s a visual scripting medium, whereas this question is a “solved” one for C++ when trying to follow SOLID OOP principles, keeping things encapsulated and in their own functions is best, but with blueprints, things have intrinsic links and kind of force or simplify different paradigms.
One of the best reasons to make them functions as well, is that if you need any of these later they can be cleanly accessed separately from each other. Like making the speed check before impact something you can check for physics object damage, for example.
Functions are not unlike subgraphs, but they have their own place to live and can be called differently than events, which is nice to have in these situations. A subgraph for each event isn’t the worst case, but managing them is a bit more effort than functions. Though a subgraph to hold all of them if you wanted to keep them as events is decent for organization even if I personally don’t favor them. Every developer I’ve ever met works slightly differently in BP, while many follow the same principles. I wouldn’t get too hung up on the idea of perfect, if your workflow isn’t cumbersome and you can extend and maintain it cleanly, all the rest is preference.
