Is Unreal Engine for game developers or for engine troubleshoothers?

Preface: not attacking the Engine. Just sharing my bad experience hoping for an improvement of the Engine

Not other than troubles.

Since I started using this Engine, all I’m doing is trying to resolve engine-related problems.

Incompatibilities with Visual Studio after upgrades forced me to install newer versions… and this led to…
Incompatibilities with the older code. This forced me to change my code on the fly.
Weird visual bugs resolved after restarting several times the engine, a bunch of crashes due to engine-related stuff.

I’m wasting lots of my time trying to solve engine issues, I barely write code for my game.
I don’t even have the time to develop an algorithm or a new feature.

I know what you think. You think I’m lazy and I don’t want to have problems while making my project.

No.

I do want to struggle, it’s ok. But I want to struggle on my code, on my algorithms, on my problems, not Engine ones!

Sometimes I really wonder how big companies manage to use this unstable Engine.

And I know someone is going to say the problem is me, not the Engine.

Just to mention a recent episode…
I was installing the Unreal Engine 4.12.5 using the Epic Games Launcher… it crashed after some minutes of download.

Seriously guys, just make ONE Engine release which is as stable as mountain rock.

When will these updates be over? I can’t bare this anymore!

All this frustration is taking me to write a game based on SDL and pure C++! Crazy!

Again, not attacking the Engine or the Epic Games staff. Just expressing my troubles with this engine.

I’d like to hear your opinion!

Incompatibilities after an upgrade are to be expected. This is a typical and expected issue with any software package.

4.11.2 was a rock solid release for me. Great performance in the Editor. 4.12.5 freezes all the time for 10-20 sec, constantly. 4.13p3 does the same.

Man you are preaching to the choir. I completely abandoned actually coding in the engine, then got frustrated with blueprints and thought about just coding everything besides minor things. I had the C++ problem when they switched to UE 4.10 (I think it was 10) forcing me to acquire VS 2015. I already hate Visual Studio and what it has become. I would like to see some other integration like eclipse or CodeBlocks seeing as how both of those are cross platform and what I normally use.

You are right the versioning is Horrible. They push up additions at break neck speed which breaks code. My team has decided to wait for the right version for us and stick with it when it comes out. This post is old and you are probably gone now but there are inherent issues with the way the jump forward never settling on a release version. Many things need to be fixed that have been ignored for the last 2-3 years.

One thing though, it seems they don’t cause old problems on top of new ones. This is pretty amazing to me with the way epic goes about a new release every few months. The problems remain, the toolset gets in the way of creativity and the things you can do once you learn to move around the obstacles is amazing :smiley:

I just realized this is probably not a old post seeing as how after the forums got HACKED (because they are using a opensource forum) the dates are wrong. One more thing Large companies get extra support from epic they always have.

If you upgrade the engine every month when an upgrade is available, it’s only logical to expect breaking changes. The engine has been available for two years, it’s a high performance system that will always stick to the latest compiler / libraries because they bring better performance. If you’re a C++ developer, you can skip the compiler upgrade by compiling your own version of the engine (it still supports Visual 2013), but it makes sense for a new version to only support the latest Visual version. Just like it makes sense to have breaking API changes, because those are needed from time to time. That’s what versions are for.

EDIT : didn’t know about the date issue. Sorry :slight_smile:

A couple of points…

  1. You knew that you only upgrade when there are reasons to upgrade - eg bug fixing… or performance or new features which are badly needed. Do not just upgrade because there is a new version…

  2. Knowing C++ or at least know to cherry picking code changes which you badly needed (show stopper bug fixed for an example) will be of immense help…

Unreal Engine only uses VS as an editing/debugging platform. They have their own build system (UnrealBuildTool) which does the actual build. So it should be possible to setup Eclipse or Code::Blocks to use it. The only other VS dependecy is the project generators and if your IDE of choice supports import VS solutions, this should be easy to do. There was someone who got thinks working with QT Creator, do a search of the board for the threads.

I really would like to just stick with one version!

But…

  • When I ask for help on the forums, they most likely suggest me to upgrade
  • When I update Visual Studio for my own reasons (other development projects) my current Engine version no longer compiles my code! And since Visual Studio launches updates frequently… I always need to update the Engine…

What exactly do you believe to be an issue ?

Breaking changes in the C++ API ? There is a depreciation system so that the old API stays for a few months.
New Unreal releases not supporting previous Visual Studio releases ? Usually, building from source fixes that - and supporting all versions in a binary release would make the download size even larger with each supported release.
Old Unreal releases not supporting newer Visual Studio releases ? They can’t see the future, can they ?

  1. if you only upgrade when you have a reason, then upgrading will be much more painful. sticking to one version isn’t really an option because all the existing bugs and incomplete features, and because if you report a broken feature or bug they will only fix it in a next version (or several versions later).

  2. that’s a time waster. I can relate to the OP about wanting to work on game code rather than the engine, which is why I have a strict policy of sticking to pre-compiled engine releases. once you start making engine changes, updating to a new version is a time hog.
    also you can’t just cherry pick code changes. it can work on code changes after one version but after that any code you want will be dependent on other features and so on.

