Everything is too complicated and too inconsistent

[MaxiHori]

I’m a professional developer and I’ve been using this engine for 6 months now.

This is really the best looking engine ever with an amazing effects system and great designer tools.
It is been made to easily add new contents but it is more a set of great designer tools than an engine, sometimes I feel like I’m using an Adobe pack.

There is no clear pattern or guideline to follow, not in documentation and not even in the engine itself.
The only guide that I found was “first use brush, then static mesh, then refine”.

There are too many ways to achieve the same results and it is not clear which is the best approach to use.
Just think of spawning a pawn and make it move forward, If I can think of more than 10 ways of doing that, something is wrong.

There are too many incomplete components.
Sometimes you expect a feature,
for example there is a draw sphere and an overlapping actors sphere, but there is draw cone without an overlapping actors cone!
And sometimes they are just incomplete, like PawnSensing that has just one event that fire when it sees someone, just that.
There is no “not seeing anymore event”, you can’t fire it manually so it can’t replace overlapping sphere,
and you can’t use the cone area to do anything at all.
And now with the new Behaviour Tree it is even more useless since you can’t combine those 2 features together.

The Behaviour Tree it is even more absurd since it is a simple state machine and the state machine is the most basic form of coding, but still I find easier to
write all the AI logic from scratch than using that.
The blackboard is it even more strange to use, it is just weird.

There are many errors that should be fired at compile stage,
for example if you add an input movement to something that does not have a movement components it will not work but it will not fire any errors.
AnswerHub is filled with perfectly compiled code that don’t work just for similar problems that could be easily solved throwing an error at compile stage.
Sometimes I feel like there is a big try/catch everywhere.

There are new features that have been added without being designed first,
for example hud widgets are not clear on how they should be used (and you can even read developers in this forum telling you that),
should there be a main container? Should the main container be a widget itself? It is better to just add multiple widgets to the character itself? What happen to the old draw hud method? how those features lives together?
And even simple things like padding, margin or borders are things that takes too much time to do.
You can create incredible things as 3D widget but HUD widgets are far worst than the oldest HTML.

the official documentation is lacky,
for example there are no guideline on how to use event-graphs, most of the examples are not explained, not even in video-tutorials or in step-by-step tutorials,
they are just a copy-past of working code.
Quite often code could be made far easier and there are only examples on really basic stuff or extremely specific stuff, but not for common actions. Once again, AnswerHub is filled with the most basic questions.

Basically this seems to me like a bunch of useful tools and features, they are really amazing but they do not live together in harmony.
Everytime I have to combine 2 features to get something else it is a nightmare.
It is not a framework to me, it is fine to use it in the boundaries of the templates that you created, but nothing more.
Now please consider that I spent time writing this feedback, so I’m not a hater or a fanboy or whatever, I really think that there is a lot of potencial here,
but I can’t stand the frustration that I get from using it.
I think that you should stop rushing to implement new features and redesign what is already present. It must be made more fluid to use.

[Havoc]

Have you watched the official videos? There are quite a few of them on YouTube, and they cover the majority of what it seems you’re looking for. There are many, many included content examples, which a lot of developers have taken as an example of “best practices” within UE4.

One thing that stands out specifically with your given examples: “Just think of spawning a pawn and make it move forward, If I can think of more than 10 ways of doing that, something is wrong.” Epic has made Unreal super flexible, and this shouldn’t be seen as a weakness, but as a strength - there are many different ways you can do something, and it’s up to you on how you’d like to implement it, but again, they cover most of the “basic stuff” (even most of the questions that are posed on AnswerHub…) in their ongoing YouTube videos.

That being said, there are some difficulties, and developing can just be frustrating in general. Unreal has a great community, though, so you shouldn’t hesitate to post if you’ve got any questions on how to tackle something in specific. A lot of us here just want to help

It sounds like most of your concerns are tied to specific issues with specific mechanics you’re trying to implement, and I’d be happy to help if at all possible - just shoot me a PM or make a post on AnswerHub.

[jonimake]

@MaxiHori;265253

The Behaviour Tree it is even more absurd since it is a simple state machine and the state machine is the most basic form of coding, but still I find easier to
write all the AI logic from scratch than using that.
The blackboard is it even more strange to use, it is just weird.

