Thanks! I think it would also be useful to assign a kind of “stability” note for different parts of the engine. I know Epic is constantly adding new features to the engine and some internal APIs and systems get replaced. Stability note would help developers make decision if they should or should not rely on certain APIs. For example: “Stable” for parts that are not going to change in the near future, “Unstable” for parts where active work is going and “Obsolete” for systems that may be completely rewritten, replaced or removed. Any thoughts on that?
Speaking just for myself here, there are two major areas right now that are really dampening my spirits. One is trying to get up and running with the very base level connective tissue in C++. Things like loading levels, spawning actors, spawning and attaching components. Now I understand that UE is sort of designed for these things to be done in Blueprint not in code, so that may very well be the reason for the lack of documentation, but I feel that is a bit unfair. The choice should be ours, and in my case I wanted to do it in C++ because of this next item… which is Testing. Right now I am really bummed out on using UE4 for my own personal projects because I am finding it very hard to right unit tests for. I don’t like to do the “Unity vs Unreal” arguments, but here is one glaring area. Writing and executing tests in Unity is extremely simple. Dead simple. In Unreal, it is very hard, and a large part of that is due to documentation.
As a whole I feel it is ironically a lot easier to figure out how to connect the dots with code in Unity than in Unreal, which feels completely backwards to me since Unreal is open source and Unity is closed source with just a lighter scripting component, but that is how it feels. I don’t think that is true just how I perceive it and I think that is because of documentation. The C++ side of the docs right now are just really, really lacking IMHO.
<----Noobiest Game Developer ever (Actually, let’s not even call myself that yet, until I ship something), so Noobiest, still in-school, learning UE4 and Game Dev student…that’s sound better:)
So let me give you all my view on this: In school, we are given a very “basic” course on UE4 and that’s only after a very basic programming class that is a requirement. Before that, I learned a bit of C++/C for a Computer Engineering degree. So I knew some basic terms before my class, and during the class, I got a nice refresher in OOP. But, it was hard, very very hard when I cracked open UE4. And while it’s getting easier 6 months later, I will tell you, I agree with the guys saying that documentation is lacking or outdated. A LOT of the awesome nodes that I would consider advanced, or not even advanced nodes, are poorly documented. Or examples just don’t make sense.
And also like someone said before, I understand that the groundwork of this Engine is based on UT, so FPS are the “main” focus, but I also understand that there are workarounds to making things happen. And I am sure that future releases will include better options to make other genres easier to develop for. But, it’s hard, if I wanted to make an FPS “exploration game” or “shooter” or whatever FPS, or platformer, calling up events would be easy. But if I wanted to do something like a turn based game, that’s going to be out of my league for quite some time via Blueprints as an amateur “programmer”. Blueprints is definitely great though, especially with the awesomeness of Epic’s examples and the community’s Epicness (see what I did there?), it’s a great stepping stone to doing something in the Engine. But is still requires A LOT of programming knowledge to take full advantage of.
If/when Epic can “break” that barrier, with the further development of Blueprints, I can see many many many great things in the future. Of course, it’ll never get to the level of C++ programmers (which I’m relearning on the side, Stroustrup’s Programming Principles and Practice Using C++ is quite the page turned I tell you…) which will want to keep their jobs:)
TLDR;
Blueprints is great for amateur/non-programmers to get their feet wet in the Engine, but it’s not going to replace traditional programmers for anything remotely advanced in gameplay but, with clearer documentation on everything, proper 0-100 tutorials/live streams on gameplay examples (I am looking at you Turn Based game example), I think we would see much more out of the community.
My 2 cents.
Blueprints are for coding, just like any other scripting language. It’s not really any harder or any easier if you can do the same and follow the same logic path, it’s not for N00B’s or Amateurs to get their feet wet as some have made impressive games BP only. As you can code your own BP’s it’s extendibility is limitless as well, so I really don’t agree…
But of course, if Epic want more people to use their engine I agree. Having more “basic examples” in C++ and working their way up is never a bad thing BUT!.. Some of the examples are there if you want to find them: UGameplayStatics::OpenLevel | Unreal Engine 5.2 Documentation
They also give you great examples like the quake like demo thingy, which has both C++ and Blueprints you can reverse engineer. As much as I encourage Epic to simplify and explain in detail whenever they can. I also expect that I meet them in the middle and do plenty of research myself…
Then if I get completely confused, ask on the forums / answerhub. I’ve been doing this a fair while, even though I’ll admit I don’t understand how UE’s API works I also don’t expect to get stuck on silly little things for days or weeks either if said process can be achieved without pain in a competitors engine. In that instance there’s something difficult for the sake of it…
For the most part, everything has been pretty straight forward so far…
For me networking was really painful for almost two weeks, but than at some point i just get it and it works from that point, i get it right or not, it works as intended or not, i don’t know, but at least i have a result. (blueprints as non programmer)
Some current, important things to me:
• Clarification on Build system docs would be nice, as another user stated.
• Some info on low-level networking. As said before, UE4 is room-based. An overview of sorts on the best way to delegate, or override the network driver to allow default client-side functionality to be sent off to custom servers. Same sort of info on spinning a custom UE4-based server from a low-level standpoint.
• There seems to be confusion regarding which classes are run in a client environment, and which are run in a server environment. An overview of the separation between the two would be helpful.
• An overview of the architecture behind the scenes in both the Editor and Standalone game. I’d love to know the relationship my game module has with the engine. I’ve been porting a mod system I’ve been working on to UE4 and it’s been a long trial-and-error process for getting the plugin system injected at the right point when the Engine is starting up, without killing the editor and allowing PIE to work fine. It works for me right now, but because there are some issues that don’t coincide with the docs right now, I’d like to know my options.
I’m just jumping in here, from a different perspective.
I am a senior programmer, what 30 years now? Man. I was working on an indy Multiplayer game and used 3 different engines over the years. Irrlicht, Ogre and C4. The C4 engine was the most promising one because it had an editor and stuff. But it quickly turned into a nightmare because the editor was unusable, the import pipeline was broken, and getting assets into it was a gamble. I ended up writing my own converters using 3DS as my level and object editor. It was bad, believe me.
Unreal helps a great deal with the art pipeline and the organization of assets. I agree that it would be nice to have a setup where my program provides the EXE and UNreal is a library that I call. That’s how it should be when you write a program in C++ . I also agree that there must be more tutorial material and documentation to make the C++ interface usable for anybody who does not want to spend a year fulltime studying source code. I don’t study source code. The C4 engine had hardly any documentation and whenever you asked a question the answer was “read the sourcecode”. I don’t do that. I use only software that is documented because my time is too valuable to read source code. Probably comes with age.
So Blueprint is a godsend for me. I can make the client in Blueprint, the right click/intellisense thingy helps me to figure out things I dont know anything about, because I often just type some guess words and then get a list of fitting things that allow me then to research them and find out what I need. I sue C++ more like an under-the-hud thing to interface to the network library I use but otherwise stay away from it. I would use it more if I could, but like I sad, lack of documentation is a gamebraker for me.
If I could make a whish, I would make it so that the editor can be used for the whole import part and organizing assets and that there was a second form of Unreal that can be linked as a DLL or so. And of course documentation.
Yes, but see (And Epic: see) this is the folly that leads to downfall. Like I said, I was with the C4 engine for 2 years or more. it was the typical 1 man 1000$ engine. The man who did it was good at what he did. He was a mathematician and the 3D rendering part was really good. His problem was that he too played the game of “gotta churn out new features faster than my competition”. Of course he lost to Epic because he was only 1 man, but what made me want to leave his engine long before was the lack of documentation. Of course he also had an ego problem and got really mad at me when I complained about the bad documentation, luckily that’s not the case here at Epic, but my point is: What good are features when nobody knows how to use them?
Epic is waht, 50, 100 people or so? I mean in the videos they have “tutorial content engineers” and stuff. Set a few people aside that do nothing but write documentation! Write a book that explains how the components of the engine work, what they do, WHY I should use them and what I can do with them!
The documentation reads like a physics book that explains exactly the electromagnetic features of subatomic particles. You may understand what a Quark is and how it interacts with its environment, but that doesn’t give you the capability to brew a good Whiskey. That’s the problem with the C++ documentation. It doesn’t allow one to actually use their SDK.
If there was a good manual of how to use this engine’s SDK I guarantee, people would flock here in legions from other engines.