2019.3 entered the final stages of beta testing

The UX team is not going to be tasked with building a game, especially in conjunction with the artistic team that produces beautiful but expensive art (talking about importing assets) because their testing/feedback would be quite irrelevant and the task is too expensive. Please explain, how do you propose to improve their UX team?

I'm sure there are already plenty of background processes, but how can you measure the effectiveness of these processes if you haven't got a project to work with?

I also disagree with you on this. The whole point of an engine is that the only custom solution that you need to have is your gameplay. The editor should be agnostic to every project made with that editor's version so your rendering pipelines, console support and so on should work on anyone's computer.

When talking about being tied to one editor's version, wouldn't it be safe to assume that anything newer than the version used to make their game would be a safe choice (specifically LTS releases) as newer "usually" means "better"?

If custom solutions are needed to build a game, what value do I get from using this engine then?

Anything from here leads to the 2020 release, which is all based on modules. A modular approach means that you can include only the engine's features that you need but what proof do we have to make sure that these modules are as good as they're advertised?

Please correct me if I'm wrong.

 

1 Try importing any large or small set assets, the editor is blocked during that time. ( This is planned to be fixed on the roadmap )

2 My experience with any demos from unity is that they only worked in a specific unity version. Try opening the book of the death in the latest LTS version. Last time I tried it did not work.

 

Unity needs one unified standard pipeline and one standard format for SRP project.
If you want open Fontainebleau demo or Book of the death with newer Unity, you will come across obstacles.
Future practicality should be one of the main foundations of standard format.

 

This is a terrible idea because it basically means you need to have a graphics programmer on your team, otherwise you're either dealing with pipeline overhead or a pipeline that is missing features that your project needs. This is one of the reasons they're trying to move away from the Builtin renderer in the first place.

 

We're not thinking on the same thing.

 

Then you're not describing yourself well.

 