Behaviour trees sure aren’t simple state machines.
State machines can only have one active state. With behaviour trees you can be in multiple states at the same time, running parallel tasks.
State machines also don’t store information at all. With behaviour trees and blackboards (I guess the blackboard name refers to this Blackboard system - Wikipedia ) you can store data about past events, which is simply impossible with finite state machines. Also with FSMs you’ll quickly run into problems with many states, you’ll have really hard time managing state transitions from all possible states to every next possible state. I find this is much more manageable with behaviour trees.

[HHunter]

Hey Maxi, I think your being way to black and white. The reason unreal has so many ways to do stuff is because some ways are better than others for certain things… Of course there 10 different ways to move something. That doesn’t mean each one is the best at a specific thing. There tons of overlap because it a engine designed to do and be many things. For example if I wanna make a physic based space game like star citizen. I wouldn’t make my movement or collisions detection the same way I would for a fps or even a fighting game or a top down. I can think of well over 10 ways to do any task in unreal and they all have pro’s and con’s.

Alot of people are happy to have it this way because not everyone making the same thing. Infact alot of people felt limited in UDk because there was only a few ways to do things and not always the best way at least in kismet. I know in most cases if you are a developer that been in the game industry for many years you would know there specific engines designed to do certain things well and unreal trying to bridge the game and do everything decent to good. For example in UDK or ue3 you would of been hard press to make a non fps/tps in it. Without alot of rework. In ue4 everything about the same difficulty and thats great. So I think when you look at unreal 4 more realize it not designed for 1 genre or 1 type of game but for many and imagine why some of those methods exist. In anything there 100’s of ways to do the same thing doesn’t mean one the most effective.

[anonymous_user_7ef7f636]

I think this is more a matter of “Epic’s way of thinking is very different from my way of thinking” than anything inherently wrong in UE4. Personally, I think UE4 is very easy to use. I see a consistency and logic in most things.
Regarding the " If I can think of more than 10 ways of doing that, something is wrong" your reasoning is very backwards however. As someone else wrote in this thread, that’s more a strength than a weakness.

[anonymous_user_6f48ddab]

Hey Maxi!

Don’t be discouraged and keep at it. The most difficult thing about unreal is just getting used to the patterns that are at play here. I can see scenarios where too many ways to do the same thing could be frustrating but I honestly think this is a huge benefit. One thing that drives me absolutely insane in other commercial game engines is that there is generally two common things that happen during design of the engine that become obstacles in advanced scenarios.

**1**:  An engine will be built in a very generalized way so that it can be used for as many possible game types/patterns as possible. This can enforce frustrating limits if feature implementations get too non-specific, usually in the form of the engine trying to do everything for you and leaving no possibility for customizing the internal details of things.

**2**: An engine will evolve from a studios successful game series and be very very tightly coupled to that games feature set and patterns. Basically you end up with an engine that was intended for use "x" but fitted to be also good for use "y" and "z".

Looking at game engine design in that way, I’m sure you can imagine a whole world of limitations that be enough to break the spirits of even the most hardened developers.

Epic, while inevitably having some tendencies from both categories above, has done a terrific job trying to avoid those pitfalls typical to other game engines within Unreal Engine 4. They are doing their best to keep the engine “game-type agnostic”, which is why you will find that there are several ways to achieve similar end-results quite often. Sometimes this will mean that there won’t be a super simple, straight forward way to do things that we view as typically simple and trivial. The upside to this is that it avoids the typical closed-implementation horrors that we find in other game engines when we want to customize how very specific things are done, or even entire systems for that matter. Of course there are certain hard-coded limitations that are imposed (typically they are things from the heart of the engine relating to reflection or auto-generated header content, etc) but I’ve noticed that Epic continually revisits these issues and is slowly removing limitations and/or adding support for more fluid design patterns. Perfect example is the improvements to c++ code support, FObjectInitializer reliance is almost completely gone, more natural syntax is slowly coming into the fold.

I’ve definitely had my moments where I wished I could just take the graphics pipeline and ditch everything else lol, but cooler heads prevail each time and I’m usually able to find an acceptable solution or workaround for problems.

