[=;488642]
First disappointment: Blueprints are limited in what they can do. the construction script cant spawn new actors. In coding, it is a common thing to have a class create an object member in its constructor. But BPs cant do that. So, complex actor building at designtime is not possible.
That’s a really bad programming practice. It’s good that Blueprints don’t allow you to do that: the sooner you get over this bad habit the better.
[=;488642]
Second disappointment: Some fucntionality is only available in certain places wothout any appearent reason. The most annoying limitatiosn are:
- Timelines are only possible in event graphs. Why cant functions or macros contain timelines. This would allow for simple animation functions instead of one messy graph
- Static meshes can not be created in components or macros. Again, this makes the procedural placement of items a hazzle.
- Some actor functions are only exposed “half-way”. i can set the horizontal alignment of the TextRender component, but not the vertical, etc.
These can be seen as annoying, yes, but they are in reality trivial things. Timelines are simple animations to do simple things, if you want to do some sophisticated animation layout (that’s the only need you should have of a function or macro to lead them) then it is much better to use Persona for that. Unreal engine is built around communication between many different aspects of the engine (much more so than others, as Unity) and you shouldn’t try to do everything in single classes (actually the less you do that, the better; this includes using parent/child relation, inheriting, interfaces, delegates etc. properly instead of spamming single classes with code).
Many of the bad comments here on Blueprints it seems to me come from people that don’t have much knowledge of game engines in the specific and programming in general. While Unreal tries to simplify things it is still a professional tool, much more sophisticated and powerful than the other publicly available counterparts (that are more used for mobile for a reason), but with this, naturally, comes also more difficulty of use for those that don’t understand the underlyings of the system properly and lack a solid background. There’s no way outside of it. A Photoshop will be, no matter what, always more difficult to use properly than a Paint, and a Maya more difficult to use properly than a Rhinoceros. The more things you can do, the more possibility you have of doing mistakes and then - as it always happens - blame the tools for it instead of yourself.
It has already been suggested before but if some of you have no knowledge of game engines and/or programming in games then it would be better to go in degrees: maybe learn to use Gamemaker at first, then dabble in Unity and finally come to Unreal. You can also learn everything from scratch by using Unreal, but you will have many more chances of doing mistakes and neither understanding what you are doing wrong in the process (and this, in turn, will create gaps in your knowledge that will bring bad habits, as the one of spawning actors in constructs). I myself don’t come from a game background in programming and I had to learn in steps. If I would have jumped to Unreal immediately without intermediate steps I would have never understood many of the things by reading them (and I had already knowledge in general programming prior).
[=;488642]
Another thing is refactoring. It is a real pain to move a variable declaration or a function with its implementation to a parent class.
One has to manually recreate the function in the base class, copy all nodes inside, delete the child class implementation, drag the inherited function in and reconnect all nodes.
That’s annoying, yes, but, sincerely, it should very seldomnly happen that you have to refactor functions or macros if you have a concept a priori (a thing that if you want to use Blueprints not just as a way of a “quick test for ideas” but for serious work) it should be necessary. If you find often in this situation then it means that you are, frankly, approaching your project in a very bad way and with bad practices. You should have at least a good idea of what your parent classes functionality has to be so that you don’t need to go back and forth consistently, at least not in the refactoring sense.
