wow I can’t believe this thread is still going on, Unreal is simply better than Unity, deal with it. Of course it has defects, it’s unoptimized but I think in time this can be improved, like the cache it is eating, eating drive space and sometimes it can be non responsive because it loads up ram and never gives it back, but per general it produces better realism. I haven’t even tried yet, but building the engine from source and adding anything you like, and the fact that it has native code running on it, running on the same type of code it was constructed because it’s a modular structure, it’s just modules.
Yupp, I feel your pain. For me it is not even the C++ or the documentation part, its the DX in general. After years of Unity, its a lot of pain in the rear. Visual Studio code hinting is super slow (2022), of course, vs 2022 is not supported out of the box, I had to reinstall like 3 times, with plugins that wasn’t mentioned required, but looks like they are.
Live coding is not live at all, clicking a 10x10px icon all the time is a lot of fun, Unreal macros are screwing the linting over and over again, and every 10-20 minutes i have to restart UE because it keep forgeting to react to code changes (specially in BP-s). Save, close everything, “Regenerate VS files”, open everything, compile, and hope for the best. Minutes out of the window. There is always something that tries to sabotage me - at least it feels like.
Unity be like: change code, save → see result, check. I don’t understand 
What did I mess up with my setup? Or is everybody feels like this? I mean even in the tutorials the teacher had to regenerate files from time to time. UE devs live with this? Tell me whyyyyyy
2 Likes
Got sick of Visual Studio hanging all the time, either due to a Perforce query, performing a search or because the day ended in Y.
Ditched Visual Studio and Windows for Fedora 36 and Rider.
Not perfect, but over all, a far more enjoyable experience then VS ever was, even with the Visual Assist extension.
Gave up on live coding ages ago, so just didn’t bother trying with Rider.
Out of curiosity, I did a quick search related to Rider and live coding with Unreal.
Found this:
May have to give it a go.
1 Like
Live coding works fine, and from what I’ve heard in 5.x, the limitations that were involved with it in 4.x are mostly gone.
VS2022 works fine with it, and is much, much faster than previous editions, just make sure you select VS2022 as your editor specifically before regenerating the project in the editor, don’t just select Visual Studio, make sure it’s set for 2022, as that sets up the project in a way that 2022 can be more efficient with.
I certainly do agree that Intellisense is far, far slower in Unreal than in any other project I’ve ever worked in, but also other than an operating system made of thousands of different pieces that were not all part of the same project, it’s far and away the largest thing I’ve ever worked in, also. So… there are reasons why it’s slow. I try to wait for the intellisense to be doing processing each file after I open it before I start writing code in it (ther’es a little notification window on the bottom left corner that chugs away while it’s parsing…) and that makes it a little more bearable.
You can always try Rider, although it doesn’t work well for me, other people seem to really like it.
Not sure what you mean “clicking a 10x10px icon all the time is a lot of fun” … Unreal macros work fine in VS… If you’re having to restart constantly, it sounds like a workflow issue, unless you’re using 4.x and doing a lot of structure changing and trying to live code, because changing the structure of classes (adding/removing variables/functions) does not work with that. You definitely do n’t ha ve to use Regenerate VS project every time you close. You’ll rarely ever need to use that. I think the only times in my life I’ve ever used that is after adding a plugin that was installed externally, but I wanted to get to the source from VS, and when upgrading engine versions. A simple save/close/restart/re-open shouldn’t take long at all, maybe 30 seconds. I think my load time is a bit over a minute, but my project is loading a pretty sizeable commercial game into memory at each startup, so… i’ve got a pretty extreme startup time going.
It could be underpowered hardware.
2 Likes
All of the above still stands for me.
In addition, I’ve now spent some significant time more fully re-implementing a complex MP Unity application in UE5. One thing that stands out to me, now that I’ve had some serious time with creating a real MP application is that Unreal’s native feature set reminds me a bit of that old commercial for Ragu sauce. “It’s in there!”
Yes, it’s a bit daunting in terms of tackling a full application as opposed to just futzing around with one of the templates, but “no pain, no gain” really applies here.
There’s a pretty big hump in the Unreal learning road, the part that once you are over, the light goes on and you really grasp how the foundational elements are connected. There truly are many interdependencies, and following the trail of breadcrumbs when solving problems truly can be a pain at first.
But once you’re over that hump and start gaining the skills to understand and trace all those UE content, code and blueprints interdependencies, things start really happening.
Another discovery is that, more often than not, there would be some “difficult” thing that I wanted to do, but the method wasn’t immediately obvious.
With Unity, I would typically discover that, no, you can’t do this thing natively at all. Welp, time to write a new framework.
But with Unreal, I will often pick at the problem from different angles, do a lot of reading, internet searches and whatnot. Then, the “aha” moment happens, where I see the Unreal pieces to solve my puzzle are already there, and I just need to put them together the right way to get my desired outcome, maybe with some C++ glue to make it more clean and easy.
There’s that initial Unreal honeymoon experience where you’re doing some cool things, but mostly in the context of a template or sample project. Then comes the wall, where it feels daunting to progress because you start hitting that AAA engine complexity. But power past that wall, stick with it, and you’ll find yourself getting in a groove, cranking out and integrating significant features and polish in shorter and shorter amounts of time.
That’s been my experience, YMMV.
I’ve been programming in C++ since the 80’s. Note that this is before C++ had templates. Unreal looks like it was made before STL came out. It has its own containers. No smart pointer usage (you can use them, but not with the GC). Macros galore. It doesn’t follow any contemporary conventional C++ guidelines. Still can’t figure out Outer vs. Owner most of the time. Seems to change depending on the class. They’ve retooled the purpose of constructors.
I can say that getting used to Unreal is really difficult even for an experienced programmer. I find that Unreal’s idea of instancing vs. C++ instances is not made clear enough, especially for beginners. For example (and I could be wrong), constructors are for UE’s classes, not for instances, though in C++ proper, they’re technically instances. I’m not sure where such documentation explaining this would even be or if it exists at all. I just learned it based on how the editor behaved. Material instances is probably the most obvious case of this.
There are LOTS of things I really like about Unreal. The animation tools. Foliage. How you can turn any class into a derived class and turn it into a blueprint if you want. And how easy that is to do. The idea behind components. Line traces. I could go on and on.
But there are some glaring flaws. You can’t add vertex attributes. This is a basic engine requirement and Unreal doesn’t let you do it. Most people use extra UV coordinates and use them as attributes. That’s really jank. No real distinction between vertex and pixel shader materials in blueprints. I’ve tried to create my own shaders, but the setup code is a mile long. And I’ve written plenty of HLSL and GLSL.
GetWorld() on subsystems don’t work.
I won’t go into skeletal meshes because it’d be too complicated to explain how it’s a black box. Just to give a quick example, I once tried to write a loader for a different format. That didn’t go very far.
Needing to close the editor every time you make a change in your C++ code in UE5 is a little weird. I was sure in UE4, you didn’t have to shut everything down.
I find Unreal has its own way of doing things and you have to conform. It doesn’t use camel case. It doesn’t use prefixes like m_ or g_. It doesn’t use STL. It uses tons of macros. Once you accept and become part of the “machine”, you’ll find yourself much happier. 
But yeah, I can 100% see how someone can become frustrated with UE. Once you start figuring it out though, it’s pretty awesome!
It was. Also, every commercial project I’ve ever worked on has had it’s own set of containers, along with very strict coding guidelines to never ever use STL. Sometimes, a project’s container is backed by STL, but it’s pretty much always better to have your own layer between your app and STL, so you can replace it when you find that STL is not sufficient.
Outer is freakishly weird. Owner is usually pretty obvious. I don’t think I’ve used Outer since UE2.
… ? Constructors run on any instances… they’re just … often not useful, because most things people would want to do in constructor are better done in something that occurs after construction. Data saved in your blueprints are loaded after constructor. The item doesn’t exist in the world until after constructor. The things that you can do in a constructor are relatively limited, simply because most of the time you’re going to be dependent upon values that simply do not exist at construct time.
Also, yes, there is a “Class Default Object”. When you use a class for the first time, an instance is created. So the constructor is going to be called for the default object, as well as any objects that are in world. pretty decent thread talking about that: What is CDO? … there may be others as we ll
That depends on which subsystem type you’re using. I have a GameInstanceSubsystem that is able to GetWorld(). Subsystems that are initialized prior to that may not be able to GetWorld() especially during initialization. I’m not positive if GetWorld() after the fact works, I think it does not, if the subsystem existed before the world did. I didn’t really take notes on it, but I have a Plugin that has a EngineSubsystem that does some things, and then I have in my game layer, a GameInstanceSubsystem that refers back to the Plugin subsystem to add additional functionality that is only available once there is a World available. I believe I did that because it wasn’t possible to directly access World in the Subsystem even after the world was created. It may have just been because it was easier to work with. I don’t 100% remember. But I did do it that way.
I haven’t done any work in UE5 yet, but I’m told that the situation is much better in UE5 – other devs that I speak with regularly have said that the improvements in Live Coding in UE5 that allow for most classes to be completely reloaded, have made using Live Coding a big improvement over it in UE4. In UE4, Live Coding only works when you don’t materially change the structure of an object, but in UE5, you can do that.
Pre-Live Coding, i avoided doing native coding as much as possible, but these days it’s pretty decent. (I do wish there was an obvious way to turn off use of distributed build systems while doing live coding, though!!! distributed build is amazing for long builds, but for short builds, it just really gets in the way)
3 Likes
There was something wrong with my setup that I’ve fixed. It wasn’t UE related. So live coding works. Also, they moved the button to the lower right (though I was still using Ctrl-Alt-F11). In any case, I take back what I said about live coding.
edit: Want to say STL is extremely good these days. The only use case I’ve seen lately that makes any sense for having your own containers is being able to not initialize elements when resizing. If you haven’t had a look at STL lately, you should. It’s really powerful now. And not just STL. The standard library and the language itself has been expanded. This may be another reason why people can be lost in UE. It’s quite the departure.
Just wanted to drop by and thank @eblade for taking the time. Most if not all your posts end up with me researching down a rabbit hole.
1 Like
Yes, the unreal build system for C++ sucks ■■■ bad.
I always look at the ram and cpu process and what it is doing on the hard drive after I hit compile.
It does not even touch my CPU for the most part until it actually compiles my project files, most of the time it stuck checking things, gathering things and these takes minutes sometimes.
Then you see your project file tossed after a few minutes and the cpu go’s up and it takes like 30 seconds or less in this phase.
So the build system takes minutes before compiling from the moment you hit compile, it’s not even compiling at all just building, so the problem is not the C++ tools but unreal build system.
Just for one minor change in my cpp It can take 3 minutes.
I compile from the editor, it’s a drag really to open unreal after each compilation if you have this huge project it will take a long time to load up. Each compile you would have to load the editor, that is crazy otherwise it’s hot reload.
Unreal has not bothered at all with this issue , it just does not, to optimize the build system for compilations.
More and more people are complaining about this yet they do nothing, they are busy building meta humans for comercial purpose instead of fixing the core problems of the engine that is draging it down. For my own needs I find it that I will test in open gl the code or in C++ editor before importing it to Unreal, I don’t find any other ways to do this with large code chunks, it’s just a nightmare to do this in unreal with the way it’s hanging in compilations.
So test your code elsewhere then bring it in unreal
It’s not bad, it’s just an unoptimized game engine that has good quality.
Unreal C++ build system
Unreal’s memory management .
These two drag it down regardless of the quality it can output as a game engine.
I’m still in unreal 4 latest ver for it with 8gb and a quad core processor at 3,8GHZ, I’m going to upgrade my ram, I was reading specs for unreal 5 because I want to switch to it and they say 16 gb might not be enough and this is suppose to be an engine for indies and solo devs or small teams.
What bothers me the most, is this program, has such amazing protentional. And, yet, it’s also it’s it’s worse enemy. EPIC got stuck, on the “Upgrade band wagon” and completely forgot how to keep the game engine stable. I hate to say it; but I spend more rebooting the engine, than I do being productive.
I started using, and learned UNREAL when 4.25 when it became stable. (It worked most of time) . But, someone can explain why the first line of code, links to CRASH reporting? And, what’s the purpose of reporting CRASHES, if nothing is done about it? MY READ is this. Why a crash report , in the first place? IF THE ENGINE is that unstable, IT shouldn’t have been released in the first place. FIX the bugs, b\efore it goes public. That’s how 99.9% is running now. UNREAL, however, not so much. IT is by far, the most unstable program I have ever used. ENGINE VERSION 4.27.2 is the ONLY version , that remotely behaves. UNREAL 5, is a nightmare, and I don’t have a clue, how anyone can actually use ir. LET’s dump, every new (And beta builds into it,and see how long it takes, before it crashes. 5.2 , sorta behaved. 5.3. Not so much. 5.4 NEVER. EPIC , seriously over thought. NEW feature’s? If they don’t work. We’ll fix it later. In the mean time. RESET. AND, don’t use.
Version 5. will all it’s bells and whistles, needs a 100% over-haul. I still can’t get certain apps/ packs to even run correctly in V.5 . And simply the interface.
I guess, that’s my rant for the day. In the practical sense; I can create 10 projects in 4.27. and maybe 3-4 in V.5.3 . And , then usually stop, because I get too frustrated, trying to figure out, why the project doesn’t work, or runs like it’s in some delayed loop. I don’t know, what EPIC can do. THEY seem to be promoting, 5.4 real hard.