I want to specify that I use the compiled version of the Engine just because I need to build the dedicated server for my game via Visual Studio.

I don’t change Engine’s code.

I already struggle by just using the Engine, let alone change it!

It takes several years to develop a game in unreal if its a major project. You might be going through alot of updates of the engine during that time as are building your game. Each time they update the engine build, something in the code gets broken somewhere or blueprint nodes get changed… I KNEW the code was broken, I KNEW the engine was unstable, I knew the system was set up all backwards because the editor is separated off from the engine because the code and is broken up in bits and pieces in little isolated islands in the sea and you got to create
all the links all between the isolated islands to get them to all understand each other in order for them to work as game components.

So the engine is not in game components, the code is actually in thousands of pieces that you have to connect up with either classes
or Blueprints to piece it all back together again as game components.

In Unreal, we are spending most of our time under its hood to try to find what went wrong with it. And because its not
engine version friendly, each time they get a new version, something else breaks in it. The engine works but its unstable…
Because everything is in broken bits and pieces that you have to assemble to patch it all up to get it all working, It is going
to take a year or possibly more to get anything major done in it even with the marketplace coming to the rescue
now to try to speed things up.

GREAT…,ITS NOW WORKING I can see it working in Mantinee, now I can now do this cool move… OOPS, WELL MAYBE NOT…

So You instruct the editor through the user interface what to do and you would think this now makes all the code islands all talk to one another as you are changing the user GUI settings of the editor on configuring all your meshes and setting up your animations and stuff in matinee or sequencer, but no after instructing the editor on what to do with your animations and meshes stuff, you have to talk to the islands in
blueprints or instruct it through classes with Visual Studio, isn’t that ironic?, the user GUI interface already knows what to do, Mantinee knows what to do, you see it all happening in the editor on the screen its playing all your animations and all your blend spaces and so on on the screen, its all working great in preview, it took you an hour just to set that it all up in the editor, and you think now you’re all done you can just go now and play the game and you have all your animations working, only to find, nothing happens because it was just only cosmetic changes that don’t even effect the engine so its not talking at all to the engine and you have now spend another several more hours to go into the C++ classes or into the blueprints to bring out all the little islands and start wiring them all together so they can all start understanding what the user interface is trying to do, So that’s the way of doing things, doing it all back to front putting the cart all before the horse, why well because I think it was a bunch of guys who thought of setting up the games this way. That’s why I think its called Unreal. Because the engine is unreal in the amount of misery and trouble you have to go through just to get the engine to work for you.

HUD EDITOR NEEDS IMPROVEMENT

I want to see an improved hud editor that has the ability to do dialog without me having to create a new hud blueprint for
each dialog piece all the time just to put a new dialog piece on it and ending up with tons of pointless hud blueprints
because I can only see one page for the Hud when there should be the ability to add in new pages or layers to the hud so you
can hide also text dialog on different layers if you want and then you can use that layer to get unreal to look up a piece of
text in a file with the speaker name id line and then pop up the speaker picture and text in the hud.

MANTINEE.

Surely these programmers at Epic are intelligent enough to recognize a jump, a run, and idle and so on animation and
then just tell Unreal engine to create all the blueprints and state machine automatically for them when you are done setting up
in mainteee with all the blend spaces or animations you want, can’t it just read all the data from the Matinee setups to determine the state
machine to create? and then you can add other parameters and variables to it later on if you want to customize it?

LACK OF READY MADE COMPONENTS

The engine should’ve come with alot of ready made game components SO THAT YOU only have to customize those components and DON"T HAVE TO DO SO MUCH wiring up just to build the components but no they left that instead for the marketplace to do (go figure). And that’s why they have to come out with these blueprints modules now on the marketplace to make up for all the isolation that’s present in the engine.
We have isolation in the engine that is like the Grand Canyon in Unreal.

NOT VERSION COMPATIABLE FRIENDLY

The engine is not backward compatible so it remains broken you can’t always load back in those uasset save files if your engine version
is not the same or higher as its not backward compatiable so problems can arise… Apart from its dazzling shaders
and graphics that it does gives your games alot of power when you go through all the trouble of piecing it all
back together again, but under the hood of that Ferrari is a Humpty Dumpty that’s sitting on the wall and
Humpty turns out to be a fat ugly pig wearing lipstick.

Why didn’t they just list all the engine errors during the cook stage of the project instead of trying to do it
continually during the editing stage where we have to make many millions of little changes all the time to our projects
as we are building up the game?. I thought that surely the time for checking projects for any engine errors out should
really be left last during the final pack stage.

But no they set it up so the engine checks for any errors continually as you are building the game. so the result,
the engine just pulls you up on error after error after error every half an hour or so so you are spending more time
fixing up engine errors than you are in editing the game.

