[Feedback] One MAJOR mistake with C++ for Epic devs

General Feedback & Requests
1

I hope Epic dev’s will read this, I don’t want to hurt anybody, this is just an opinion.

You guys make a major mistake confound engine devs with game devs/users. Since you give us the sources, you expect from game devs or engine users, to know the engine with all internal stuff and details. But this is a mistake. Sure, Epic devs, are so familiar with the engine from years of working on it, but a new user have no time to learn and understand all stuff you did and why for years. The engine do not have an easy and logic “front API”.

Example:
Fallow this https://forums.unrealengine.com/showthread.php?56484-Twitch-Training-Stream-Extending-the-Editor-Jan-20th-2015 and watch the video.

This is just insane. Nobody expect this from and API, especially UI.

My answer was (copy&paste):
"Honestly, extending the editor is complicate and will drive many peoples back. Most peoples when comes to a new UI expect to add a toolbar button some how like that:

GetToolbar(name)->Addbutton(where, icon, callback);

and probable same way with a menu item, without needing to know in depth details about the internal framework."

And probable Michael got offender because I do not like his tutorial. I am sorry for that, was not my intention to offend anybody, I just to say something is wrong.

By design, this is not good, except maybe for speed, but this is again disputable, because there is a use of C++ template and inline, with out going into premature optimization. Intellisense is most of the time useless, because there is no way to get what data you need from it, you need to know in depth the mechanic what drives the data and structures. And this is not a good design also, users should get minimal API deprecation over time, rest of internal stuff can change daily.

Also, read what this guy said, I have to agree with him:

Thanks for reading.

2

I’m just going to say this, you are using a AAA engine. A professional level API, designed by professionals for their professionals.

Just because you have the source doesn’t mean they expect you to dive in over your head to know every internal engine feature. That’s just ridiculous.

The beta testers, myself included were required to use c++ with the same API with zero documentation and we got around it just fine. That might be unfair to say but we were all new to it too and we didn’t have a fraction of the resources you guys have now. We had to paddle our canoes up a mountainous stream, fighting the understanding of the api and continuous drastic api changes.

With an engine of this size and scope, there will never be an “easy front api” when it comes to C++. In fact it’s already easy enough. I’d also add that with UE4 API it is far easier than the Standard Template Library that comes with C++ from the ISO. I use the STL on a daily basis for work and if you asked me or any of my coworkers who use the only the STL, we would all tell you that UE4’s API is FAR easier to use and understand than the C++ STL. Have you ever tried to make your own portable game engine and platform agnostic UI in C++ ? I have and let me tell you this, it’s not easy, nor is there a way to make it any easier than it already is. Epic Games has done a fantastic job. They have gone up and above the call creating an “assisted” c++ environment. There has been so much done for you it is insane. This is by far the easiest AAA API i have ever laid eyes on. Ever look at Cryengine 3’s C++ code? Your eyes will bleed from the complexity and your heart will sink from the lack of documentation.

It’s not insane. Being brutally honest…I expected Slate to be far more complex. This is a common approach to professionally developed UIs especially platform agnostic ones like Slate. It is in declarative syntax and uses composition. If you don’t know what declarative and composition are, you shouldn’t be using slate in my honest opinion.

I guess this isn’t fair for me to chime in on because I’ve been working with UE4 for almost two years now, and been programming in c++ for more than half of my life, and i may subconsciously expect other people to know a plethora of knowledge but i stand by what i said.

3

I really know what I am using mate, no need to argue about that.

The complexity of the code have nothing to do with simplicity of use. Are 2 different things. If you look at BOOST you get what I mean. Keep it as simple as stupid is always true.

4

First of all, ditch Intellisense and get Visual Assist. If anybody is going to make a complaint about the engine API, they should have tried Visual Assist first. It will help you more than I can describe in this post.

I don’t really think there’s an argument to be made over this to be honest, one way or another you’re going to have to learn the engine API to be able to do anything with it, regardless of what functions are/aren’t called. You can’t really expect it to follow any kind of form, especially when hundreds of programmers have contributed millions of lines of code since pre-1999 (some of which still exists!). Learning the API is a natural part of the pipeline, changing it at this stage would cause considerably more harm than good, and would subsequently irritate developers that have been using it a long time, who would see the change as pointless.

I didn’t know anything about C++ this time last year, literally nothing. Now I’m quite happy doing Multiplayer, Physics, Engine-Level stuff etc, and all the experience I have is purely down to what I have taught myself this year alone - thanks to the simplicity of use in Unreal Engine. IMO, the engine makes everything ten timers easier if anything.

5

Have to agree with Jamsh.
I tried to code C++ for CryEngine 3 and it didn’t worked out, everything there was a mess. Just trying to decipher the examples was a pain in the ***. And let’s not forget the lack of documentation. Hell how long did we asked Crytek to finally write one? As far as I heard it’s still not complete, but don’t quote me on that, I haven’t used the CryEngine since UE4.
Now with UE4 everything seems so simple (more or less ^^). I still haven’t gone further than I needed yet (so basically no engine level stuff), but just reading the UE4 code is pleasant and understanding what you need to do isn’t that hard. Epic did a very good job on this front and the community does the rest.

Btw: Jamsh, thanks for the tip with Visual Assist, it’s really neat ^^

6

I couldn’t have said it better.

7

I code C# daily, but never touched C++ or UE4 before last week. I must say UE4 as a AAA game engine is rather easy to learn. There are tons of good examples/references and the API is not that hard to understand. Stuff is also pretty consistent throughout the API, so you learn rather quickly where to expect what.

I have problems with VS2013’s lack of good intellisense in C++. But that is not Epic’s fault, and I might try to fix that by trying Visual Assist.

Bonus: Since Blueprint stuff is just “tagget” c++ stuff you can always right click a blueprint node and click “Go to definition” and open up the file in Visual Studio. This is not only awesome, but it makes it easy to transfer knowledge between C++ and blueprint stuff.

I never expected to get as far as I’ve gotten when I clicked the “Download UE4” link last week. It’s awesome! :smiley:

8

Hi TDoro,

The approachability of editor extensibility is not where we want it to be yet. Things like menu extenders are functional but not very intuitive to use, and a number of editors just don’t have the necessary hooks in place right now. The process for improving this is mostly iterative, as we work on new systems we try to design them with extensibility in mind, but existing systems that haven’t been touched in a while need to be revisited. Pull requests to improve things are always welcome :slight_smile:

I’ve got the sketch of an idea to use reflection markup to make it much easier to do simple sorts of extensions, but I haven’t had time to look at implementing it (there’s always something more pressing on Epic Fridays). My goal would be to distill things down to be as simple as something like this:


class UMyBlueprintMenuExtension : public UBlueprintEditorExtender
{
public:
	// Arranges the selected nodes in a line, starting with the left-most node
	UFUNCTION(meta=(DisplayName="Align Selected Nodes", ShowInContextMenu="Node Actions", MenuVisibility=IsAlignSelectedNodesVisible))
	void AlignSelectedNodes(UBlueprintEditorContext* Context);
	
	UFUNCTION()
	bool IsAlignSelectedNodesVisible() const;
};

Obviously the exact syntax would be different, and I’m not sure how ‘standardized’ to go; it’s a tradeoff between being able to apply it to every editor quickly/learn once and apply anywhere, versus better tailoring it per-editor to reduce the hoops you might jump thru to get very specific context information like the node selection set or mouse cursor position (for node drops).

Cheers,
Michael Noland