hey jwatte, thanks for sharing your pov.
i agree with some of the things you say, but not so much with others.
are you implying that if you’re working on a really tight budget, with not so much skills, and your project is not hugely successful*1 then it shouldn’t be done?
I can’t agree with that.
i love indie games, and most of them can’t do this. i wouldn’t want a world were untitled goose game or undertale doesn’t exist.
epic is pushing really hard to help indies, something i’m extremely interested in, but without a solid engine, it’s not going to help.
*1 remember that you only get the money after the project is done and you sell the game. so most people can’t really afford to add extra dev cost before that.
what most people do is simply evaluate how things ARE (not how they could be) and evaluate cost/benefit.
and unfortunately that means people are choosing to go with the abusive practices of unity instead of using ue.
i mean that’s a literal reality as of now. people are still using unity instead of ue at this point.
and i’ve spoke with many devs who simply went back to unity after frustrations moving into ue.
and i’ve work in companies where ue was considered, but because it was very poor support for X, Y, or Z, then unity was used. simple. “fixing the engine” was never a possible solution. it’s not even considered. in fact “having to fix the engine” is seen as a “huge red flag” and reason not to use it.
in my experience, i’ve tried many times to “fix the bugs myself”, but i’ve learned the hard way that fixing bugs in engines of other people is swimming against the current, an uphill battle, that never ends. and it’s better to simply move to another engine altogether.
Besides, it’s not even about “if you have the resources you can fix it”, it’s about whether it’s worthy or not, and whether the work is wasted effort or real work. (Muda=waste if you’ve read about 3M).
one can deal with missing features, but only sometimes. and having breaking bugs on every release of the engine is virtually prohibitive.
agree. but also it’s the art of improving things.
“don’t live with broken windows” is a phrase some other devs taught me.
Simply accepting “there’s gonna be bugs”, it’s not really professional.
And not even legal in some cases. If you work in a company you’re legally bound to ship the software in good conditions, even if you loose money fixing bugs. I’ve been there.
In my experience, i have found that you can’t really afford to have an attitude of “let the user live with the bug”.
agree only partially. by the way epic is going, is actually making people go to unity already.
i’m a fan of epic and i’m working really hard to stay with them, but the truth of the matter is that these sort of issues makes it difficult to stay with them.
i work for a company, we work on a specific field with specific hardware, without 3rd party plugins we simply can’t work. those 3rd party plugins are behind and buggy.
those 3rd party plugins are really hard to implement, really big, and really hardware specific.
if you ever did reverse engineering you’ll know that implementing drivers for hardware you don’t have the specifications for is extremely difficult. (specially if you ever used open source drivers)
we can’t fix them. we’ve asked the company, they don’t fix it.
what should we do? close the company? or go to unity?
i tried that, many many times. it doesn’t work. the bigger the company the more difficult this is.
but let’s imagine it does work.
well, we could say that this thread is exactly that.
Ue is not working well, so we are asking epic to fix it.
usually we’ll use the bugform, but since that is not giving good results and bugs keep reocurring, then we go to the extent of proposing a possible solution.
So, in the end, this post is exactly what you are suggesting.
we are asking epic to fix the bugs. 
if i take your words literally you propose only 2 options:
- ask to fix
- don’t use it
that’s exactly what i’m trying to surface.
- please epic fix it
- otherwise people will use something else.
well.. i kind of partially agree. maybe most of the companies you’ve known fits in this category, but the ones i know are different.
besides success can’t be defined in absolute terms, it’s relative, and intrinsic to the organization.
and related to the is/ought fallacy. so i can’t assume the same metric of success for all companies.
neither say that their “success” is a metric for my success.
i’ve worked for companies where the bugs in ue were deal breakers. simply put. big companies that had the resources but it made no sense to fix epic’s bug. and what this company did was: moved to unity. simply. they didn’t even bothered.
agree but only partially. i’ve been studying about learning from mistakes and living in an imperfect world.
Having said that, i’ve spent many years of my life learning about better software practices and methodologies.
Bug-free releases are a solved problem, the information and methodologies are available and proved.
There are so many i won’t even bother to list them.
Imagine getting into an airplane and the software has bugs. Except that when that happens people die. Or a factory with furnaces the size of a house has a bug, people die. Or when you go to a hospital and the machine to monitor your heartrate stops or the one that counts the drops on your medication, people die. Bug free software is a solved problem.
People won’t die if ue has a bug, though they might loose their jobs, or fail to find a job (as exposed below).
But it’s a solved problem. Bugs happen, yes, but our job as devs is to fix it. And ensure it does not keep happening. It’s our job.
Of course i’m not talking about “quirks”. (a small hitch in the ui, some popup with a typo, etc)
The type of the bugs in the engine are not simple bugs. are feature breaking bugs, some re-ocurring, that are very blatant, that in “most successful companies” don’t occur.
In most companies i’ve work for, your work is not finished if it has a breaking bug.
A task is not done if it has breaking bugs. And the client will not pay for it.
It’s not professional.
Someone that ships code that breaks, is virtually as valuable as someone who does not ship any code. In fact, i rather the latter.
i’ve worked on a relatively small company that had a regular qa department, and we weren’t RE introducing bugs in core parts of the system, that weren’t really part of new features.
So it’s doable.
Games ship with bugs, yes, though not all of them, and it doesn’t make the matter better.
And they are not game breaking bugs. Imagine a game where one of the weapons don’t work, that wouldn’t be nice.
Also games make patches until it works well.
Which is something that Epic is not doing with ue atm.
Though i consider they have the skills and resources to do it.
If you take a look at the bugs in the bugform you’ll see what kind of bugs they are.
The bug that i’ve mentioned about retainer not working at all, it is a deal breaker for many games. I had to remove a feature from my game because of it.
It’s a big breaking bug, and simple testing would have covered that. Just try it, it does not work.
And it’s not lumen or nanite, it’s very old system, there’s no real reason to break it so badly.
What i wish to propose here, is not a perfect engine, but a better process for incrementally improving the stability of certain builds.