I’m a c# programmer and sysadmin by profession.
I have been trying to learn unreal for I don’t even know how long. Every few months I will make a new project and try to get something done but there is always some roadblock, always janky code, always terrible documentation and I get fed up and quit.
It seems like there are all these wonderful ease of use enhancements for visuals and mapping and everything else, but the code is still a giant middle finger blazing in the night sky.
I’ve tried unrealCLR and meh, its better but does not have feature parity with the janky mess that is unreal C++.
and that doesn’t even touch on the fact that the documentation for literally everything is subpar or worse. out of date, depreciated with no links to what replaced the depreciated feature. I’m in awe at how anyone makes anything with this jumbled mess.
I’ve tried Unity, I like coding in unity, but unreal has the best feature set from what I can see. Nanite? Lumen? All fantastic forward facing features but when I can’t even get GAS implemented properly half the time what is the point?
and this isn’t a C++ vs C# debate or anything. The unreal API just plain sucks. nothing is intuitive. none of my years of programming experience carries over and thats a serious problem.
and don’t get me started on crashes! this house of cards crumbles if you look at it wrong.
I’m sorry that I’m ranting but I’ve had it up to here with trying to learn this ■■■■ thing.
I’ve been working in Unreal from 3 months now. I started with Blueprint to get to know the APi and to get things done fast.
I’m now moving to C++ and I really don’t know what you are talking about. Junky mess? C++ in Unreal is both easy and clean.
I can understand your complaints about the documentation, but I think the only thing that is missing is a code example for each API function/object. Documentation that only has functions prototypes and parameters is not that much helpful. We can get that info from the headers (the documentation is probably generated from the header files).
The unreal API just plain sucks. nothing is intuitive. none of my years of programming experience carries over and thats a serious problem.
That’s not true. Your years of experience should carry over. Both c++ and c# are object oriented languages.
I am going to answer this in the most helpful way I can. Please do not take this as a personal attack – I mean nothing of the sort; just that some of the words I hear used indicate to me that perhaps these answers will be the most helpful to someone trying to get going with Unreal game development (and a games engineering career in general.)
Real engineering consists of powering through these disappointments. The #1 criteria for a successful engineer, is the ability to keep going, until the job is done. This is what people mean when they say “grit is as important as intelligence,” and they’re not wrong. (Some say it’s more important, but I don’t think so – my experience is that whenever I lack either, I don’t succeed.)
I have banned the word “intuitive” from design discussions, because what people really mean by that word is “similar to something else I’m familiar with,” and what people are familiar with varies wildly. If you haven’t worked with a number of different game engines, and worked on different games, enough to build real experience, then the choices in Unreal aren’t going to be familiar to you. On the bright side, because you do get the source code for the engine, studying it and learning it, will help you build “intuition” (or, more accurately, “familiarity”) with how a game engine like this is put together. Every engine needs marshaling support, editor support, object lifetime support, and so on, and while they each choose a different way to implement that, if you squint, they all end up sharing a lot of similarities.
I hope you find the grit to keep at it, and become successful! Once you power through the disappointments, there’s a massive lot of good stuff on the inside of this engine. Even if you had a team of ten amazing developers and five years to develop your own engine, you could not match it. It really is an amazing boon to game development that you can download and use it and read all the code, without paying a cent until you become successful!
a direct quote from someone on the unreal slackers discord:
" the ue api is jank, the c++ api is also jank, welcome to c++"
It should not be these bad. if epic wants more people developing they should be fixing their documentation and addressing issues in their API.’
I’m a c# developer and I’ve had my fair share of headaches in that regard, but unreal is the first thing to make me legitimately angry to attempt to learn.
See this story often. “I have x years of programming experience and unreal C++ is impossible to use. Epic needs to change this or else no one can use it.”
The problem with this logic is the majority of top selling games every year are made on unreal engine. Indies are able to produce games solo and do well using this engine, it takes forever but it’s possible.
Personally I cannot relate as I had no programming experience prior to unreal. I also started with blueprints and studied a ton. After a year of blueprints, I jumped into unreal C++. It was rough at first but took a udemy basic C++ class and then started practicing.
After learning about syntax and how things need to be organized to work properly, I compared blueprint nodes with the respective C++ code and learned more. The deeper you dig into the C++ the more you learn. Especially once you get into the engine code.
I don’t think even a master C++ coder would be able to make a game without doing research and learning how the engine works. Maybe I am wrong, but it’s that complex of an engine.
There is a reason why this engine is used so often. They wouldn’t have billions and the best earning game of all time if they didn’t know what they were doing.
I completely to agree this, couple of months back I was using Unity and picked up all the c# and all pretty fast. Yes, Unreal Engine is a bit hard but once you get the hang of it, it’s pretty easy! Hats off to Epic Games!
Unreal Engine is the most in-demand engine when it comes to real-time graphics and with the real-time features and scalability that Unreal Engine 5 has to offer, there’s no doubt the demand will be rapidly increasing.
The C++ when it comes to the Gameplay Framework is really good and easy Unreal takes care of a lot of things and makes it looks like you are scripting in C#.
Where there is problem is mostly on the backend (Slates, Rendering etc), that does require some top notch C++ skills and I myself am struggling a bit on that front. But I do agree most of this struggling is due to our tiny C++ community and outdated tutorials and the documentation mess.
c/c++/c# programmer for 2 decades been learning unreal for about 1 years.
I have worked in manufacturing, medical and defence products, and when i look at the documentation unreal provides to the public , i would say it borders on what software industry calls information hiding.
The documentation is so bad it cant be just down to lack of effort.
The only conclusion i can draw is that since developers are kind of in competition with unreal as epic develops games too, there is no financial incentive for epic top provide the public professional standard documentation.
I can honestly tell you this, if i owned epic, i would have an internal much more up to date documentation that’s not available to the public , else if the docs we see is what they use internally, the epic dev team office will look like a pirate base where folks have epic by the balls with all the real info only in their head.
There are tons of very useful features i am finding in unreal that are not documented, example how to have plugins situated in folder of your choice and not in engine or project, they have something for this, but its not documented.
Every single project i have started in the past year slowly grew bigger , and always ended because of some impossible to find bug/crash/fault etc.
I think part of the problem is that epic went too far with the Unreal version of c++, and code generation, that stuff breaks very easy.
Unreal engine really calls for some serious defensive programming , i use exceptions with message very liberally in c++ and blueprint.
And the only place where the code is really documented is in the source, else you wasting your time.
I cant leave without saying, to be fare to epic, the product is free until you earning 1 million dollars from sales, and there be no such thing as a free lunch, its up to you to decide if its worth the effort, the effort of the terrible documentation which many will call information hiding.
The only thing i really do appreciate about the document are the well thought through tutorial sections.
And youre so right when you say, you look at it the wrong way it will crash.
I do have to admit the more i learn it, what a great product , unfortunately the only way to really learn it is trial and error at runtime. Heck even the debug run you can never be sure what part of your code will be visible to set break point, and the more template types involved the more likely you see no debug.
I think they need to move closer to standard c++, so that folks c++ experience can count.
Reminds of the various failed Microsoft c++ versions.
Modern c++ is like a space ship , if c# is a helicopter. So i wount go down c# route for this only make it worse.
If you believe that a couple of months is all it takes, no matter what the engine, then you probably don’t have enough experience to understand how deep this rabbit hole goes, no matter what the engine.
To be fair: If all you want to do is crank out minimal experiences with average compatibility and not push the platforms to what they can actually go, then that level of experience probably works just fine. There’s a space in the market for that kind of development. That’s not a space that Unreal is particularly trying to ace, though, and they don’t need to.
Am I an Unreal “shimp?” If you find me on LinkedIn you’ll probably see that I have a much deeper investment in a couple of other game engines over my career. That being said, I strongly believe in giving credit where credit is due.
It is true that, when you get to the bottom of the engine, you need to be able to read code. This has always been the case at all places I’ve worked, and engineers who dive in, read the code, and get the job done, always end up being the high performrs, and those who don’t, don’t.
I think you need to qualify that a fair bit. The documentation about which part? If ou want to write your own render pass, yes, you need to read some code. If you just want to wire bits together, there’s plenty of documentation to get you going.
There’s a large amount of documentation to get you going – my main experience is that there’s too much, so it’s hard to find the right place to read:
Now, when I get down in the guts, the API documentation will say something like SetRenderPassFlags() – set the flags of the render pass – but that doesn’t matter, because the actual implementation is a single F12 tap away, and has more detail than any documentation will ever have. Given that Unreal is intended to push the envelope, they inherently cannot provide a stable API at that low level, and thus investing in transcribing the code to human-English is not something I’d expect them (or any developer in the same situation) to do – it solves the wrong problem.
If you are C# I take it you have been on Unity for a longtime.
C# is not C++ this is the truth, it’s a more modern language and if you ask me from what I read about it, it is different from C has lots of modified sintaxes.
THe Unreal API is fine once you begin to understand it.
It’s just C++ with extra handlers, it’s based on function call and those functions are made in C++
It has built in functions and other libraries like math libs that you can use that are not even from unreal.
THe only things that are native to unreal is the U components and Uobjects that go beyond function call.
it’s C++ my friend
if you are a C sharp user you cannot understand it.
Unreal C++ is some of the cleanest C++ I’ve worked with. Also documentation is not that bad, especially customer facing API (i am talking about code comments). Yeah if you’re expecting Unity level of documentation - its understandable.
I find this specifically very puzzling:
Are you new to game engines in general? Unreal shares most of its fundamentals with virtually everything else out there that falls into real-time category.
While I do agree that much of the API documentation is pretty lacking, and most of it is generated from the headers, and that lots and lots of it could use better explanation, I disagree with most every other “bad” point people in this thread have made.
I think one thing to remember, is that this engine has been built over the course of nearly 25 years of work, and that not every component gets updated and re-written and deprecated/replaced over that time. Hell, I can hardly think of anything in here that is deprecated
… I do know that the last time I went to use Unity, both the renderer and networking components had been deprecated, the new renderer was in alpha, and the new networking components weren’t even available to the public. I cannot remember a situation anything like that ever existing in Unreal. I do know that sometimes they’ll mark some functions as deprecated, and offer new and improved versions of them (usually with a compiler warning that tells you “Hey use this (new function) instead”). I cannot in my entire 15 years working with Unreal recall running into outdated documentation on a specific release.
I can’t speak for the documentation or how to actually implement anything with that, as no professional product I’ve worked on has used it – it’s also a relatively new component. However, I can pretty much guarantee that just like all the rest of the engine features, once you understand how it works, once you get that “A-HA!” moment where the piece you’re presently missing clicks into place, you’ll find it easy to work with. I unfortunately can’t advise you what that piece might be, since I don’t know it, and haven’t used it.
I’m pretty sure that it’s a large part of Fortnite, though, so it must have some pretty decent things going for it, I’d think.
If you know how to program, it doesn’t matter the language or the syntax or the API, those all should be pretty easily interchangeable. If you can operate in a few different programming languages, you have all the experience you need to be able to carry that over to any other system pretty quickly.
Knowing how to operate a debugger and using it to identify what you’ve done that causes an error/crash, and not doing that again, is quite a useful skill in programming. Both Unity and Unreal are extremely complex engines, though, and while they can be pretty easy to crash, it’s almost always due to something the user has done that puts it into a state that cannot be recovered from.
Which janky code? Which terrible documentation? Point out what needs to be improved, please. There’s a metric ton of both code and documentation.
very strong point here.
That seems an awfully large leap in logic.
LOL. I can’t wait till they get moved into their new massive headquarters that is in a space that used to be an entire shopping mall, and see the most epic pirates vs ninjas nerf battle because no one can figure out what to do.
I’m not aware of anything like this – would love to see any proof that you have pointing to that, and we can work it out and document it. What I used to do when I was working on a plugin that was used in multiple projects, was I’d create a git repository for the plugin, and then I’d include it as a sub-module ( Git - Submodules ) I would presume that other version control systems also have similar functionality, although I’ve never looked into it for others.
It actually probably makes more sense to do it like that, then to allow for including something from outside the project – if you change the plugin outside of the project, you can cause total failures across multiple projects, whereas with a situation where you specifically have to update the module inside the project, you’re not likely to commit a change that breaks any of the projects.
I don’t follow. What do you mean here?
Every commercial product I’ve ever worked on has banned the C++ stdlib from being used for anything. (and i’ve done a lot of work outside of games) Outside of that, everything in here is standard C++ (well, obviously excluding the C# bits for the build system). You do need to become familiar with the various containers and other types that are available, but that’s true of everything. So what do you mean by “move closer to standard c++”?
If I remember correctly, not very long ago, GigiK-K-K had many of these same complaints
If I remember correctly, not very long ago, GigiK-K-K had many of these same complaints
Yeah, but not in this mode, I was saying that I did not understand the extra ++ stuff, unreal ++, the handlers. When I first got my first UE copy I was just like this guy perplexed, what is this what is that, what the !!@!@#$ Until you understand the handlers and the UComponents .
So I was talking about how I felt when I first saw this, I was exactly like this guy, I had no Idea what to do, everything looked alien to me.
Like tick function and start game function, what are these … lol let’s not upset these sections or I will surly get errors, when you know the class generated it had all this code with tick, start, imput components that you like don’t understand at all.
He does not understand these, these are just “easy lunch” for a month to get by fast and understad them. It’s just a little effort to understand the handlers handeling things.
If you stay about a year on the unreal engine, you will improve your C++ sintax understanding and understand the game engine basics in general. One year is not that much if you want to move from C# to C++
I started learning Unreal about 6 months ago with no game engine experience prior to this, but I did have over 20 years of C++ experience (servers, kernels, databases, etc). While Unreal has it’s share of technical debt like any other piece of software, I found it fairly easy to pick up. The high-level overview documentation is pretty decent. The documentation on how every class/function/etc work are sometimes ok, sometimes non-existent. That’s almost always been the case for any projects using doxygen based docs though. But to be honest, I don’t think most of those docs are needed since you have the source code. Any experienced dev with a debugger and the code can figure it out pretty quickly. If we only had binary modules to link against, it would be a different story - in that case API docs need to be top-notch.
The reality is that Unreal has been around a while and has lots of users depending on code not breaking between versions. Sure, if Unreal was rewritten it could be simpler with cleaner APIs, but that is not realistic. All you can do when a piece of software reaches this scale is slowly move the codebase and documentation in a better direction and try not to break backwards compatibility in the process. I think they are doing a good job seeing how UE 5 is coming together as well as efforts with the new Dev Hub.
Also, since Unreal is developed by hundreds of people, you’re going to get inconsistencies regardless of how strict the coding standard is. For example, I’ve read through large chunks of the networking and physics code inside the engine, and while the styles and quality of code comments differ, they are both fairly easy to follow in their own way.
I can see how it could be frustrating for less experienced C++ devs. The goal is usually to make a game and learn just enough C++ to get there, not to become an experienced C++ programmer. Once you get through the basic C++ gameplay docs and tutorial projects, there is no hand holding. This is a hard area to document and teach though, since the best solution is time and experience (not just with Unreal, but programming in general). My only advice is to not hurry, read as much of the code as you can, and if you don’t understand it, learn more C++ so you do.
I’ve been working with unreal for around 4 years now, mostly as a TA, almost exclusively with blueprints except some simple libraries.
Regarding crashes, I can say that they are super common, even non-code-related, just renaming an asset can sometimes cause a weird crash. But that’s an issue with most 3d/2d software so can’t complain too much about that, save save save!
I consider myself an avid learner, I am pretty comfortable in multiple DCC, render engines, a bit of python, JS, C#, but personally, I had a really hard time understanding the C++ API in UE4, and that, combined with incredibly slow compile times, has kept me away from diving in deeper and is making me consider other options as the main engine.
To make things worse, this year I was developing an iOS app using UE4, and encountered some very weird problems, for example before 4.27, packaging a project using file-package-ios would result in a package that would not be accepted by the app store, so had to use project launcher. After 4.27, my projects could not be packaged anymore using the project launcher as it would result in build errors but worked fine using the file-package-ios.
The worst experience came from trying to compile the engine from source, to be able to add some extra iOS functionality. Even something “simple” as downloading the project from Github and compiling it, would result in errors on 1 computer, but work on another. Then after adding the new code, would work when compiling on windows, but not on Mac, or vice-versa. Some errors were permission-related, but some were just very hard to track down, even some other people experienced the same issues and never solved them on forums or other places.
I understand that it’s a very complex engine, and it’s free, but it’s a nightmare experience for small developers.
Those problems can definitely be frustrating. Although all the problems you listed can be solved by understanding how the engine works by diving into C++ and setting up your IDE correctly. If you are using visual studio and it’s too bulky, check out: https://www.jetbrains.com/lp/rider-unreal/
It is a IDE being built for UE4 with way less bulk, so far I have had good experiences with it. Compile times haven’t been an issue for a while, at least for me everything compiles in less than 2 minutes. What is your cpu, gpu, and RAM? It could be a hardware issue causing your longer compile times.
You understand blueprints well enough to get a game nearly packaged. Perhaps you should start with a basic C++ class to learn syntax and organization then compare blueprint nodes to their respective C++ code. Then try to implement and get a basic blueprint project into full C++. You will learn so much and it will allow you to start understanding how packaging works and how to fix the errors.
It can be a nightmare and there are some features that are not working properly, those should be avoided until they are fixed or you find a way to make them work. Personally though I have found the vast majority of issues minus buggy features are from developers not understanding how the engine works and using it improperly.
The problem with other game engines is you have to modify them greatly to fit your needs, or give up a huge chunk of your profits when you do succeed. So it’s a trade off, use the best engine for graphics and profits but it’s hard or use something easier and give up a ton of your profits(unity). Or the final alternative build your own engine or modify an existing one with a decent business model.
You could also post a thread here about your packaging issues and generally someone will point you in the right direction to fix it.
Until you understand the handlers and the UComponents .