Download

Professional Development Firefighter (Engine Learner's) first impressions and learning Unreal.

Hi,
Part of my job is to fly around the world to various developers, quickly learn their toolsets and help them raise the quality bar on their games. As such I’ve learned and used a ton of engines. I’m good at picking them up quickly. Somehow I’ve never needed to learn Unreal 4 before.

  1. I can do everything from modeling, FX, animation, to programming, so depth of systems hasn’t bothered me.
  2. I am new to C++ but as an expert in C# I went through C++ collage course work in a few days and have not found the C++ itself to be a barrier.
  3. I’ve gone though and learned every system in the documentation at a surface level.
  4. I’ve gone through almost every tutorial. I’m now recreating blueprint tutorials in C++ to ensure my total understanding of the engine before building my own small game project. Once that is done I’ll be ready to help a developer with their production.

So with the above in mind I wanted to give some feedback on my experience learning Unreal.
**
Overall:**

  • I’m extremely impressed with the tools. They are some of the best I’ve used in the industry. They are not as specialized as some of the proprietary engines (obviously) but are an amazingly polished and functional set of tools. I wont be able to fully judge the engine till shipping something with it, but my first impressions are extremely positive great.

  • Love the workflow.

  • The documentation and learning resources have a long way to go. Especially your API documentation. It reminds me of learning a proprietary engine. If I didn’t have experts in Unreal to help my learn I’d be having a lot of trouble.

  • The combination of sub-par API documentation, with the heavy use of macros (gross), and the lack of a scripting language makes learning the engine very difficult. There are a few reasons for this:

  • Its very hard to trace back through the code to see what the engine is doing before getting lost in Macro hell. (I do use VAssistX)

  • There is a fuzzy line between gameplay logic and engine stuff I probably don’t care about. This lowers accessibility dramatically.

  • The API documentation is nigh useless, even confusing at times with poorly written explanations.

As an example (not to start a Unity vs. Unreal thread, they are both good for different things, this is simply an example of solid easy to understand documentation to provide contrast.)
Awake In Unity -this document fully explains what Awake is, how it is used, and provides an example.

BeginPlay in Unreal - doesn’t explain when this is called relative to other things in the engine, or why I would use it.

PostInitProperties in Unreal - doesn’t provide any example of use, the sentence in remarks is actually confusing. “mainly this is to emulate some behavior of when the constructor was called after the properties were initialized.” what? Emulate some behavior of when the constructor was called?

I think the sentence is saying something like: “This is first event called after all actors have been created by the GameMode and before BeginPlay. While an actors constructor is called when the actor is created you can be sure that all actors that are initially created at startup by the game mode exist when PostInitProperites is called. As such you can use it to… ???” A graph like UWorld ->GameMode → Actors (constructors called on creation) → PostInitProperites → (other stuff) → BeginPlay would go a long way.

So all in all:
-I’m excited to use the engine, the tools are amazingly powerful, fast, and fun.

-I highly recommend a separate API documentation (or section) that eliminates all the deeper engine functions that will not be commonly referenced by gameplay code. I don’t want to filter this myself.

-I highly recommend spending some time writing API documents.

-I recommend having someone who doesn’t know the engine very well UR your tutorials and documents (not just the API documentation). You guys have a tendency to write like highly skilled engineers who have worked in the engine for a long time. (like a rocket scientist explaining the detailed process of how fire comes out the back of the engine to make thrust…do I need to know exactly how the fuel mixes with oxygen and all that? Probably not when I’m just trying to make the rocket go, I’m ok with that being magic. I just want to know that fire comes out the back of the engine creating thrust if I put in fuel and press the start button.) I think some UR would help prioritize what information is shared and how.

Really great work on this engine, It came along way from Unreal 3. Can’t wait to use it more!

P.s.
I needed a tutorial to delete a class. This process should be simplified.
https://www.youtube.com/watch?v=QiDbjmUjq5E

P.s.s.
I’ve started creating my own project now. I’m going to use this like a diary every time I hit something that feels like it could be improved.

-The process for moving or creating a folder in the C++ directory. Allowing the editor to create a “New Folder” would be great.

Oh wow, you have my dream job!

I can’t really add to much to this topic, but I agree completely with the quality of the documentation, I only program in BP but I find more often than not documentation looks like this Append | Unreal Engine Documentation (an example, but most docs on nodes are like this)

Not the greatest environment to learn the ‘Non Programmers’ language

In the four-five years I’ve been using UE4 now, this is by far my biggest point of contention; if you don’t use VAX, you often have absolutely no chance of backtracking through the code to work out what is actually going on (sometimes you’re still screwed when you’re using it). When you get to macros-within-macros-within macros, it’s really time to stop and reflect on what you’re doing and why you’re doing it.

Blueprint is the scripting language, and once you’ve gained a moderate level of familiarity, it works reasonably well. I often find myself implementing fairly hefty systems using it, and only backporting to native code for performance reasons later (I’ve seen people who are non-programmers doing things like procedural terrain generation and run-time modification using just blueprint scripting, and get it up and running in a fairly short period of time - something Unity wishes it provided the tools to support).

The problem with Blueprint is that it’s a debugging nightmare. There is no reasonable means through which to debug blueprints and the most effective method is often to statically do so using logs (yay, mid-90s game programming!).

This is very well put.

As I continue to learn Unreal one thing I’m discovering that is odd in a commercial engine, is tribal/ritualistic knowledge. I see this a lot when working at developers with proprietary engines, e.g. programmer 32 has no clue why x and y does z, just that it does and only if you set it up in a very specific way.

As I look through forums ect… I’m seeing the same ritualistic behaviors in the Unreal community and in the expert engineers at work. They often say something like “not sure why this works but if you set it up like this…”. I think this behavior would also be remedied by solid documentation that explained the desired behaviors.

My initial enthusiasm is being tempered a-bit as I’m forced to Ctrl - Shift -F on every function to figure out what it does. Sorry to hammer on this but its such a simple thing to fix and you have such great tools and such a solid core code base, I really hope you guys hire a tech writer.

Hi TheDogtoy,

Thanks for taking the time to provide this feedback. We definitely want to improve the state of the API reference (and Blueprint API reference) and hope to be able to put some plans into motion in the future that will remedy some of the issues you have mentioned. I know I have said this before on these forums so it may sound like lip service, but the engine is a large place and it will take time to address all of the things we want to do to improve the documentation in all areas. This one is certainly high on the list, though.

I’m not sure if you found these pages, but we do have some documents that show some of the logic flow for the game and Actors:

Order of execution is one of the most common questions, especially regarding the same event in different Actors, or how do you know when all Actors are guaranteed to exist. We already have a task to explain this sort of thing better.