Why does this suck so badly?

You have valid points Triv1.

Regarding compile times, I have also tried rider for unreal, and I haven’t seen any big improvements. I have also tried changing the ue4 config files, but 20+ min compile times are still common in the project I am currently working on.

My specs are i9-11900K, 64GB of RAM, and RTX3090. I don’t think specs are an issue, I have seen multiple complaints about slow compile times.

I understand blueprints enough to get multiple commercial projects packaged over the years, both desktop and mobile. And learned enough C++ to get some classes going, build a blueprint function library or build a plugin. But spending 2 weeks trying to compile the engine from source because of error after error that don’t have answers on UDN or forums or discord is a bit too much for me.

I’m probably just ranting now and thinking grass is greener on the other side.

I will report back after 1 year of unity.

2 Likes

That is most definitely a local issue, I can take any version of the engine that I have a current installation of the compiler that will work with it, and have it running on a similarly spec machine in 45 minutes (assuming you have NVMe SSD storage, as well)

20-minute compile times are not normal – on a machine like that you can build the entire engine+editor in 45 minutes on a clean build. I know, I do it regularly.

Lucky :sweat_smile:

Mine is i5, 8GB of RAM, and NVIDIA Geforce 410M :smirk:

Wow yeah your development PC is way better than mine. There used to be a big issue with compile times before 4.2x versions. I can’t remember which version it was though, but they fixed it and I haven’t had issues since.

It does sound like something isn’t working properly locally to cause such long compile times.

Unity is useful for games that don’t need top of the line graphics or large complex mechanics. Personally I mainly dislike their business model for developers. But some profit is better than no profit.

Good luck to you with unity, I hope you find success.

I missed this the previous time around.

It’s true, Fortnite is a real cash cow! But do you know what else is a cash cow? Every single game that ships on next-generation platforms, that uses Unreal Engine. Between thumb and forefinger, I would assume Epic makes similar money from those licenses, as they make from Fortnite. Why on Earth would they make those developers less successful? They rake in the cash, licensing out an engine that they would have built anyway. The more successful they can make other developers, the more money they will make.

Now, why don’t they add tons of newcomer-friendly documentation that hand-holds developers through the bring-up period? If you consider what kinds of games actually bring in the dollars, and what kind of development teams build those games, perhaps you will realize how the structure of the industry makes it the way it is. My guess: A random Roblox or Unity development team is not on the list of target users, other than as a way to market/farm future AAA developers.

1 Like

I’m no dev and I mastered the framework of UE4 in less than one year.
I’ve been working with many 3D software before and I never saw a software so easy to learn. You got all the documentation needed, even in videos of 1h long from the Epic games staff itself. Tons of tutorials. You got an hyperactive community on Reddit, on Discord, on the forum and on the answer hub.
My advice, start with Blueprint. Coder or not, Blueprint is the key.

1 Like

Gonna pile on to this ridiculous thread just to say that I see people up above comparing Unity C# to Unreal C++.

Unity C# is scripting, comparable to Blueprint in Unreal. If you are working with C++ in Unreal you are working with source, something you cannot do with Unity. This is not to say that Unreal is “better” than Unity because it’s open source, there’s no such thing as objectively “better” when choosing a toolset.

Comparing Unity C# to Unreal BP is like trying two different makes of car and comparing what it’s like to drive them. Comparing Unity C# to Unreal C++ is like comparing driving one car to building a different car from scratch. Apples and oranges. No wonder OP was having difficulty. Most drivers are not automotive engineers.

1 Like

You don’t have to use C++ at a level significantly differently from Unity’s level of using C#, if you don’t want to. You don’t have to go poking at and extending the engine, and can definitely achieve quite a lot. Though it is easier to blow things up in C++ since you are effectively extending the engine, whereas Unity is running your code separately sort of.

You are right , this reminds me of the blender game engine that split from blender and are no longer part of the Blender Foundation.

They use Python api to run C++ engine with bindings, it’s a pain, each time you want something you got to ask the devs that are like a few guys there to add something in C++ to the engine, some new functions to use or some other new things, the rest are monkeys put in charge of the API code and wild as Tarzan from the jungle where if you are not careful coconuts from the trees can fall on your head and break it because of the API crowd put in charge there :grin:

So I told them why don’t you make C++ api if it’s in C++ , and I got in arguments with the API chiftans there from the cave of the jungle, I waved them goodbye with my safary hat once I was on my way outa there

1 Like

Stop all this nonsense, Unreal Engine and Unity are the 2 best Engines. Both on the #1 spot.

1 Like

Frustrations aside, I don’t think there was ever a doubt about which one is the best one. They are both great engines with a bit different target audiences, strengths, and weaknesses. I think we should always strive for the right tool for the right job.

1 Like

time is the issue , the devs can spend there time ether fixing bugs or adding features , or spend almost the same amount of time correcting the documentation for code that may have a bug , that once fixed needs the docs modding again to reflect the fix changes to the api’s

look at the api’s docs as a guide (not even read them so cant comment but an analogy of old would be like one of the original yagdrasill alpha version 0.95 linux manuals that had the words “alpha version trust this and die” in bold printed at the top of each page ), especially with ue5.x builds , fixing the code and getting it working is the high priority bit (doc’s are no use if the code is broken/changed, other than tell you what it should do not what it actually does )