Yup, but it just shows how Unity use their own engine. Instead of making robust improvements like Epic (read their last blogpost on Niagara -- Unreal's VFX Graph) they just create tons of workarounds and hacks without general approach which will work only for the specific Unity and Packages version.

The problem is not that making games will lead to hacks and stuff (in general). The problem is that UT fundamentally makes bad design decisions when they have access to source code. What you can expect from us, who don't have such a privilege?

When I saw Book of the Dead and FPS sample I thought a lot of stuff from that will be upstreamed to the engine. But boy oh boy, Book of the Dead doesn't even work on HDRP now.

That speaks for itself.

 

You just described two major problems that would be quickly fixed if there was a team inside Unity who was forced to experience them in the flesh, every day, while trying to meet deadlines and tend to angry gamer reviews. But since they don't feel the hurt themselves and only hear about it from rabid forum posts, it hardly takes priority.

I'm strongly of the opinion Unity should have a couple canary projects in the wild: actually published, regularly updated, multi-platform games. These games should be crashing the editor, becoming fully pink after an upgrade, failing certification, and having their updates rejected from the AppStore and Google Play long before said betas and alphas are unleashed upon us.

Something like Book of the Dead, for example, is out of tune with how actual Unity game development works. Since they have no obligation to scale it into a full game, it's full of brittle hack-ish solutions that won't survive an Unity version upgrade, instead of pushing the engine team into creating solutions that could be shipped to customers. Try scaling those high fidelity assets into a 10-hour game and see how far you get before the editor starts bursting at the seams and you have to break things into multiple projects, loading externally built asset bundles in the editor and writing custom editing tools since your scenes no longer can be edited in a WYSIWYG fashion.

 

This was 7 years ago ... it looked amazing, and it required a lot of custom tools. I'm not sure if any of those custom tools ever made it back into the editor?

This illustrates what I meant, its not just about unity making a game or a cg short, its about making the custom tools required for those kind of projects available in a user friendly way and work across multiple unity versions. ( not just a lot of scripts but actual editor tools )

 

On the other hand, what could solve this effectively without using a bunch of resources in an incredibly time consuming and expensive matter, would simply be listening to the community, something that Unity has kinda shown themselves to be increasingly bad at, especially following the 5.x release cycle.

For instance, the terrain system has been in a bit of a state for ages and one thing people clamored for for literally just under a decade before the Feedback site was shut down was a voxel based terrain system that could handle things like overhangs and caves without a series of hacks. This was the most voted on feature request on Feedback since voxel terrain was introduced into CryEngine ages ago. What do we get instead?

New brushes and an alpha clipping solution with some minor collision tweaks that are currently broken in 2019.3, which is still slated for release in the coming weeks. And this is just one example of many.

Unity making a game is an inefficient alternative to them taking proper feedback from the people who use the engine day in day out.

 

New Landscape tools are in for 2020.1/.2. I suppose new tools require change of API which is the reason for waiting.

 

Just windering.. do you think anyone at UT is reading this thread or is it just us complaining to ourselves?

 

I think they are reading that but it doesn't mean we are complaining to anyone except ourselves.
Our complains start in a polite manner, but the more we left unnoticed, the more aggressive and hostile we become. I try to avoid that, but it's so hard to not being salty.

It's funny to see such a character development when reading old posts from familiar people. At first they were like "hey guys, I have a suggestion on improving workflow", now they are like "screw that, I lost my hope, you do nothing".

The best part is when people get pissed off some guys from UT come to a thread and tell them to deliver a constructive feedback instead of a rant. But where have you been all along?

People give constructive feedback (that thread as an example) --> people left unnoticed --> people start being disappointed --> people start a rant --> someone from Unity comes and tells everyone to keep a civil discussion and give a valid feedback.

But maybe we are just a irritating minority which only yells on a forum? This makes sense to me. At least I can understand why all the stuff is being ignored for years. But some recent reddit and twitter popular posts says that this is not a bunch of crazy old dudes yelling at cloud.

 

The terrain tools you're talking about are the ones I mentioned, which are absolutely bunk compared to what people have been asking for for nearly 10 years.

 

Unity migrated away from the One Size Fits All approach that was the "built-in renderer" because the idea behind a universal solution didn't work. Some people need a high-end renderer, some people need high performance, etc. Your idea would be a step backwards.

 

Next >

From a UX perspective one flexible pipeline actually makes sense. I like the Microsplat terrain shaders: I can click on checkboxes and drop-downs to enable and disable higher-end features. If I disable features, the shader runs faster. A simple tradeoff. Each option comes with a warning about what I stand to gain (quality) and where my project will take a hit (memory/cpu/gpu). Why can't there be one Unity SRP which also works like this? This would streamline development and make Unity much easier to learn. My prediction is that URP will disappear in a few years - either discontinued or merged into HDRP (which will be renamed Standard Render Pipeline).

 

Yes, I think some Unity staff is watching this thread.

I think it's the "regular folk" (non-management) who is reading and these people are most likely not in the position to talk about the situation, it's not their job. If they would do, they would probably get in trouble. I imagine some of them raise this issue/thread at their supervisor or however this works inside of Unity Technologies.

For Unity staff it's hard to participate in a thread like this, because the thread turned on a personal level. I guess that's when Unity regular folk turn into "read only mode", because they might cause more harm than good and become the target of future attacks/insults, even if they personally have nothing to do with it and just wanted to help.

I guess at some point, probably next year mid-January (after holidays), we will see a blog-post how they plan to address the current situation.

 

When are holidays over? Is it January 6th or the week after ?

 

Why do you think that it would be ineffective to use their own product? Being directly exposed to the experience themselves is probably one of the most effective things a company can do to validate their products. If they don't like it, what is the probability that others will?

The situation gets tricky when management and leaders within such company are biased and delusional (I'm referring to how they take feedback and constructive criticism), then there is truly a problem and it can (will most likely) sabotage the growth of their product in the future.

A company should always take feedback, there is no alternative to that. But it is also important to assess it as often as possible. There is a lot of ongoing feedback (mostly negative) and criticism so what better way of compiling all the issues into a game? You have a higher chance of fixing the issues if you can work with them directly.

There is a lot of raised issues that UT cannot replicate and therefore are closed off. How do you deal with that?

 

The reason it's inefficient is because Unity would have to pour tons of money and manpower into developing a triple A quality game for the sole purpose of finding out where Unity fails to scale. That would come at the expense of further engine feature development and bugs fixes.

As far as I remember Unity mentioned some time ago that in recent years they've started working closely with studios in order to understand what people actually need and where the engine fails to scale. This makes a lot more sense than forcefully developing a large scale game for feedback. If they actually wanted to release a profitable game then that's a whole different story.

 

BTW, this thread as gone wildly off rails. It started as a post about letting us know that 2019.3 is being delayed in order to release a more stable version. It turned out into a rant party where everyone complains about different things that are not necessarily related to each other.

It's valid to complain that Unity is unstable, but the fact Unity is delaying 2019.3 is a proof they care about stability.
It's valid to complain that Unity doesn't scale well at very large projects, but they are working on adding things like "on demand asset loading" for the editor in order to improve the usability.
It's valid to complain that Unity doesn't listen to feedback, except it's half true. Unity is such a large company with so many different teams that it's easy to pick some areas\features that Unity neglected and paint the entire company as unresponsive. Wasn't the new input system been delayed multiple times because the devs actually listened to user feedback instead of releasing a half baked feature?

Ugh, I really suck at delivering my point so I'll just summarize it:

1. It's not like your complaints are wrong. There's definitely room for a lot of improvement but I wish people wouldn't make it look like the entire engine is bad and the entire staff is unresponsive.
2. The complaints here should probably have been in their own threads instead of taking over this one. I hope Unity won't "learn their lesson" and lock future stickied threads instead of allowing open discussions.

 

I'm not gonna argue against it because there are plenty of unity3d games that are quite successful. The argument comes in regards to how frustrating it is to build games with unity.

And yeah, of course, money is the biggest factor here. But one could argue that the biggest factor is the usability of your product, and if people are unhappy with your product, you might see them moving somewhere else. How are you going to make money then?

To me, it looks like an investment rather than anything else. You invest in your own product to make sure it meets your customer demands.

 

I think the rant started when someone picked up on the number of unresolved bugs in this release and yet this thread has been titled "Final stages of testing".

I agree with you we seen remarks of improvement and I love this engine to bits. I also don't want new people coming into the thread and thinking this engine is unusable because you can literally make a decent enough game on a weekend. But there have been some good points in this thread and I hope UT staff acknowledges it

 

Better to let us all vent and rant in one single thread than inundate the forum with a massive number of separate complaint threads.

 

I have transitioned from rants into positive encouragements and polite requests. It is superior approach in the long-term.

Fontainebleau demo and Book of the dead is good start but needs holistic treatment with integrated workflows within Unity rather than separates and locks itself in only one Unity version which isn't usable in future.

 

Unity would do a great service to its user base if they would take all of their demos to this day (ALL of them), and upgrade them to URP or original pipeline but on the latest version.
I’m split on the issue of having custom shaders and patched code in the demos. On one hand it makes them unusable out of the box in other projects, not as builtin engine features or packages, but on the other hand they do show you the flexibility of the engine to make your own rules. From what I gather so far most successful games make custom adjustments and optimizations to the render pipeline / shaders etc to fit their needs, so it’s not like Unity doing it in their demos is abnormal, it’s just harder for us who don’t have the resources or knowledge to do that.
Simply keeping the demos up to date with the latest Unity versions would do SO much, instead of abandoning them. One of the projects even has in its GitHub readme a statement that this project will be kept up to date and the last commit was a year ago. Seriously.

 

I updated my project to this latest beta, but something as basic as multi-scene lightning is broken, the lighting is not updated when changing the active scene (broken on build too). I had to go back to 2019.1

The editor is slower as well, and I was already having problems with editor performance on 2019.1

 

Because making a game is a dramatically inefficient process for this sort of thing. Using your engine is something that can be done in basic testing based on feedback and is kind of a natural extension of how bug reproduction and tracking works, but for workflow issues.

Making a game is slow. Making a game is expensive. On top of these two very big problems, there are a billion tiny problems, and those are every problem with the Unity engine that has existed for years now. What game do you make that addresses enough issues? If you can't address the issues all at once, do you make multiple games? If you make multiple games, how many? Games take a long time to make, how long will it take for these fixes to get backported to the engine? How long until they reach a mature enough state that they can even be used in production? Games require a lot of work, who will be working on these games? Will they be drawn away from engine maintenance and development?

These are just some of the issues that come with a game focused approach to internal engine testing. I haven't even touched on the noise factor, like what features should even be implemented at all. Sometimes certain features seem invaluable for the current project but in fact have very limited use cases. This is something you can see with Unreal, an engine I still keep trying to give a chance because of the various Unity issues. Unreal is really powerful, but the minute you try and do something Unreal doesn't natively support, you're basically walking into the desert. That's another problem that comes with using your own engine for gamedev.

 

Fontainebleau demo is perfectly fine. Everything in that project got upgraded to HDRP default workflow a long time ago (Using Shader Graph, VFX Graph, Physical Sky, and all the shaders before were default Unity shaders except the lens flares which is now working properly.) and the same thing is happening with Book of the Dead. You can get the current version of Fontainebleau Demo that works with the current Render pipeline and will upgrade smoothly on Github and it's being updated fairly regularly when there are changes with HDRP. It's been free from any locked HDRP version for a long time.

https://github.com/Unity-Technologies/FontainebleauDemo

Changelog to see the changes
https://github.com/Unity-Technologies/FontainebleauDemo/blob/master/Changelog.md

 

I totally understand the frustrations you guys have regarding Unity, stability, and feature creep. I think fixing these issues is important.

But I'd rather Unity just release the full source code to the engine. Everyone has a different philosophy regarding engine complexity, features vs stability, what platforms and frameworks to continue supporting and what to abandon. Unity always advertised itself as a democratic game engine, so why not give every developer the means to change the engine to fit their needs?

This is still the biggest issue that plagues Unity developers, where just about every other game engine out there allows developers to modify and build the engine source code for free. Unity is going in the right direction by open sourcing many of their packages and being a big part of Microsoft's .NET foundation. But the underlying engine bindings on Github are reference only, so you can't even suggest critical fixes.

Every new release of Unity is filled to the rim with bugs, and Unity developers can't even fix these bugs themselves. Old frameworks, features, and platforms have been removed, and many of them for the better. But what if the developer wants to continue supporting X platform on a newer version of Unity? They would have to contact a sale person and spend all their $$$ to get a source code license.

Many developers don't have very much money. They should be allowed to have full access to Unity's source without paying up front for a hefty license. I'm sure this has turned off many talented developers.

 

Maybe that is Unity goal ... they just tease what you can with whole marketing, rest is up to developer.
"Want to spend $$$? You are more than welcome."

 

That will work for a lot of problems. Unity has to take advantage of a passionate and big community. There are more people willing to contribute and make engine better than in every other open-sourced engine.

Look at the Mirror for example.

But they can't make it open-source because of lots of legal issues. Epic had to rewrite a lot of stuff to make UE4 open-source, it relied on lots of third-party stuff with different licensing.

 

Also even though Epic went open source, it didn't really help much in the long run. Once the engine reached a certain point pretty early on in its release, source access didn't result in many merges. The reason is simple, of course: UE4, like Unity, is a monumental code base and takes either ages to end up familiarizing yourself with and also tends to take a few engineers as well.

Source access is a fun idea, but it's not the game changer people think it is.

 

I know this is a 2019.3 thread but I just wanted to sound a more positive note than some of my earlier comments to say I’ve just started dabbling with the latest 2020.1 alpha and have been positively impressed so far. It feels more solid; like loose knots are finally starting to be tied together into something more coherent.

 

Actually there's tons of merges from hundreds of game developers (outside of Epic) on every single big release. Developers are able to fix critical bugs, add features and compatibility to an otherwise monolithic game engine. Many developers are making ambitious game projects, like the reimagined half life project, because developers are able to modify the rendering and physics engine. In Unity, this project would use expensive physics simulation using C#, because the developers can't just modify the C++ physics engine built with Nvidia Physx. Now you hear Unity bragging about bringing Havok physics into their engine for the first time. The HPC# version (Unity Physics) is stateless and brand new, so it's filled with bugs, and lacks the same performance and stability of the C++ version (Havok). Unity developers can pay for a license to play around with a blackbox version of Havok physics, while Unreal developers get to experiment with Chaos physics with no license fee at all.

 

This might sound a bit off topic but I believe it has a direct relationship with the current state of Unity 2019, being a tad buggy and slow. But bare with me.
On every Unreal release, there's a huge number of community bug fixing contributors. There's even a section in the release notes of every update for that. Yeah, community bug fixing has a huge impact and it can even easy out the pain Unity developers itself are having. Unreal Engine source code is massive yes but it's also very clean and well structured in modules. Have you ever take a look at? Quite often the fixes you do doesn't have any impact elsewhere. But just pointing out where the problem comes in the source code can guarantee a fix for a critical bug many people have.
Unity have now the means and power to allow anyone get access to source code. They can re-negotiate with existing third party middleware or even provide compiled Dlls for such cases and the rest of the engine modules provided as source. Better than nothing.
On the other hands I wish I could add some minor changes to the built-in renderer so NGSS users can benefit from a tighter/rich full integration. Yeah I know, SRP is there for that same reason but is not really "production ready" in my book.
PS: Pardon my English, I'm a French Canadian.

 

Imagine a game studio working on a 200 hour RPG. Would you trust the game to be stable, engaging and balanced all the way if the developers never had any QA people play it from start to finish several times?

One month synthetic projects/demos/samples are the equivalent of only playing 2 hours of your 200 hour game. Relying solely on external feedback and bug reports is clearly not working. External feedback is useful, but paints a much less detailed picture than daily reports, for example.

Imagine if you had a member of UT visit your office every day and talk to your devs to collect feedback, and you could show them on your computer what the problem is. Or if you could freely walk over UT offices and discuss issues with them on their desks. Can't you see how that would improve their notion of what things should be fixed or improved?

Many of the biggest problems with Unity show up when your project starts getting large. By that point it becomes nigh impossible to create reproducible bug reports. If you're working on a large project, you probably also have the resources to work around issues by creating custom tools and pipelines, or even by purchasing source access (the seamless streaming in Playdead's Inside, for example). If your team doesn't bother to take the time to write detailed reports to UT, and someone at UT reads and escalate those, none of that will result in actual changes in the engine.

You say UT actually using their own product to its fullest is inefficient. I respectfully disagree: there is a major quality difference when you actually use and depend on the tools you write versus just having someone else use it and report back when they feel like. It's called eating your own dog food, not just giving it a sniff and maybe a lick.

 

The source access is the primary reason big companies use UE4 for their AAA projects and scoff at the idea of using Unity for anything outside of mobile. Experienced devs hate black boxes, period.

It does take engineering effort, yes, but the possibility is always there, that's the biggest point.

One of the best things about SRPs and packages is how much of it actually has source code you can read and modify. For example, I'm using AssetGraph and was able to modify the ExtractSharedDependencies node to better suit our use case (made it 100x faster and made bundle naming more deterministic). None of that would be possible if it was locked in the black box.

 

Don't forget to create a pull request :^)

If you didn't rip some functional stuff for your project needs of course.

 

Oh, yes, I already forked it with that purpose and do plan getting to clean up the changes and make a PR. The dependency collection step was taking over ten minutes for us (extracting shared assets from over 1500 scenes), I added some local caching and brought it down to a couple seconds.

The naming convention change can be controversial, so maybe I should add a checkbox or drop-down option to toggle it.

Source code access rocks. Period. I acknowledge more accessible source access would go against Unity's subscription model (since you can compile away the licensing checks from the editor), but it would be fantastic if they at least managed to do it for the Unity Player, while keeping the editor source license separate (that's how CryEngine did it back in the day).

 