So the guy is right who brought that up in here about spending more time fixing up the engine errors than
you are in developing the game. That’s why it takes SEVERAL YEARS to get a major project done if it ever
gets it done… Even the guys making the tutorials warn that the engine crashes often on them and warn others to save and compile every time
you lay down any blueprint nodes that’s how UNSTABLE the engine is. So EVEN WHEN ITS ALL WORKING
the engine still keeps on crashing on them when editing in blueprints…

So when it all works it becomes a powerful engine when putting in all the HOURS in wiring up all the classes or blueprints nodes and then the Ferrari will work and it goes all great until the tape begins to snap somewhere as soon as they do the next
engine upgrade. then its back to Brokeville to try to fix up Humpty again.

Well I suppose it is possible. But here is the thing… Macros… There are so many macros in the code it would be hard to count them out LOL… Not that my IDE’s of choice don’t support Macros but if you know anything about coding you know those type of operations do not pass over well from IDE to IDE… Of course there is always notepad++ but then it really isn’t organized which is something that is needed.

That was the nice thing about Unity (not that I would ever use it professionally)… They allowed for mono up until this latest trainwreck. It was default however Mono is C# and that is exactly why I like UE better :smiley:

>This is for programmers only:

I think this comes from people who try to learn programming while making games. If you can’t identify an error from a stacktrace or you are afraid to look into the engine’s source code or you are not able to use google to find an answer to your problem or you are not willing to change engine versions to get that feature that you want or you can’t be descriptive when writing questions or you are not willing to “read this tutorial first, then ask questions on google and then on actual people” state of mind or…i could go on… it’s nobody’s problem that you can’t get the hang of the engine.

Don’t expect this piece of software to be tolerant of your general lack of knowledge on the fields of: CS , physics, math (&geometry) , graphics , audio. Heck, I’ve seen people not willing to learn to speak english but still want to be into gamedev efficiently! If you want to learn to make games with an engine you should already know how to speak english ,write some code and know math.

</rant>

I know you get frustrated because the engine is “unstable” or your pak size on android is big or steam doesnt work in a packaged build or some random issue. Small parameters that most of the people probably ignore can cause a lot of problems but these parameters are what separates the pros from the noobs. You need to learn things from the ground up and there are plenty of resources to do that. I’d recommend thenewboston.com’s intro videos to programming and then some game making with a high-level wrapper for graphics and physics. After that , math for game developers playlist on youtube and ALL khan academy math classes. ALL OF THEM. If you don’t udnerstand something from a random video google it, find it and learn it. Then you can safely transition to the engine side.

The stereotype you described is my exact opposite :smiley:

No. I get frustrated because, as a developer, I’m struggling to make the engine work and not to make my algorithms work.

You didn’t answer my questions, though. What exactly would you like to see change in Unreal Engine ? How specifically could it be better in your opinion ?

  • You wonder in your first post about how big companies can get a game working. I’ve had a 70,000 lines project going on for two years. It saw every public version of UE4. There is just two of us, not a big company or anything, and we’re hardly spending our time debugging the engine. How experienced in C++ are you ?
  • You wonder when updates will stop : they will stop when Epic goes out of business. This is a game engine, it will be updated all the time until it doesn’t exist anymore, just like UDK was updated until it was replaced by UE4 and abandonned.
  • You complain about how Visual Studio updates break compatibility with the engine. Why is this even related to Unreal ? They’re not the one doing the breaking !

How the hell do you expect this thread to have any positive outcome ?

One year passed with unreal (with me having 0 gamedev experience) and now I got a game on steam. The only thing I have ever had problems with is physics which comes from me not having a proper understanding of how it’s implemented in-engine. Most of the problems are either solved by not daydreaming while watching tutorial videos or the livestreams or actually looking through source code

It has nothing to do with C++.
I’m an experienced C++ independent programmer.

Already answered. “When I ask for help on the forums, they most likely suggest me to upgrade”.
When something doesn’t work with my current old version, the first thing they suggest me is to upgrade to hope for an improvement.

So this keeps me from not updating the Engine everytime.

That was just an example. Not only am I forced to upgrade… I also come across incompatibilities.
Not only I come across incompatibilities, I also need to update my old code with the new supported one.

All of this happens just because, as said above, I’m forced to upgrade.

And all of this takes EXTRA time from attention and makes me lose my focus on MY GAME.

I never expect anything from anyone. Expecting just disappoints you.

I hope the Engine will reach a better and stable position.

You don’t really need to upgrade the engine to fix bugs. People might giving you bad advice here. Even if you check a release out to see if a bug was fixed, you can always go back. I usually have a Git branch for every new release, for example, so going back is just a double-click away.

For me it is all just a pleasant learning experience;
If I’d get soo annoyed about engine changes breaking things, I would instead go and download DirectXTK Games for Windows and the DirectX SDK blog | Technical tips, tricks, and news about game development for Microsoft platforms including desktop, Xbox, and UWP
and make my own “engine”, instead of wasting time with ‘somebody else’ mistakes…

But, I manage to find my way around the issues so I don’t know why some ppl be so angry when they face bugs.