I had also tried to get into UE4 a couple times, and failed until I used found the following resources:

https://www.udemy.com/unrealcourse/learn/v4/overview - a bit slow, but there is tons of content

https://www.udemy.com/unrealmultiplayer/learn/v4/overview - building an online game with Unreal turned out to be stupid hard for me, and this has paved the way

https://www.youtube.com/channel/UCRnPBe1tJpXA0lccx_U1mww - UnrealGaimedev is amazing. I have so much thanks for his videos

With those, I have built some simple games. One of the things that I have found interesting is that the visual programming of UE4 can accomplish way more than I thought it was capable of. If you're getting started, I'd recommend not even touching C++ because the visual programming stuff is powerful enough for pretty much everything you would need in a hobby game.

I have been getting into Unreal the last few months and had the opposite experience.

I found the visual programming language frustrating to use and reason about. While I loved the discoverability of working with blueprints (it is easy to find new nodes), I found that actually working on game logic quickly devolved into an unmaintainable mess of literally, spaghetti code. It was great for prototyping, but horrible at actually building something maintainable and understandable. Reading other people's blueprint setup is even worse.

I found the workflow even more frustrating. Blueprints are stored as uasset binaries, and as such make traditional version control impossible. Changing a single default parameter in a blueprint rewrites the entire file, and can not be diffed, merged, or reviewed, making git/p4 log nearly useless.

I know there is a builtin diff/merge in the editor, but it's pretty limited and I would say it's quite a far cry from what "normal" developers are used to in other parts of the software world.

I have since switched to using mostly C++, and only using blueprints for derived Actors to set up art (meshes, materials, etc). It's definitely slower to set up than using the blueprints. I'm not happy about being back in a place where segfaults can happen; the compile-play-crash-restart cycle is much longer than it should be. I'm not a huge fan of C++, warts and all. In return, however, I can actually read the code, grep it, review it, etc. Do "all the things" you're supposed to do as a good software engineer. I really don't know how the AAA game studios are managing real games with blueprints, I kind of doubt they are.

At least as an experienced software developer but amateur game programmer, I found it much more comfortable to sit down with C++ and learn their API, than it was to perform game logic by dragging around 'foreach' boxes and doing arithmetic by crossing lines.

I was also frustrated with the poor git support by blueprints. I ended up just writing long commit messages so that I could read about what I (thought) I had changed

I think they could go a long way to fixing this by building a textual representation of blueprints. I can see art assets being unmergeable, but as far as I can tell there's no good reason why nodes, the netlist of connections, and their parameters couldn't be stored in text.

At least this would allow diff, merge, and code review with standard tools.

I've found the git support to be lacking. Every game studio I've known uses Perforce mostly because it handles lots of binary data much better. Because of the way games are developed, DCVS don't have as many benefits.

Perforce is great for binaries, but really kind of a substandard experience for code, at least compared to hg/git.

I also tried Git LFS and it is a hot mess.

I don't have much firsthand experience with Perforce. I've set it up, attached it to UE4 and just appended commits. I have been on the miserable side of git and binary data, LFS and other solutions seemed like awkward solutions.

Even ignoring the distributed aspect of git, the things I loved as a solo developer was immediate branching, a sane way of merging, and things being fast because there was no server to talk to (coming from SVN and CVS).

Now that I think more about it, I think some of the game studios I'm familiar with were using Git for the engine and artists were using Perforce for their assets.

Agreed on the visual programming system. I went into UE4 dev thinking I'd work mostly in C++, but now I'm basically only doing enough in C++ to get something exposed to blueprints so I can prototype faster.

Learn blueprint scripting. It takes a little getting used to but it's essential to being productive in UE4. Once you get the hang of it it's basically another scripting language. You can get a long way without writing any C++, and because it's faster, less error-prone, and has great auto-complete it makes it a lot easier to learn UE4's APIs while working in BP than in C++.

Besides that, read the docs and learn UE's concepts of actors, components, blueprints (prefabs), actor inheritance, pawns, and controllers. Then when you want to add some C++, make C++ base classes for your blueprint classes so you put some functionality in each.

Epic has great docs, this one might be a good place to start if you have Unity experience: https://docs.unrealengine.com/en-us/GettingStarted/FromUnity

fwiw, there is a C# for UE4 integration out there: https://mono-ue.github.io/ And I recall there being a JS one too but I don't have the URL handy.

Very interesting. Have you seen it used?

unreal-JS is by ncsoft (some billion-dollar company), so it should be pretty reliable!

though you can't use unreal-JS for iOS apps (uses v8)

I've been making an arpg as a solo project for ages (https://streamable.com/b9hae) and using the GameplayAbilities plugin that comes with the engine. I do the abilities (which tend to be heavy on delegates, so visual scripting is perfect for it), the UI, and the animation blueprints in BP, while everything else is cpp. I follow the model of creating all base classes in cpp, then having the final implementation as a data-only blueprint. This lets me rapidly change the values of things in BP in the editor when I'm fine tuning things, without having to deal with BP otherwise. So if I have a fireball spell for example, the fireball actor will have all its logic in cpp but the visuals, sounds, base damage, explosion radius etc. are all set in the editor in the bp, but the ability that lets me cast the fireball will be in pure bp.

I ran into the same issue and frustration you have in trying to learn UE4. I even started UECasts.com[1] to help bridge that gap for others.

I made a lot of getting started resources and cheatsheets to help newcomers such as a C++ Cheat Sheet[2] and a Blueprint Cheat Sheet[3].

[1] https://www.uecasts.com

[2] https://uecasts.com/resources/unreal-engine-c-plus-plus-chea...

[3] https://uecasts.com/resources/unreal-engine-blueprint-cheat-...