As for source availability, it's never going to happen with full Unity but I think you get most of the runtime code for DOTS and this is the direction Unity is heading at. Main thing missing is the native code side from renderer IMO and this can be problematic as you are still at the mercy of Unity to get the bugs fixed on that side.

As for source code usability, it is a huge thing in favor of UE4. I could (and did) for example modify their physx integration in few days to implement physx contact modification support for UE4 where it's impossible for user to expose in Unity because it's in the closed engine side.

I have bunch of PRs merged into official UE4 and I have my UE4 fork that I maintain that does all kinds of custom stuff, I'd love to do same with Unity but instead I'm very limited to modding packages (the few that exist in github in the first place).

C# packages and SRPs help on renderer modding a lot but I still file a lot of bug reports for things that are broken on the native side of Unity (as I have no means to fix these myself). In ideal world bugs wouldn't exist and Unity would always fix all issues asap but since we are not there, not having full source for the player is a big risk for people doing games with Unity professionally.

 

Imagine a game engine developer working on a 200 hour RPG. When the hell are they working on the engine? Who is? How much money does this cost?

External feedback, as mentioned before, is not even being properly used. They have sat on their thumbs and used external feedback so infrequently that it was determined that the external feedback part of the site wasn't even worth keeping around despite the most requested additions, fixes, and improvements never even got implemented.