As for the problems with documentation, this is just something that is going to take some patience. It’s an enormous code-base and it’s updated regularly which is making it difficult to keep up with understandably. Epic really has seemed to put improving documentation much higher on the priority list lately though and it’s showing (thanks guys and gals!). There is still some pretty important stuff that lacks documentation but if it’s something high priority for you, make use of the forums, answerhub, and don’t forget the IRC channel on freenode #unrealengine to appeal to the community. You’ll even catch some of Epic’s peeps lurking in IRC on occasion where you can get some real-time convos with them about problems with your code. Personally, I’ve found that digging through the engine source often helps me find solutions. Although I will say this to Epic in regards to documentation: Document everything in code as you go please. Everything! I know its a pain sometimes and can slow things down but even those little template methods that you might think get overlooked don’t.

Just keep at it Maxi and don’t let those frustrations drive you away. With UE4 you are in good hands. I’ve had the engine since the end of October now, and my first 4 months I intentionally spent studying the engine’s documentation, it’s source and doing lot’s and lot’s of little experiments and tests to make sure I understand the aspects of the engine that relate to my planned project. I even discovered a way to use ALL of the scalar types (int16, uint16, uint32, uint64, etc.) within blueprints from a plugin I made that doesn’t even modify the engines source! lol The Epic Dev that noticed I had done this even seemed baffled. Just keep at it, study and be patient.

[Shadowriver]

There are many errors that should be fired at compile stage,
for example if you add an input movement to something that does not have a movement components it will not work but it will not fire any errors.
AnswerHub is filled with perfectly compiled code that don’t work just for similar problems that could be easily solved throwing an error at compile stage.
Sometimes I feel like there is a big try/catch everywhere.

Problem is components can be destroyed and created dynamically and compiler can’t check if component will ever exist it assumes it will exist considering you using it, thats why best practic is to always check if component exist, you should always check pointers if theres no guaranty that they always exist.

What happen to the old draw hud method? how those features lives together?

It’s simple it will exist until they be told that it’s deprecated (but i think it won’t, canvas is always a option) and long they are not you can use them if you wish, thats normal for any code base.

the official documentation is lacky,
for example there are no guideline on how to use event-graphs, most of the examples are not explained, not even in video-tutorials or in step-by-step tutorials,
they are just a copy-past of working code.
Quite often code could be made far easier and there are only examples on really basic stuff or extremely specific stuff, but not for common actions. Once again, AnswerHub is filled with the most basic questions.

AnswerHub is filled with the most basic question not because there lack documentations, but people lacking experience and they usually lack ability to search for information, sometimes they too shy to try something fearing they doing something wrong regardless of fact that it works. In AnwserHub i usually don’t answer questions… i find answers for them, that litterly what i’m doing, i shere my ability to figure out things and actually it’s a learning experience for me too, because other people problem becomes my problem and i trying to solve it and i take experience from it, sometimes simply find answer in documentation. But then again if i can do it… so do others.

So i think people instead of searching for tutorials to how to do very specific things, should learn about fundamentals and learn how to use them by themselves how to those specific things. Programming requires thinking out of the box, it requires thinking for yourself not others, thats what will give you a edge and thats what people should be though about. This is not Ruby on Rails where your brain is latterly railed by conventions and you can’t go even step outside of them.

[anonymous_user_8784b148]

I actually have to agree with OP in almost all points.

The only reason why everybody ( just my guess) is accepting everything as it is, is because Epic told us from start this is a beta wip and nothing is final. So, basically, we are waiting for stuff to be fixed or added or improved.

[unit23]

@MaxiHori;265253

The Behaviour Tree it is even more absurd since it is a simple state machine and the state machine is the most basic form of coding, but still I find easier to
write all the AI logic from scratch than using that.

You need like 5 scripts to get a Behavior Tree to even run.

All the stuff which is small, like interfaces, or lists should be located in related nodes, all this BT stuff could be located in one instance, one place. With the current implementation, you have to check several files to test things, or find an error, this makes things more time consuming and more prone to error. This is especially complicated because AI behavior is often not clearly visible,

And then while working with BT, because i work on AI, i have suddenly go into some panel setting somewhere else to set avoidance of AI … ? A single option, somewhere else, where AI is developed.

Why not keep AI settings in one place?

