And what you are saying is basically: “Who cares if the engine keeps stalling and the brakes dont work, the car needs to have a flashy paint job”. 
[=bzinventor;296450]
What I’m saying is you’ll always have bugs and fix them.
[/]
You must be joking mate. We are not talking about bugs. We are talking about horribly buggy software. There is a big, big difference between those two.
Every software has bugs. Not every software is buggy. UE4 is buggy to the point of being unusable.
[=;296449]
And what you are saying is basically: “Who cares if the engine keeps stalling and the brakes dont work, the car needs to have a flashy paint job”. 
[/]
Couldn’t agree more.
I thought I’ll never say that.
The GI is necessary and has to be done once and for all. I’m not arguing here because this is not an argument, it’s a fact.
And so are numerous posts of people using Cryengine because of the UE4 GI issues
[]
because this is not an argument, it’s a fact.
[/]
We all make the world we live in. Your universe has some strange facts
But joking aside: Maybe for many people GI is a decisive feature. For many others, it is not.
So what are you missing from CryEngine that makes you even look into UE4?
It’s 2015 you have to have a Dynamic GI to compete with new engines - that’s the fact
I don’t have to prove anything as time will do it for me 
What do you think would happen if Snow engine was released for free (just a hypothetical). It’s easier than ever to make a new engine from scratch, in a very short time, because of all the resources R & D are already done. You have to adopt, or you will be phased out, no matter how “free” your engine is.
[]
Every software has bugs. Not every software is buggy. UE4 is buggy to the point of being unusable
[/]
Well, as they say: You only value things, if they are gone…
So I made a journey back in time and started a little project in some older versions of the engine.
I started with 4.2 and 4.3, all the way through 4.7.6.
I looked at two major points:
- Feature growth
- Stability
From what I felt in this time-lapse like impression was:
When new features came aboard (UMG), they also introduced their specific UMG bugs.
At the same time some other components became more stable (Lightmass, Blueprints, etc).
When the Blueprint functionality were extended, also some UMG bugs were removed, but not all.
Later, the Blueprint bugs got more and more eliminated, but not all.
So overall, as Epic sais and does, bugs get eliminated. Long standing bugs as well as bugs due to new added features.
But once the next set of features comes around the residual bugs remain.
This silts up the engine with more and more “minor bugs”. This could lead to death-by-1000-papercuts…
[]
It’s easier than ever to make a new engine from scratch, in a very short time, because of all the resources R & D are already done.
[/]
You are aware that “from scratch” and “already done” is kind of a contradiction? :rolleyes:
It would be if it was about the same engine.
Source Code for rendering techniques, resource formats, physics engines, compression methods etc are freely available online.
The technical area where UE4 falls down is a lack of full multi threading for all aspects of the engine. And I’m not surprised at this considering UE3 never used all the cores on a X360.
[=bzinventor;296486]
It’s 2015 you have to have a Dynamic GI to compete with new engines - that’s the fact
I don’t have to prove anything as time will do it for me
What do you think would happen if Snow engine was released for free (just a hypothetical). It’s easier than ever to make a new engine from scratch, in a very short time, because of all the resources R & D are already done. You have to adopt, or you will be phased out, no matter how “free” your engine is.
[/]
Probably you’re from more level-design oriented background if you really think that dynamic GI is more important than fixing project-breaking bugs See, you won’t be able to even use GI (or anything at all) if your project will be destroyed by, for example, some circular-dependency bugs at some point of development. Like @ said, it’s something like “Who cares if the engine keeps stalling and the brakes dont work, the car needs to have a flashy paint job” 
Your car is always going to be broken. While it’s running well you need to get a 4th wheel, as you are running on 3 at the moment.
The point is, you should have had 4 to begin with, and worry about fixing the engine
[]
You see, stability is far more than simply about crashes. API stability is very important too. etc, etc.
I’m not saying that UDK is perfect - far from it, but where stability is concerned UDK is far, far more stable than UE4.
[/]
Blueprints breaking is the biggest issue currently. API stability is fantastic compared to UDK: if you wanted subsurface scattering or tessellation in UDK, you’d have to sacrifice your whole hardware. If you decide you want to scale the landscape after it’s already made, you will crash the game. If you want to use Prefabs, not only was it exceptionally difficult to update prefabs, but they would almost certainly get corrupted to the point where you’d need to rebuild key features. I used UDK from 2012-2013 for school projects, and I even made a game in it for a local marine aquarium exhibit. I’m not sure if later builds of the old engine actually improved the stability, but everything from foliage to landscape to Kismet, prefabs, and even lightmass felt like it was a ticking time bomb. Yes, I lost a map in UE4 because I kept naming it different things. But if I changed the name of something in UDK, there’d be hundreds of errors right off the bat.
UE4 on the other hand just has a few minor things that go out here and there. Overall your file won’t get corrupted just because you tried to scale a blueprint object or the landscape, and you don’t have to fear losing hours of work because of an inexplicable crash that happens when you build lighting. You can change the name of levels and move them from folder to folder without fearing that it will be gone forever, and autosave no longer causes the engine to crash (ironically, that was another source of frustration with UDK, hence the new “autosave countdown” feature and its ability to postpone saving until it’s safe to do so). If your idea of a stable engine relies on the frame rate, just adjust the post processing, use less stationary/dynamic lights, and instead of a dynamic reflection environment, use a skylight or ambient cubemap for a reflection. By default, a lot of UE4’s “look pretty” settings are turned on very high, but you can turn it down a few notches for a more reasonable result. Batching will help this engine a lot, so hopefully the 4.8 build will wind up being even more stable than it already is right now, and in my experience, even the very most unstable experiences in UE4 seem extremely tame compared to the average errors I used to get in UDK.
[=;296592]
Blueprints breaking is the biggest issue currently. API stability is fantastic compared to UDK: if you wanted subsurface scattering or tessellation in UDK, you’d have to sacrifice your whole hardware. If you decide you want to scale the landscape after it’s already made, you will crash the game. If you want to use Prefabs, not only was it exceptionally difficult to update prefabs, but they would almost certainly get corrupted to the point where you’d need to rebuild key features. I used UDK from 2012-2013 for school projects, and I even made a game in it for a local marine aquarium exhibit. I’m not sure if later builds of the old engine actually improved the stability, but everything from foliage to landscape to Kismet, prefabs, and even lightmass felt like it was a ticking time bomb. Yes, I lost a map in UE4 because I kept naming it different things. But if I changed the name of something in UDK, there’d be hundreds of errors right off the bat.
UE4 on the other hand just has a few minor things that go out here and there. Overall your file won’t get corrupted just because you tried to scale a blueprint object or the landscape, and you don’t have to fear losing hours of work because of an inexplicable crash that happens when you build lighting. You can change the name of levels and move them from folder to folder without fearing that it will be gone forever, and autosave no longer causes the engine to crash (ironically, that was another source of frustration with UDK, hence the new “autosave countdown” feature and its ability to postpone saving until it’s safe to do so). If your idea of a stable engine relies on the frame rate, just adjust the post processing, use less stationary/dynamic lights, and instead of a dynamic reflection environment, use a skylight or ambient cubemap for a reflection. By default, a lot of UE4’s “look pretty” settings are turned on very high, but you can turn it down a few notches for a more reasonable result. Batching will help this engine a lot, so hopefully the 4.8 build will wind up being even more stable than it already is right now, and in my experience, even the very most unstable experiences in UE4 seem extremely tame compared to the average errors I used to get in UDK.
[/]
We are working with very different UE4’s and UDK’s .
And what about 's map being lost? Would you also consider it “minor thing that go out here and there”?
Seriously, I’m reading your last post and when I see something like:
“you don’t have to fear losing hours of work because of an inexplicable crash”…
Did you read what happened to ? If so, how can you say such thing “you don’t have to fear losing hours of work because of…”.
Unbelievable.
[=bzinventor;296528]
Your car is always going to be broken. While it’s running well you need to get a 4th wheel, as you are running on 3 at the moment.
The point is, you should have had 4 to begin with, and worry about fixing the engine
[/]
What is your background, that is would you consider yourself more of a programmer or artist?
[]
And what about 's map being lost? Would you also consider it “minor thing that go out here and there”?
[/]
Compared to what used to happen in UDK? One map being lost is nothing. You have autosave that doesn’t cause things to crash, you have the ability to name and move maps between folders without losing references, you have the ability to build lighting without crashing, etc. etc. I had classmates who had 6 weeks of work lost because of a combination of crashes and file corruption: they couldn’t even use the autosave files because those got corrupted, and references broke profusely.
No, it’s not good that someone lost their map in UE4. This shouldn’t be happening at all. But compared to the issues that used to happen in UDK, and the severity of these issues in UDK, just the comparison alone makes UE4 an infinitely greater engine to work with. I made an entire game using Kismet, and the whole time I was doing so I felt nervous about everything.
Guys, I’m not sure its useful to keep comparing UE4 to anything else. The fact is, we should expect perfect stability and usability as the target no matter what it is we’re using. Of course that can never be achieved, but the question is how do you move towards that goal.
The issue right now, is that there are still plenty of crash/breaking bugs. Once my schedule is a bit less frenzied (end of term) I’ll do a quick test and see how long it takes me to crash the engine or find a feature that causes what would be a game breaking bug. We used to do this kind of thing on the games we were making for consoles. If you could make it beyond a specific time (think it was 24 hours, but can’t remember exactly) you were OK to ship.
I highly doubt you could get UE4 past an hour. Which I don’t think is what you’d say was acceptable for mainstream software. Of course we all learn where the majority of mines are in the minefield and learn to avoid them, but I think if there’s going to be real progress you have to start thinking about tools for mine detection for instance
It’d be really nice if things could get less about specific feature sets and more about how to engineer a better process for this particular aspect of stability and usability. How does the engine team plan on improving their process etc.
Honestly, I’ve been out of mainstream game dev for a while, but I remember that with the best will in the world, game code was never really engineered for long term stability. But I think the circumstances of the new engine model should maybe give pause for thought on the development process. I appreciate that Epic have gone to this preview build model, but to me that is like trying to fix the door after the horse has bolted. Sure we can help test, but testing isn’t really the issue, the issue is code quality in the first place. Fixes earlier in the pipeline usually give far more benefits. So things like better code review, more discussion of public API designs, actually trying to think long term how to improve development process etc.
[=;296623]
Compared to what used to happen in UDK? One map being lost is nothing.
[/]
It shouldn’t happen. Full stop. If it happens it is equivalent of saving file in word and not being able to open that file. That says that the software is of really poor quality.
[=;296623]
I made an entire game using Kismet, and the whole time I was doing so I felt nervous about everything
[/]
Agreed. I’m making game in UDK and it feels like sitting on a ticking bomb.
[]
It shouldn’t happen. Full stop. If it happens it is equivalent of saving file in word and not being able to open that file. That says that the software is of really poor quality.
[/]
You can do a lot more with Unreal Engine 4 than you can with Word. I’ve had Word, and Adobe software crash on me, too. It’s unreasonable to expect a software to be 100% bulletproof, especially if that software has thousands of different features and settings intertwined with each other. I’d rather get optimization updates like gpu particles, shared samplers, and batching than for Epic to just spend forever fixing every bug known to man.
[]
Agreed. I’m making game in UDK and it feels like sitting on a ticking bomb.
[/]
use UE4. One bad experience from one does not represent the experience that will have with the entire engine. I’ve seen too many users (myself included) with awful experience in UDK to recommend it to anyone. But UE4 is not a ticking time bomb. At the very least, you have to give it that.
[=;296693]
You can do a lot more with Unreal Engine 4 than you can with Word.
[/]
But you cannot write docs in UE4.
[=;296693]
I’ve had Word, and Adobe software crash on me, too.
[/]
Couple of times a day? Every day? Because that’s what happens when you work with UE4.
[=;296693]
use UE4. One bad experience from one does not represent the experience that will have with the entire engine. I’ve seen too many users (myself included) with awful experience in UDK to recommend it to anyone. But UE4 is not a ticking time bomb. At the very least, you have to give it that.
[/]
Judging by the numbers of threads reporting crashes of UE4 (and my own experience) I simply cannot agree with you. Oh, and it is not one bad experience from one . If you look through this forum you will see plenty of evidence that plenty of people complain about instability of UE4.
You will see a vocal minority who are hitting these problems, but it is by no means the majority of users - more to the point Epic are using the very same engine/editor internally to develop at least two projects (UT and Fortnite) so the editor/engine can’t be as bad in the majority case as you are saying.
That’s not to say you don’t have problems but clearly those problems that you and others are dealing with are being caused by something which Epic, internally, are not doing and thus aren’t catch pre-release. Does it suck? Of course it does, but claiming the engine is unusable is just clearly false.
Indeed the fact that some of you are hitting problems that others aren’t seeing does, for me, make the whole ‘stability/zero bugs’ thing somewhat unworkable. Clearly you guys are doing something which Epic isn’t testing, so even if they put out a build with all known bugs quashed chances are upon release you’d still hit paths they haven’t accounted for simply due to your use cases.
UE4 isn’t some thing that has been thrown together and chucked out the door for others to use while internally Epic are using some Super Secret Master Build to do work; they are dog fooding the engine the same as you guys so if it really was as bad as you say there would be no Fortnight or UT in the state they are in right now.