were lucky though, it comes with the source , if you want to know how to use one of the api’s read the source for it
once the code becomes final , then is the time to fix the docs , quick reference api sheets etc.

also when reading the code to find out why your call to it fails , you may spot the bug that causes the issue , saving the devs hours trying to pin point it themselves , leaving the dev’s with more time to do the cool stuff like write new features ,and us to get on with our own dev using it , not waiting around for weeks for someone to get around to fixing it , so at the end of the day this can benefit us all

you dont have to be a expert c++ programmer to read the code and get an idea of what its doing , anyway you should be able to see what arg’s are needed to be passed to it almost as easy as a quick ref api sheet if nothing else ,c++ can be a pita to code but its readable , its why many prefer other languages like python, java etc , also note EA UE5 source is commented :), so more useful and up to date than the docs , maybe you will learn something from it in the process(C++ probably)

many hands make light work , may the source be with you :smiley:

I agree that the documentations may be not as they should be; However, I see the actual code is written with naming and commenting that try very hard to explain almost everything. It may be tough to find proper documentation about many things, but if you keep digging in the source code, again, and again, you will understand more and more things. I think the source code is well written frankly, and is entertaining to learn.

It is tough still, because as far as my experience goes, UE4 code squeezes every last feature of C++(C++11 at least), which will, by design, make the code very time consuming to understand. But the more I read, the less angry I become about the those who wrote the code, and more understanding I become of why they did so and so.

Yes Psy the documentation does suck badly. I am having difficult time trying to understand how to get access to things that are part of the engine because the documentation is no where to be found.

The engine can be as good as it is but no documentation means you cannot fully exploit the engine even if you are like “supper entity” computer programmer.

Granted that, but if you are trying to access some data which contradicts the essential assumption of the engine architecture, then there is a very great chance that this issue is well described within the code comments (somewhere < this is the tough part).

You have to consider the comments and naming, and naming conventions as a more valuable source for learning the engine than the actual documents alone. Documents I think are of two types. One type is designed to guide newcomers so that they can do casual/frequently done tasks in C++, and this type of document is pretty decent. The other part tho (which is labelled ‘advanced’) is designed to only give to a ‘competent’ programmer an overall idea about the philosophy and major assumptions of the engine design, and this part is decent as well.

Now, if you want to do something that’s not commonly done by everyday game developer, then you have to behave like an actual engineer and just keep digging in the source code yourself if you have the patience and competence to do so (hopefully you have), you’ll find it a pretty decent, well written, well commented code. That’s exactly how I feel, and I am not a programmer by profession. I spent years on my game, and on UE4 source code, and as tough as it is, I never felt that there’s any real obstacle preventing me from completing my darn mission. You need to be the right person for the task. Or just go to another type of games that doesn’t need advanced access to the engine’s source code.

Why don’t people delete this thread?

i guess you know how but for those who dont

say you want to find the UPhysicsThrusterComponent function , not just every bit of code that calls it

file search (contents) for “void UPhysicsThrusterComponent”
the “void” part so we find the function itself not calling code
returns a list of all files containing the given keyword/phrase (dolphin in kde on linux does this , i dont do windows so cant help on that ) it may take some time to search all files in all sub folders of the project ,
in this case
~/UnrealEngine5/Engine/Source/Runtime/Engine/Private/PhysicsEngine/PhysicsThruster.cpp where it found 2 instances

then open the file(s) , and search and replace , highlights all instances of that keyword in the file and its line number (kate or notepad 2 on ether linux or windows (both have code highlighting also ))
that returns
2 matches (2 checked) found in current file
/home/david/dev/UnrealEngine5/Engine/Source/Runtime/Engine/Private/PhysicsEngine/PhysicsThruster.cpp: 2
26: 1: void UPhysicsThrusterComponent::OnRegister()
41: 1: void UPhysicsThrusterComponent::TickComponent(float DeltaTime, enum ELevelTick TickType, FActorComponentTickFunction *ThisTickFunc

this speeds up looking for that bit of code

maybe being old school, predating IDE’s , i tend to uses an editor (kate ) and a console as my normal “ide” , but i guess most ide’s offer search functions that can do the same

Thanks a lot for sharing these tips.

I fully depend on Visual Studio:

  • for any entity: right click, then ‘Find All References’: this gives a decent sortable search findings, including the files paths, and whether read/write (for variables), and a few other features.
  • for functions specifically: right click, then ‘View Call Hierarchy’ (this takes time).
  • for classes: in solution explorer window, find the class file where it is defined (usually a header file), right click on the class to see all base classes, and derived classes.

I am pretty much doing this kind of searches, and jumping back and forth between files, writing notes on my GoogleDriveDocs. This is how I am learning the engine.

I think most editors/IDEs these days support some sort of “Find Symbol” to search f or functions, variables, properties, etc.

though that can sometimes take a while, i usually start with checking for a file closely named to what i’m looking for. :slight_smile:

I wholeheartedly agree with you and mind you I just started learning Unreal and C++ coming from Unity and C#. I was a little apprehensive after hearing how difficult it was to learn C++ and now I think those remarks were made by students just starting out learning their first programming language and choosing C++ as the starting point. My transition into C++ was so smooth that I was quite surprised with myself. The Unreal interface was a little daunting at first but if you start thinking logically it is easy to pick up.