Basically, for work flow satisfaction, design things like “Move to” nodes in a way so that you can just enter destinations and then just tick the AI option to patrol between those points. Simultaneously, the Behavior Tree panel gets updated with the AI patrol node, this is translated, visualized and adjusts accordingly on the BT. You have to sync the behavior. Currently I’m unsure if i want to use BT, or why exactly. Using only nodes, i have everything inside the BP panel, why should i start messing with BT?

Imho, topology of UE is somewhat messy, could be much more streamlined, sophisticated - optimized for fast prototyping.

[iniside]

I actually have to agree with OP in almost all points.

The only reason why everybody ( just my guess) is accepting everything as it is, is because Epic told us from start this is a beta wip and nothing is final. So, basically, we are waiting for stuff to be fixed or added or improved.

I accept it because I really think it’s good.

You might not notice it in small project, but the bigger you get, the more you realize, that everything here is to help you, not make your life harder.

And what is actually good for beginners, unreal enforces several conventions on how you should write your code, from the start. And if you fallow them, things are easier, and really hard to screw up.

[zoombapup]

Just want to chime in regarding the AI stuff. To be honest, the BT system that UE uses is pretty much “industry standard” right now. So yes, its a bit confusing if you don’t know what you’re doing or haven’t got a lot of experience in AI work, but otherwise it pretty much matches the toolsets of the other engines out there.

Thats not to say things can’t and shouldn’t be improved, I’m just noting that for the most part things are as you should expect out there in AAA land. I.e. its built for experienced developers to use, so it favours complexity maybe more than it should for new users. Stuff like “requiring 5 parts to get an AI working” is actually kind of normal. The only reason you have something simpler in other engines is because someone built a black box for you to use and made it all simple. In reality under the hood of that black box, are likely exactly the same parts.

Behavior Tree + Blackboards are currently what the majority of AAA devs use. Admittedly some things could use some UI and usability improvements. But the guys are doing a good job with limited resources in this area at least. New AIPerception component should fix a lot of the problems with getting things sensed (PawnSensing was an old system that is going to get deprecated I would think). I’ll be posting a tutorial on how to use the AI Perception system, some of the new AI debugging stuff and the EQS alongside it all soon.

Yes its complicated. But its powerful too.

[anonymous_user_5d9b5a3e1 (anonymous_user_5d9b5a3e)]

I actually have to agree with OP in almost all points.

The only reason why everybody ( just my guess) is accepting everything as it is, is because Epic told us from start this is a beta wip and nothing is final. So, basically, we are waiting for stuff to be fixed or added or improved.

I agree with this statement, which agrees with the OP (lol)
UE4 is quite a big leap forward, bringing tons of power to the people, but that doesn’t mean it’s without flaws. That’s the entire point of the feedback category of the forum, to help make UE4 even better. Feedback like his seems essential
Telling the OP how to “work around” existing issues doesn’t fix them, and pretending as though issues don’t exist is even worse, in my opinion. It’s okay to be critical of the things you loveeee In fact, that’s proof that you love something.

Anyway, it sounds like he’s trying to express that things need to more intuitive, and if they’re NOT intuitive there should be documentation that explains how to use something or the purpose of something. (Ex. Black Board and the Behavior Tree)
Also, I think he’s saying that there are tutorials, sure, but they don’t give you a fundamentally-sound view of things like Blueprint, and I definitely agree. The tutorials are just saying “Do this, and do that” without explaining how things actually work, so you arent developing a fundamental understanding of Blueprint, you are just remembering some steps and applying those steps to similar tasks.

So yeah, I do feel like people (especially artists or anyone who isnt familiar with programming concepts) will be left in the dark, and I would personally love if Epic would explain things more thoroughly, but how much training can we really expect Epic to provide? Perhaps making the engine more intuitive is the way to go.

[Extwokay]

The YouTube tutorials are awful nobody actually knows how to make a tutorial just a bunch of heavy breathing they don’t explain anything

[IceWater91]

but it does not tell us the basic steps, or why we do certain things ion certain blueprints, or whivch blueprint we are even supposed to be working in . because the third person blueprint for the character alreadt has the three nodes that you start with connected to stuff. and we cannot make multiple of the red starting niodes.

[IceWater91]

but all the tutorials skip over necessary things