They already do this with external studios, but really only ones that can afford it. This is why they need to listen to more feedback.

And many more of them are plain on their face issues that have been around for ages. You're ignoring a huge part of the problem and attempting to gesture towards another problem as if that makes the first one go away.

I'm saying it's inefficient because making a game diverts resources like finances and developers away from the engine and requires bringing on even more people because if you're making a game more complex than the FPS sample you need to do a lot of stuff to get that to work. This is something you should understand after bringing up your 200 hour RPG point.

Eating your own dog food isn't a cure-all and usually has you die of malnutrition because dogs don't eat like people do.

 

I am not KokkuHub, but I can't just read those strange points.

I don't understand the point you are making. Why are you trying to force the exaggerated example of a "real project"? Why it should be 200 hour RPG? Why can't it be a multiplayer shooter or brawler, whatever. Why can't it be a 8-hour linear action game? You are trying to make an argument in favour of your opinion just because you want to sound reasonable.

Yeah, this is why they have to get their own feedback and feel all the pain for themselves. When you have abstract problems that happen to external developers it's not so easy to believe that some stuff is urgent, like nested prefabs or good UI system, or terrain tools. For example you can prolong those features for the next 9 years, huh.

This is just not true. Using your own engine for a important project and not a tech demo is a good motivation to keep your engine bug-free, stable, performant, scalable and productive.

