Blueprint Macros vs Functions feels like an unnecessarily exposed abstraction

Such feature shouldn’t be ever considered by the C++ programmer as it would promote bad programming practices. Below I’ll try to explain why.

Blueprints already allow for doing bad things without ever letting you know that you’re doing something bad. You’re executing things that look innocent and ending with issues you’re not even aware of. Until you realize the terrible performance (framerate, memory, waste of development time, badly designed systems). This OK, blueprints are awesome for non-programmers and can be efficient, if… you know what you’re doing :wink:

  1. Functions and macros are different beings. AFAIK content of macro is actually copy-pasted into blueprint using it, making the graph bigger and longer to process. (please correct me, if I’m wrong on this). Functions in blueprints are never embedded into another graph.
  2. Functions and macros are different things and auto-converting anything from function to macros could cause bugs that you didn’t experience with function.
  3. Last but not least. Delay node is pure evil, there are used far too often making blueprint code quite difficult to read. And cannot be canceled. Actions separated by time should be often also separated functions/events. Otherwise, code gets really messy - it can cause bugs that are difficult to track and fix (requiring redesigning messy blueprints). That’s especially bad if the given blueprint is part of some system or feature. Blueprint A would still cause event although Blueprint B already canceled the action…
  4. I understand the convenience of using Delay nodes, but this node should be avoided. You could do an entire project without it.

So… proposed feature would promote bad programming practices: overusing Delays and blueprint macros. Non-technical people would simply assume this a good way of doing things.

2 Likes