i agree with many things you’ve said. but i’ll try to keep on topic.
i do feel the communication to/from epic needs to improve rather sooner. it does feel like either they communicate not effectively, or there are much much less people, or they don’t care (something i don’t believe but they are letting people think that). And it’s creating confusion and dejection from developers. That includes things like bug reports.
i personally feel epic are being absorbed into many new features and fronts. At the same time you’re right, they have downsided considerably (many companies did around the same time iirc).
i agree silly bugs are quite unprofessional. and can’t be expected for the users to fix it. And it creates a big big problem for developers.
i can totally see why you’d feel disrespected and/or insulted. specially in regards to your time.
i do highly value my time as well.
i do believe epic has good intended/hard-working people because i’ve met them. i just think they are giving a bad image working like this.
this is actually a very important point in pro of an LTS version.
it would make much easier to publish content.
i create content and plugins but it’s not worth the time/effort to support more than one engine version.
that condition alone is killing many indies and first timers, which is what was holding back ue ever since it started. sad.
here’s another example, i won’t give specific details but this is a real world professional work scenario.
a project that has almost 2 years of work is stuck with 5.2 because at the time of starting it was the best version available.
we had to work with a 3rd party plugin with no bindings to versions past 5.3.
and even 5.2 has blatant crash bugs with relatively basic and old features.
so 5.3, 5.4, 5.5, and 5.6 are virtually out of reach.
i’d prefer an LTS without the latest 2 years features, but more stable. than 4 versions that i can’t use.
which btw, the new features are still not production ready so…
because the risk/cost of upgrading is too high, and the 3rd party plugins are not there yet.
one example: htc vive openxr still does NOT has support for 5.5 as of today. and has very recently had support for 5.4.
one might argue that htc is not that popular, but it’s quite big, and you can’t release to vive without it.
so if you want to use vive, you can not use 5.5 or 5.6. that’s about 1 year behind at least (i don’t keep track).
once again i rather have an LTS from epic, with improved stability, performance, docs. than having 2 versions i can’t use.
specially if it gives htc the option to keep improving their plugin.
i mean, professionally speaking i wouldn’t even risk with features like nanite or lumen, which aren’t even supported or release ready for vr. so newer versions have no selling point to me, (except minor QOL improves).
also i’ve been thinking that, by not having an LTS version, epic is indirectly forcing 3rd parties to keep a quick release schedule. which not only can be prohibitive for small companies, but also forces them to release buggy code (which i’ve seen in case of htc for example).
each release puts a ton of overhead on any 3rd party to port their plugins.
And i’ve been thinking whether it’s actually “paying the cost upfront”, but imnsho after thinking about it, i don’t think that’s the case for most situations.
so it’s actually a very pervasive issue.
It would cost EPIC more resources to keep an official LTS version of the engine.
Every version of UE can be LTS! All you have to do is to pay for it!
You can pay EPIC for support, and they will support an older version of the engine (for the right deal.)
But you don’t have to; you can do it yourself.
First, make sure you git clone the engine from the EPIC repo, and build it yourself.
Then, make sure you have a programmer on staff that understands the C++ and how to debug it.
Then, whenever there’s a bug fix in a later version, have your C++ engineer check the diffs for the bug fix, and fold them back into your own engine.
If there are bugs that seem to not get fixed at all, that engineer can track that down and fix those, too.
Overall, this will probably cost you approximately one full-time engineer, which seems like a reasonable price to pay if your team is big enough that this matters.
Although the EPIC support contract might actually be cheaper, depending…
Most companies are small businesses (1 or 2, sometimes 5 people, but mostly 1). So it would take me fulltime to clean up their bugs, leaving no hours for actual development. Times a million small companies to create a million fixed engine branches to be “their own”. I don’t see how that makes sense. If EPIC would wipe its own b"tt we wouldn’t have to? have you seen the number on the bug tracker? That will take about 10 fulltime EPICs with competent c++ engineers for one branch I suppose. Which small dev would (and could) pay EPIC for releasing broken code?
Or, EPIC pays small devs to fix bugs and work on an LTS. That sounds a little more interesting.
I know what you’re saying, we’re both c++ devs, yet I read it as “1. throw seeds at the ground, 2. wait a week, 3. free c++ specialists show up” in a funny yet dark way. That is what EPIC seems to radiate.
I’m already paying with my time either way, nothing more expensive.
of course it will. the thing is, i think it will have a really good return of investment for epic given the current state of the engine. and, the current state of the engine is not really good enough. specially for epic.
the cost of an lts is not that much. is just backporting bugs.
i don’t think current versions are at a good enough state to be lts. so i cant really agree with the idea of “any version can be an lts”.
imho an lts is more than “an engine that is used for long time”.
is not true though that “any developer” can backport engine bugfixes. it requires certain level of expertise. i have to agree with roy on this point.
it will be much more cost effective to have an lts provided by ue, than having the users maintain it on their side.
for example, i’ve considered making a fork of ue where the community could contribute to maintain a LTS version, but without official support from ue it’s basically wasted effort.
for example:
the issues with marketplace and 3rd party plugins wouldn’t be fixed at all.
the issue with wasted effort from epic in new features that nobody can actually use is not fixed at all.
you already pay epic for royalties, so paying for an lts doesn’t sound so good of an alternative to me.
they are generous in their licensing yes, but you still do, specially if you’re not making a game.
and it’s fair to expect for a product without recurring bugs on every release.
This is true. But i’ve even worked in companies with up to 80 employees. And still could not afford to fix bugs. even for engines 100 times smaller than ue.
They were very skilled devs, but still i don’t think they would have been able to perform all the required bugfixes in ue. None of them had experience modifying the ue engine. And if they tried, it would be much more costly for the company than for epic, for obvious reasons.
all and all, i don’t think an LTS requires much extra work from epic.
just to backport fixes, and fix all the bugs (which is expectable to begin with), once the fixes are in place, it does not takes any more effort at all.
i’m on discord, and i’ve seen quite a few devs getting into ue, and then abandoning because of the bugs and lack of support. it saddens me, but it’s true. i think epic could benefit from having a more solid stable release in this regard.
Besides the points you already mentioned, a public fork (by just anyone) on the engine would also take ridiculous effort to create visibility and trust, to be maintained as well, compared to an official branch. And when we look at the official branch, there’s no way to tell what fixes are going to be merged and when… Code is being deprecated in favor of experiments on the official branch, but no business will build its entire project on a fork (risky).
i totally agree. i was actually considering that. that’s why i basically consider it wasted effort. i don’t even consider the chance of someone will take it seriously ever.
and a company when confronted with the choice of supporting a branch/target, they will always choose the official one. always. considering they will mostly choose one branch to target.
i’ve seen this happening in opensource a lot of times.
i don’t think in this world HTC (e.g.) will spend time targeting a publicly maintained fork. considering, again, they are two version behind at their best.
(i mean, look at what happened with the ue wiki )
Also i was implying the fact that epic will likely not merge the changes on mainstream github. because that’s what sadly is happening on github atm.
And there’s another huge point. 90% of the people use installed builds.
even in big companies. In the company i’ve worked for, with 80+ people, they couldn’t spend the time to maintain a source version, and the artist team weren’t able to use a source build.
Having an LTS that you can install through the epic store is really important.
besides, it’s not like the community is not helping on fixing bugs already…
so what i’m wishing for, is not exactly for more work from epic, but more intelligent organization. https://github.com/EpicGames/UnrealEngine/pull
as i said before. LTS is not specifically work, is a way of organizing work.
so it supports the idea that it actually will cost relatively little to epic to implement.
People have been active on the forums to report bugs and give feedback. This process has not been perfected (at all) as mentioned earlier (our feedback isn’t processed by EPIC). As for the Github, I can’t tell. I have reported any bugs I found on the forums, so that even if staff doesn’t use the feedback, the community is able to respond. I have not contributed to the engine through Github, as I’m already out of time working on my own project, with this engine in its current state.
Work still got to be done. If it’s not more work from EPIC, but work done by the community, it’s still a gain vs pain situation. How can the small dev business contribute without making losses? If EPIC can come up with a program to support both LTS development and the community working on it then we could see improvements. The people who contribute “for fun” burn out at some point. It’s not fair.
You could literally pay EPIC dollars to have them fix bugs for you that matter to you!
That’s what their support plans are.
Or you can do what I do: Learn to live with and work around the bugs. Nothing is perfect! If a bug is so heinous I can’t make forward progress, I will fix it myself.
Yes, absolutely! But those people do exist (or, at a minimum, can be trained.)
If your project is big enough that it economically matters to the world, you can choose to allocate those resources for yourself.
If a marketplace plugin doesn’t work, then don’t use it? Or ask that developer to fix it. They may even be open to a small contract to do so.
I think your definition of “required” is different from that which most successful companies use.
Bugs are a fact of life. No engine, ever, will be bug free.
The point is to fix the bugs that are actually drastically impacting your ability to ship a real project.
Engineering is the art of trade-offs.
Would I take an LTS version if it showed up for free with no other costs associated with it? Yeah, probably? But it’s not like UE5 is so terrible, I have to use Unity and live with their business practices instead, just because there’s no LTS version of UE5…
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.
let me give you another example.
super meat boy.
the guy who made it, afaik, put a mortgage in his home. (something i’d wish i’d never do)
it’s quite self-evident that he could not afford to fix bugs in other’s people code. not with time, not with money.
should the game not exist? i don’t think so.
was the game successful? i think so. (9/10 for most reviews)
was the game made in ue? nopes.
also, i think that asking for breaking-bug-free software is the baseline.
living with broken software is not really acceptable. and sounds more akin to a Stockholm syndrome or cptsd to me.
a company the size of epic should be on top of this type of bugs, there’s no way around it.
Bug-free software is a solved problem. And for a company the size of Epic is not that a big ask.
i find the idea of paying a company extra, just to fix core bugs in base features simply preposterous (i don’t say it in a personal way, i’m talking about the idea not the person who said it).
it’s like going to the dentist and paying extra so that he does not damages your other teeth. in what world is that acceptable?
some bugs here and there for new features? ok.
recurring breaking bugs on core functionality on every single release? no. simply not.
I’ve worked in project where they were almost cancelled because the client was not satisfied with the bug count. and we spent a few months just fixing bugs, not allowed to introduce new features. so this way of view is acceptable/normal.
another example. look what happened in usa industry with the japanese cars. i don’t think i need to explain.
if you ship an engine that every version is unstable, your image gets damaged, until people won’t buy it anymore.
another reason why i find preposterous to pay epic to fix their own bugs are:
i’m already paying them royalties
i’m already paying them in other ways. like social recommendation
i’m investing with my life and my time (things i will not get back ever, and are potentially the highest value) in training and betting on this engine being part of my career for the rest of my life. once you become adult enough to value your time and your life, and the impact of these decisions. you’ll realize this is not a trivial decision, and that it matters
i’m already contributing my free time to fix their code for free
pay epic for support fixing my own bugs? ok.
pay extra for ensuring they do their job? not ok.
like i said i’ve used ubuntu and debian for 20 years or more.
at the start, a new version meant support for flash (when it was ubiquitous. for example in games and youtube), support for a wifi card, or support for a video card, or support for ntfs.
not anymore. ever since 10 or 15 years ago, i’m totally comfortable with kernel 2 years behind latest, since it has absolutely everything i need. Same thing with ue. I don’t need nanite or lumen. In fact, like i stated above i can’t even use it because the implementation is still lacking core functionality like transparency, overlay, and masking does not work well. And vr support is not good enough. So unfortunately those features are virtually non-existent to me.
in ubuntu/debian rarely, if ever, i encounter a breaking bug.
it’s extremely rare that i use a release with some blatant bug that i just “have to live with”.
in fact it’s even more bug free than windows in some cases.
unfortunately i can’t say the same for ue.
And that it’s not acceptable to me, and i know it’s not acceptable to many more people, because way too many times i tried helping people stay with ue, but they left (another thing i do for free but would be fair to get a compensation). Or the company chooses unity.
i don’t see why epic can’t sustain the same quality as debian or ubuntu. debian is not even for-profit, and ubuntu is FREE.
Either canonical engineers are extremely good, or epic could improve their process.
Actually i’ve met a canonical engineer and he was really good, but i can say the same for epic devs. So i think epic can improve their process.
another thing.
a recruiter told me recently a few months ago about ue vs unity situation. and i’ve did some checks on various sites.
and i’ve found that for each unreal job ad, i found at least 10 unity ones.
1:10 is a very poor ratio of adoption. And it’s a really high risk, that a dev takes when deciding to adopt ue. would you take a bet with 9/10 chances of failure?
epic can’t really afford to ship broken software.
because, those bugs, are simply, broken software. not minor, not new features, broken.
anyone that ever made a game (or product), knows that the player will judge your game in the first maybe 5 minutes of interactions and if you don’t get them there, you’re done.
in fact, it has been researched that people start to judge your game from the first image they see on the trailer.
if your first experience you have with the engine is “oh that core feature is broken in this release, and you have to spend 10 hours researching because it’s not documented, and the bugform is basically ignored, and the previous and next version also have other breaking bugs, and you have to ask on the forum and wait 3 days to get a reply by some random dude, and then you have to implement a fix in the engine yourself”, then you get really discouraged and leave for an engine where you don’t have to worry about that.
and i’ve seen that happen enough times on discord, to make me sad and irritated about it.
there’s an old quote that says “It takes a lifetime to build a good reputation, but you can lose it in a minute.” and epic is risking it atm imho.
and i say this admitting that i love people at epic. love is not a word based on objectivity, so what would you expect for those that are objective?
let me give you another example. i’m a lead senior engineer, and part of my job is evaluate products for adoption. engines, plugins, hardware, protocol, etc. constantly. for several years now. and i have to contemplate several factors.
i can’t tell you how many products we’ve rejected that had way less bugs than ue does. because it just not professional enough and doesn’t make sense from a business/engineering perspective.
for all that i conclude that epic is not really on a spot where they can have the luxury to release unreal as is now. since it’s broken software.
LTS is a simple, quick, easy, cheap, proven way to really improve the situation.
I’m literally getting self destructive because I can’t even click on a spline point or the engine crashes. I can’t even delete spline points without it crashing. I can’t even reset the spline points. I can’t reset the component by making it transient because apparently it still gets serialized. I can’t generate a circle of 3 points because one click generates a literal spaghetti view of 45 + up til browsing the next point crashes. I can’t update the spline component on an actor and have the actor update on the level as well. Long story short, when I need a simple spline, I apparently need Unity for that. ffs spline can’t even figure out its own time if closed loop is checked. Having the spline component added in c++ (defaultsubobject) makes blueprints choke on it.
epic could even be sued for providing software that is not free of defects, not talking about breaking bugs, defects.
of course, depends on their license, and i bet they have some limits on their responsibility, but still.
i’m not inciting people to attack epic, specially since i love epic and hate lawsuits.
but my point is:
“expecting defect-free software is normal, natural, and healthy. and it’s protected by law.”
i’m making a game about cptsd, and can’t help to think about how “sucking it up with less than ok, because what are you gonna do about it”, it’s a mark of abuse.
Look at this. Wasn’t able to use splines to calculate positions automatically so I decided for a “quick” workaround, moving around scenecomponents to certain positions. Even that is broken half the time (at random?). Is there anything that does work?
man that’s really sad.
i wish bps corruption and versioning would be solved by now.
it’s really painful.
so much wasted effort for gamedevs.
instead of putting time into making great games, and showing everyone how good ue is; one is stuck fighting with bugs.
I’m saying that everything we do, has a cost to the rest of the world. The world has a certain amount of resources and a certain amount of human time available.
The sum of all that time, all the work people put in, and all the resources created and extracted, is “the economy.”
How do we decide who gets what part of those outputs? How do we decide how to go about best using the resources? How do we decide that Bob will fix a bug in the UI widgets system, Sue will help a client in front of a judge, and Kim will plant rice in a rice paddy? That’s where the incentive systems come in. These come in flavors from “anarchy when everyone does anything they want” to “full totalitarianism where the Glorious Leader says what everyone does.” But, for most of us, the incentive system is “a more or less open market where we can choose to buy and sell goods and our time/skills.”
OK, so, if we want to make a change in the world, we have to make that change ourselves, or we have to incent other people to make that change (typically, “pay them to do it.”)
If there is a change in the world that someone wants to see, and they have money (or time) available, then they may choose to help others who want to make the same change. For example, if you want to build a game of a certain kind, and can convince an investor that this game would be a good investment, then that investor may fund your effort with money, presumably in exchange for whatever they expect to get out of the deal (anything from “philantropy” to “the bigger part of the revenues and credit for the game.”) This will help you make more changes in the world to make the game more likely to come about.
But, let’s say you have no good way of incenting investors, so you just have to do it yourself. And, because you also like to eat, you have to do this in evenings and on weekends, when you’re not working (or studying.) At that point, it’s up to you – you have to trade your scarce time for whatever actions are needed to get the game done.
And, most of the time, “fixing the few windows that have the most value” is a net positive investment, but “fix all possible broken windows” only leads to the actual game not shipping.
Now, if it really is a big deal that there is no LTS version, then you can probably make the world a net better place, by forking the engine, and announcing the project to “freeze” the version and only back-port bug fixes. You can make your changes available to other developers who also want those fixes. You can accept changes from other developers. As far as I can tell, as long as you only share with other developers who have UnrealEngine access on github, and don’t charge for the engine code, this would probably be OK. (But, I’m no lawyer.)
If it’s actually valuable to the world, the world will agree, and help you make it happen!
And this is not a passive-aggressive way of saying “that is a bad idea” – I honestly don’t know. It might be great! I would love to see you try it.
Another thing that I think is sorely lacking in the engine is comprehensive automated tests. The engine has a number of subsystems that are not structured to make testing straightforward, and while sometimes “abstraction costs frame rate,” most of the time you can make the same code and performance easier to test just by making that a design goal. There’s been a few token attempts in the past to improve the situation, but this is an area where I think the EPIC team and leadership just doesn’t have the necessary experience and background to make it happen and make it stick. This is one of the weaknesses of the engine.
But in the end, shipping the game is what matters. If you get too caught up on other things, that doesn’t happen.
Thanks for sharing your pov. Sorry if i missunderstood, sometimes it happens.
Ive readed your last post quickly, ill read better when i have more time and reply more appropriately.
Just one idea came to mind,
I love open source, so i agree with your idea of ‘if you want it try making it yourself, if its valuable people will follow’.
In my case its just that i want it, im confident is valuable (not “saying” sure to be generous), but i really dont have the resources.
Im already overwhelmed myself. And i dont consider myself good enough to maintain engine code.
But mostly i am quite confident that without official support from epic, other companies wont buy into using the project, and it becomes a chicken/egg for people. I think.
And without company support the value drops a lot. For example i work with htc, they barely support 5.4 which is quite old now.
bump. upgraded to 5.6 and found a few new and exciting bugs that weren’t there.
it’s like pokemon, each new release some new forms appear. gotta try-catch 'em all.
Formerly I thought that Epic’s marketing department crowded with blue and/or purple heads, as known as bad decision makers. But nowadays I think that Epic just trying to grab the balls of the industry as an another game of prevail imposed by China. Tencent owns %40 of Epic correct me if I’m wrong.
I love Unreal Engine, I born at 1997 and using a Game Engine was a childhood dream and Unreal gave that to me so I will always be loving Unreal Engine. But using it as a toxic asset on the market by publishing versions after versions as “Production Ready”; while as known by a lot of developers UE5 not even a complete product, annoying and upsets me.
have you seen the number on the bug tracker? That will take about 10 fulltime EPICs with competent c++ engineers for one branch I suppose. Which small dev would (and could) pay EPIC for releasing broken code?
)
