Is there a way to avoid a lot of if statements inside BP?

Well, I made a lot of gameplay logic but many times used the Branch node
Want to know alternative ways to make the same to decrease spaghetti effect
I will be very much appreciated it if someone will share their experience on that

Using switches can certainly help clean up your branch nodes. There are a bunch of default switch nodes, such as Switch on Int, Switch on String, Switch on Name, etc. Or you can make your own switches based off your own enumerators (create an Enum in your content browser, add new Enumerator on each line), then call it in your blueprint via Switch.

Hope this helps!

3 Likes

I like to use macros as much as possible. This helps keep the main flow and branches clean without all the complex tests and branch nodes scattered everywhere.


image

4 Likes

Macros are nice! They work with async nodes like timers and timelines. But reusing them doesn’t save on memory the way that using a function would (which you might want in the long run).
For unique effects, default to macro.
For async effects, use a macro.
For repeating, non-asynchronous, effects, use a function.

1 Like

IMO it depends on what you want to achieve and how you as a programmer are able to achieve it. Without a specific use case it might be hard to come up with an alternative to if… else / Branch node.

1 Like

Agree, just want to gather good ways to make my code more optimal.

From time to time I like to dive into leetcode.com and look for problems to solve. Found it to be a good way to try and find more than one solution to problems under tight performance budgets.

1 Like

A good rule of thumb is if you find yourself copy\pasting groups of nodes, it might be time to bottle it up into a macro or function.

The spider-webbing or spaghettiing of code is kind of a side effect of games. I’ve made more spaghetti in games than I have in apps.

Then again, if the spaghetti is really getting out of hand it might be a design foundation issue. Either the programmer is doing something fundamentally wrong or UE4 Blueprints really doesn’t cater to the programmers specific needs. No sweat, I’m frequently throwing a wrench into good design patterns :slight_smile: .

You could share a snippet of what you’re working on and we can try to help out.

3 Likes

Yes, since 3 or 4 months of development I started trying to do not copy/paste code, I learned how to use functions to make my code clearer, but sometimes have to make a lot of branch nodes and start thinking about this.
Tons of if statements :smile_cat:


I don’t think that some specific cases are so important in terms of this topic. I’m trying to gather some good practice or get pieces of advice on how it can be handled
For this moment I’m only once found where I can use the select node instead of using a huge chunk of branch nodes

Sometimes, the best way to clean something up, is to factor it into more, smaller, pieces.

Using interfaces, and collections of objects, and virtual functions, and world/collision/overlap queries, and event dispatchers, can all help.

For example: maybe there’s a bunch of lights that need to all turn themselves off when a generator is shut down. The lights could be given a reference to the generator when instantiated, and the generator could have a “power state changed” event dispatcher, and the lights would bind to the dispatcher in Begin Play or some similar place. Then, when the generator changes state, it would invoke the dispatcher, and each of the lights could change its own state accordingly.

Or the generator could do a world query (or radius query) for objects implementing an “OnPowerState” interface, and then call each of those objects when the state happens. This removes the need to register the objects, but it adds a potentially expensive object iterator query. Which, if the iteration is within a radius, and power state changes infrequently, may be fine, or, if you have lots of separate little objects, may cause an unacceptable frame hitch at the time of change. Only your own experimentation can find out which it is.

There are many different structure tools and they each solve problems of slightly different shape, so it’s impossible to say “always use solution X” – knowing which solution will work out best, is something you learn with experience.

1 Like