Yes, they do get better feedback from external studios. But there are some people who worked with Unity and sent them bug reports and guess what.

Don't try to force that opinion which is based on a strange arguments. Unity has a demo team and the team which makes small projects. Merge them and give them a big project (at least not a demo showcase) which will keep them occupied for a year at least.

I can't imagine a robust game engine from people who use it only for small stuff, researches and demos. Yes, external feedback could be enough in theory. Only if you have a strong and perfected communication with your own community. Unity doesn't have it, never had and won't have. There are billion of reasons for that.

Look at how the major studios rip Unity for their projects. For example, Escape from Tarkov have lots of stuff rewritten for the game needs. Lots of tools, fixes and the whole brand new systems to handle stuff Unity can't handle properly. And so what? Engine won't evolve from that, because EFT is made by another people and they won't just upstream the features.

Look at the URP. It has no camera stacking. It's in "Production Ready" state from 2019.1 (IIRC). I can't believe that if you have in-house game based on that technology you will leave it like that. No, you will work hard on the features you need, not features you THINK will be needed based on vague feedback which is not even collected properly.

TL;DR
Every game you make on your own technology gives you ton of experience. It shows you all the pain points, bottlenecks, workflow problems, UX flaws. It forces you to create new tools, features, systems. The best experience is your own experience. Period.

 

I was literally using their same example but all these things also have huge resource costs.

What you have just said is "this system they aren't using doesn't work so clearly this system they don't use will definitely work." The problem isn't that Unity isn't making their own game, but that they aren't doing anything. As I mentioned before:

Again, I have addressed these points already. Unity refusing to actually use the feedback they get will not somehow be instantly solved if they decide to start burning huge amounts of cash and dev time to start making their own game, and even if it did fix things, those fixes would take years to end up back in the engine. Those demos that they make? Even those features don't get backported. We're still waiting on systems that were first shown in The Butterfly Effect from 2012.

We have seen Unity eat their own dog food in a variety of ways, but all they do is spit it back up, just like they do with all the feedback they get. These problems will not be solved the way you think they will because historically, that has not been the case with Unity.

 

This works well for engines made to only make a specific type of game and not engines that's supposed to be generic and used to make any type of game. This is why AAA studios create their own engines which also allows them to focus on problems it has with their game and make decisions to better optimize it to run said game. Others use one that's geared towards the type of game they are making.

Things are different for engines like Unity and UE4 (Although UE4 is still heavily in favor of third person games and First person games) and Cryengine with First person games. Unity is looking to support anything from messenger games all the way up to high-end console and PC games of all types of genres, so that's a whole different set of issues to solve to get things running smoothly for everything. A solution to a part of that problem is to have different renderers to target different projects (SRP).

 

Epic uses their experience with Fortnite to improve the engine across the board, not to make engine better for shooter or battle royal games. And UE4 is not good only for 2D games, because they just dumped it in favour of 3D. There are MMORPGs, RPG, TPS, Fighting games, Flight arcades and even Racing sims (last Assetto Corsa CMP).

It's all on the shoulders of the engine team. If they can't extract something good from their project to improve the engine in general than there are some problems by design, I think.

I can tell you a lot of stuff you can get for your engine from simply creating TPS game that will benefit it in general. Of course you will have some tools and stuff that won't get into the engine as a core (but maybe as a plugin or package).

But, for example, if they were creating a game with lot's of complex UI they will immediately start on improving workflow and performance.

This is why we have and had so many great assets on Asset Store that are just essential for a mid and big size projects. Because engine don't have some crucial and fundamental parts every developer will notice as soon as he will start creating real games but not tech demos. People were closing gaps for Unity for years, but Unity were busy adding other features and telling everyone to rely on third-party plugins and assets.

The time they delayed improved prefab workflow is still baffles me. I can't imagine developing a big game without such an essential feature. This is the gap you will try to close on the early stage of the development, and I am sure big companies who worked with Unity did that by their own hands with internal tools.

So I disagree with that kind of point. Agnostic game engine will benefit from any kind of a mid size+ project.

 

I brought the 200 hour RPG example to show that your product will never be as great as it could be if you don't use it it yourself. If you make a game and don't play it, chances are high it will be bugyy and suck. If you make an engine and don't use it... well, here we are: full of features declared "production ready" by people who don't actually do any actual production, marking things as deprecated while the replacement is years away and letting basic bugs fester for years because their reports are glossed over as whining from entitled users.

If you cannot see the major difference between fixing bugs you encountered yourself versus one's reported on a forum, I hope I'm not unfortunate to buy your games in the future. Good software needs as much resources poured into testing it as into actually writing its code. And if you can actually profit from your test suite, even better.

Also, I'm not saying Unity should make Skyrim. All they need to do is take some of their their one-and-done samples, make them feature complete, publish them on as many platforms as possible and keep updating them to the latest Unity versions as they come. They don't need to go as far as have their own Fortnite (or a Paragon), what they need, at the very least, is to have their own "Unreal Match 3", "Action RPG Game Sample" and "Shooter Game". Those are three UE4 samples, where the first two are actually live on the Apple appstore and Google Play.

Shooter Game is not published, but it's a platform canary project: it's a fully working multi-player shooter with two maps, achievements, friend invites and matchmaking, designed to test all those features on each platform. It's updated to every new UE4 version and no version is deemed stable if it breaks on it. We have nothing like that on the Unity camp, and it shows.

 

Don't get me wrong we agree on this as I've seen all the additions made to UE4 from Paragon to Fortnite and other studios adding their tech. Just not on the point that Unity making a game will solve all the problems since most of the problems being solved would be related to that specific game type. This is why I mentioned that studios using their own engines don't have to worry about anything other than the tech needed for that specific game, which is exactly why they choose to use their own tech.

With that said the engine doesn't really support any other types of games. Fighting games and racing sims you mentioned all have heavily customized version of UE4 and UE3 (Mainly for the fighting games). Even Gears of War uses a heavily customized version of the engine and UE4 already has pretty good support for third person games. The main fact is we need better and stable tools which we can build off of for our projects as every serious project will need specific custom work done. The current project I'm working on already have a lot of custom tools for both workflow and project specific.

All I care about is that the core tools/engine functions well and that's being worked on (new preview features everyone fears) so I hope when we get there it's as good as expected. These problems are being addressed and the rest is up to us based on our projects.

 

Guys, as interesting as this debating might be we should stick to the thread topic. In this case... 2019.3 is about to go out of beta. We all think it’s still quite buggy but let’s hope for the best.

The whole “Unity comms sucks” / “Unity doesn’t feel our pain enough” conversation (which I’ve been a part of) should happen in another thread. This one probably will be locked soon, when the Comms team comes back from holidays.

TLDR; I really think we’ve made our point. It’s in their hands now.

 

There have been other threads about this. Numerous threads, in fact. It feels like the only communication we get from Unity comes from bug report threads in the alpha/beta forums though. In General Discussion there's a pinned thread about the state of the standard assets packages in 2018. It was posted in February of that year and the last time a Unity employee posted there was in June of 2018. Standard assets have not seen an update. We have not heard anything about what's going on with standard assets. This is not unique.

When prompted for what people want done about certain parts of the engine, we quickly see a couple of months of communication and then total radio silence. Roadmaps don't get updated, Unite comes and goes, we don't see or hear anything about this stuff. So we post it in another thread, what happens?

We all know that 2019.3 isn't even close to production ready and that it's going to be the basis for LTS when there are still showstopping bugs and feature issues. What more is there to say on that front? Everyone has said "hey, this is a bad thing" both in this thread and in the blog post, but the only feedback we've gotten is pretty much the blog reply that says "yeah, we know things are a little rough, but we ARE listening!"

But we've been told they're listening for years now, with little to no evidence that that is actually the case.

So why beat that horse?