Unity is not worth using right now

Edit: deleting post

 

Just tossing this out there. I've been using Unity 2019.3 since it came out and haven't had a single problem with it. While I know there are people out there that haven't been as lucky I have to wonder what they're doing that is constantly breaking things for them. Current project is using the latest stable releases of the HDRP and the new input system.

Can you provide actual details on the problems you're running into (assuming you're not behind an NDA)?

 

Eh, I'm pretty happy with Unity when all is said and done at present. If i could go back in time and pick a different engine for my project, I'd still stick with Unity. C#, easy platform deployment, and the rapid prototype environment of Unity still suites my project very well.

There are a few things that still bug me, the mediocre post process stack, the new input system which can't be THAT complex and should be feature complete by now. Prefabs could be more polished (not to mention the bugs that i imagine the OP may be insinuating that will hopefully be fixed soon).

There are a few things up in the air listed above that once they are tuned up and fixed Unity will be rock solid. Just hoping they don't drop the ball with their very ambitious DOTS upgrades, which will make or break the Engine moving forward.

 

Yes, the traditional Unity experience is pretty solid for me, too. One of the side effects of the company's shifted attention to new preview packages (including URP and HDRP, which still seem like moving targets), superseding existing features instead of enhancing them, is that the core is basically the same as it's always been. I enjoy working with it.

That said, I can sympathize with the feelings implicit in the original post. I do feel myself stuck in this psychological vice with Unity: the old stuff is clearly being left behind for completely new paradigms, so why would I start a new project with it? But the new stuff is clearly not ready yet, poorly documented, and constantly shifting, so why would I start a new project with it?

The double-bind makes it hard to start anything.

I'm aware that this may be the way it's always been, except that development that was once hidden backstage is now happening in the open. Transparency is good in theory, but it still afflicts me with this ineffable inertia.

 

it depend what you doing, if you only concentrate on menu and input it is very small subset of overall engine.

You will find the graphics side very fragmented and unstable i feel.

 

Like I mentioned in other threads my primary roles are in fact with UIs and input handling but I have had to work with other aspects of the engine like the animation systems, and between me and the other members of our team we haven't run into anything that held us back or caused us problems.

We have a developer that is knowledgeable on the SRPs but prior to that one of my tasks was to investigate the HDRP and determine the troubles we might run into with it. I had no trouble learning the basics and getting assets that the automatic upgrader missed converted to use the new pipeline.

 

ah i see, if u mean the 'fighting game' u are working with joe strout, then it is likely members will have tried many fragmented workflows to get something working but u will not be so informed.

That is issue, inside unity it is not 'just out of the box working' it requires lots of searching, many package requires certain hdrp version, lots of plugins do not work, example particles, some can easily update, others u need to use special vfx graph, water, terrain grass.

Without hands on experience it hard to give honest opinion i feel.

 

You just love making assumptions with no meaningful information to back them up, don't you?

 

it is factual friend, to arrive at solution it requires lots of testing, chatting to colleague is not suffice i feel

 

Up to you what you want to believe. If you want to pretend you know something with your few months of experience that the developer with two plus decades of experience knows that's your choice. My company isn't having trouble learning in spite of what you want to think.

 

Check mail.

 

also as addendum, although engines like unreal and cryengine / lumberyard are more complete out of box, they too are not without major problems.

Cryengine has one of worst asset import procs we encounter, and ray tracing on unreal is still problematic, volumetrics slow etc and industry sized team for scripting.

 

No. If you have anything to back up your statements then everyone will need to see it otherwise there's no reason for any of them to believe anything you're saying.

 

Agreed, but it's funny when you read this post and realise that half of it can be done with built-in, except they have just abandoned it instead of backporting.

 

the hdrp package is quite different than srp, and even if it did 'half of it' it doesn't compare to studios requiring tripple a solutions, it would simply 'not make sense' to keep adding to srp or backporting, which was never intended for cutting edge technology i feel.

the question is of course, should it be as fragmented as it current state, perhaps not but its conception was a wip and unity trying what is best, and requiring end users to test parts for review.

overall i am quiet satisfied with unity progress.

 

HDRP is an SRP. What you are talking about is the built-in.

 

I feel somewhat the same but for entirely different reasons. If I did not have so much time invested into two mid-sized to large projects I MAY have abandoned it. Financial pressures dictate I stick with a constantly silently crashing application in hopes they get off their duffs and fix the built-in render pipeline. @Ryiah apparently has the same rig and grfx card as I but is apparently no experiencing the same crashes as I and have to wonder if it is her use of HDRP. I am hoping a thread I started today about stability an grfx drivers may yield some solutions or at least get some folks off their duffs in the Unity/nVidia/MicroSoft triumvirate and asses the issues which seem to be go back several years and with widespread larger games built with Unity as well as dev complaints. The Unity qa bugs replies are invariably the same and yield no positive results after explicitly following the same directions month after month.

The game designer of the other project has been having issues with same style crashes and went through the trouble of uploading a 2+ GB project for them to assess in 3.14 and they told him they would not look at it and to upgrade to 3.15. WTF? I am in 3.15 and it till has the same issues. Somebody needs their ass fired. The other form of reply "We have had lots of grfx driver issues" is not helpful at all and indicates they know of the issue and are not resolving it nor communicating anything hopeful about the issue.

 

Unity does seem to be in an awkward place at the moment, but it is still worth using right now.

I do see the issue with the old Unity being left behind (along with much of the user base), and instead are focusing on new Unity with DOTS and HDRP and so on, which feels less user friendly, and far from democratising game development. But I'm still hopeful it will all work out in the end. In the meantime, I have been doing what I have been for a while, using the oldest version practicable.

 

You keep digging that hole deeper with every post. The HDRP (High Definition Render Pipeline) and URP (Universal Render Pipeline) are both major pipelines belonging to the SRP (Scriptable Render Pipeline), and it's not like this is some secret info that no one but experienced developers are privvy to. It's plastered everywhere Unity discusses it/them.

In fact like @Lurking-Ninja mentioned the pipeline your post is describing is the one that has been built into Unity from the very beginning and not at all the pipeline that I have been describing. This is why you need to stop pretending you know a subject and go learn the subject properly. We have enough confused developers. We don't need you creating more.

 

I still want PCSS, contact shadows / screen-space shadows added to built-in.

I wonder if any AAA developer will ever use HDRP... It still seems missing a lot of what Unreal has.

 

One example of discontinuity in Unity is "Playables". I've been reading about it here. It's supposed to be 'better' than using a simple built-in animation state machine. But then why doesn't Unity just make the default animation system better? Why create a new feature? Or if a new feature is needed, then why not fix the old animation state machine system to use the new and improved Playables system? People will keep using the old animation system because that's whats easily available. Not everyone is going to scour Unity's dev blog for days looking for the best animation system to use.

 

I was very surprised to learn that Unity is working on a secondary animation system ON TOP of mechanim that is DOTS powered... From top to bottom Unity is systematically working on a new DOTS based system for their Engine on top of supporting prior setups.

It's kind of exiciting. Whereas Unreal is a hyper focused engine that plans on doing FPS type hyper-real visuals Unity is taking a different path, they are chasing modularity. We see this in the package manager, and multiple systems being worked on.

We are seeing the transition phase, and it is frustrating. While Unreal is doing what they do best and refining, and chasing new tech pillars, Unity is taking a big chance on improving their performance with DOTS and revamping how we view a game engine. From a defined set of features, to a more pick and choose package that scales with your needs.

It's kinda crazy to think Unity is working on at least 3 animation systems concurrently, but it also shows that they are ambitious and feeling out their new modular and expandable design of the platform.

It's all or nothing, they either make DOTS usable and expandable, or they have allowed it to fully destroy their platform.

Why is everything taking so long? Why is everything up in the air? Well, you have to imagine in making DOTS globally useful and adoptable they are using their own internals as the prototype bed. Unity often gets the criticism, "You don't make games! You don't know how to make an engine!" Well, it would seem they are putting their money where their mouth is and looking long term to ensure they remain competitive.

It's going to be painful for a bit, but hopefully the end results justify this migration. If you have a singular bottleneck, your game is going to run slow. So it makes sense they are shifting their entire platform to the new paradigm, not only for the functionality, but so they can know 100% internally that they know how to migrate to the new DOTS solution, so it is universally applicable to all sorts of use cases, and that they have a great many internal users who can educate us how to use the new systes.

I would absolutely welcome more news about what's going on internally. It's a little crazy how much we have to assume from the outside. Is there a plan? Do you guys at Unity have a vision for these tools. "Playables is more approachable and we envision it being used for cinematic uses like cutscenes in games or fully fledged movies or cartoons, whereas our DOTS solution is going to replace our current solution and have XY and Z new bells and whistles you can be excited about as we are building on our existing system and we have learned many lessons about what COULD be."

Instead we just learn "X exists, we don't really know why". There are a myriad of reasons to not release information, to keep your competition off your trail, because it takes resources educate those outside of whats coming, because things can change and then you look incompetent, because people are hyper critical and will whine about anything, because features are so far off it isn't beneficial to set expectations early, because things are going very poorly, who knows.

Whatever happens it has the potential to be a spectacular success or spectacular failure, but likely it will be somewhere in between. Will be exciting to see how this all unfolds regardless.

What I hope they add is a new feature that reduces burnout so I spend less time rambling on the board and more time using their awesome engine.

 

Unreal hasn't been focused on FPS for a long time. People made racing games in it. It is good for anything 3D,

Which rings a lot of alarm bells. Look up Gnu HURD and Microkernel vs Monolithic architecture debate.

 

There was a time where you started a new project with Unity and then just worked on your project, you had a standard set of components and monobehaviour API to get to grips with but it just worked out of the box.

Compare that to the complexity of modern Unity are you making a 2D/3D project a URP/HRP/SRP project. Will you be using packages and if so which of the 61 packages will you need to work on your game.

So if my binary math is correct that's 2 ^ 66 combinations or about 73,786,976,294,838,206,464 possible configurations of your Unity project.

That's before you factor in package versions and stability of their myriad combinations or adding the possible platforms to the complexity equation (or assets).

I think it's safe to say that Unity is becoming too complex.

The thing is Unity should have a huge amount of user data on game projects and packages maybe they could have a better templating system...

Imagine a system like an online shopping experience you choose your game type genre/rendering style and unity offers you a set of templates that most game developers use and have found to be successful.
​

The community could even submit their own templates and have other developers rank them.

So you could have a 3 step system (select genre, renderer, template) that reduces the upfront complexity of making a new project with Unity.

 

Not SOLEY focused on fps, but overal that is what their engine has been designed to do. To my understanding, "Unreal" is the name of their flagship first-person-shooter title from which their engine has it's foundation in. The architecture of the engine from the base level is that of an FPS game, it's lineage all stems from this. The entities in their engine "pawns" are the evolution of player avatars that run around that you kill in an FPS. Their vehicle system was originally developed to create things you could climb into within the FPS, much like the warthog in Halo.

The very soul of Unreal is the FPS. And it's not a bad thing, a great many emerging experiences like VR are perfect for a platform that was built around the first person experience.

I really hope Dots doesn't totally bone Unity, I'm not familiar with the nuts and bolts of the back end of these engines so i don't really have a strong opinion of whether it will succeed or fail, I just know most all forced tech pivots fail. Unreal is a great example of a succesful game that was modified to be a multi purpose engine. Unity seems to be pivoting in the dark and their silence isn't very reassuring.

 

By that logic, Unity engine is only good for making GooBall clones. Because that's the game Unity Technologies started from.

Spoiler

The entities in the engine are Actors and Components.
And why would that matter? Humans evolved from a single-cellular entity that lived ages ago. We are not longer that entity, though.

That is not true. You put too much weigh into the name choice and history.

They're general purpose 3d animation/physics framework right now, with heavy bias towards realtime cinematography. And not 1st person shooter.

Take a look here:
https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Unreal_Engine_4
Majority of games using unreal 4 are not first person shooters. They're puzzlers, 3rd person games, sports, and so on. There's even a city builder there.

Actually, it is most frequently used for 3rd person perspective games and hack and slash right now. And not for FPS.

You would have a point if you were talking about Unreal 2. That was First Person engine through and through:
https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Unreal_Engine_2
But you're talking about Unreal 4. And with Unreal 4 your belief of the engine being geared towards FPS is no longer correct.

 

I feel as though Unity is still very good at making goo ball clones and this further proves the point that the core game created with an engine will influence it for the duration of its lifetime.

The Unreal engine is very good at handling biped animations and movement and the vast majority of its most successful titles benefit from its origins as an FPS game engine. It's entire render pipeline and physics engine are geared for conditions that exists in an FPS. Particles, depth of field, sunrays, fog, etc. are all specifically designed to work in this environment. I don't even know how this is open to debate. It's called "unreal" for a reason. It's no fluke that Fortnight is the behemoth that it is. It builds on what the engine was meant to do.

 

When I Ctrl+F "61" the only places I see it are here and in Ryiah's post count. Where did you get that number?

 

Your point is a mistaken assumption. Unity has also been used for city builders which do not benefit from roll a ball mechanics.

That is also false. Its animation system is not tied to Bipeds in any way. You can use whatever.
Unity, on other hand, has mecanim, which is geared towards Bipeds only and does not work on anything else if you want retargeting.

All those systems and effects are genre agnostic. Every game uses particles and fog, sunrays appear in many titles. Fortnight is not an FPS, it is a third-person shooter. Which means it is not what you believe unreal was "meant" to do.

I'll be blunt. I have hard time believing that you are being serious here.

 

Remember what Unreal recently said about their functionality, "it just works". You don't need to rescale things to get them to work, you don't need to go in and mix and match 50 different post process effects to try to get it to look nice everything is tuned and polished for an FPS experience and it has been since day one.

There is a difference between an asset you create that you assume will be used in 50 types of games with different camera angles and scales, and one that you plan to be used from a certain vantage point. This is espeically true for effects such as depth of field. These are important concessions of quality that are lost when you start layering these systems on top of each other. It's why you can tell imediatly if a vanilla scene is unreal or Unity, unreal just looks better out of the gate because its render pipeline is locked into that near the ground camera positioning, first person or 3rd person they are nearly identical.

This doesn't even factor in the various raycasting and particle setups that they have perfected over the years releasing so many various FPS games built directly into the core of their engine so it's not scattered about, not just in the engine UI, but in the back end too. Again the soul and the foundation of Unreal is that of an FPS, down to the nuts and bolts.

I'm being serious. The core infrastructure matters, what you lay first in your foundation matters, it's a million and one tiny things that all add up, a certain "I don't know what" that makes everything come together a bit better in a multitude of ways that makes the overarching experience better that you just can't quite put your finger on.

 

That is false.

You're dealing with software engineering. In software engineering you can make a foundation, build on top of it, then replace the foundation. That's what makes software engineering unique, by the way.

Anyway. I do not believe you're being serious. I mean... they have RTS tutorials in their documentation, and NPR rendered games based off the engine. There's also a flight simulator developed using Unreal 4, so nothing you say holds. In off-chance you are serious, I'd advise to learn more about Unreal engine and games made with it

As for me I don't want to deal with this.

 

Perhaps I did not communicate clearly enough that I believed Unreal had a focus and spirit of the FPS genre, and that it was fine for other projects. It was not my intention to say that Unreal was a one trick pony, just that it's core is very good for games that exist at the scale, perspective, and with the weapon mechanics of an FPS both in visuals and gameplay.

 

Mhm... nope?

The unreal-based games look great because the engine provides a huge number of tools for artists and designers out of the box. Material Editor exists there since UE3, the first games released in 2006. It was one of the major selling points of UE3, artists could easily author many shaders. It's normal to have a different set of shaders per model (or small group of models).

I was seriously surprised when I open the Atmosphere Fog equivalent in Unity and it got only a few properties (1 color and intensity). No artists could make a gorgeous atmosphere with built-in component

There's a different relation here, visual fidelity was always a critical thing in First Person Shooters. FPS/TPP games are pushing software and hardware to limits. So.. UE3/UE4 is a common choice for such games

Examples of not so "ground camera positioning".

 

Opened Unity 2020.x and counted the packages in the package manager it should be about right although I might have miscounted.

Maybe package groupings could work e.g. DOTS, 2D, 3D, Burst, Input .. massively reducing and simplifying the complexity for the average game developer.

 

I'm on 2019.3 but there are only 16 in mine, and some of those I've never even seen in action (like Multiplayer HLAPI or unity Collaborate). It's not difficult to simply ignore menu options you don't use.

For something like two different graphical pipelines, yeah that's an issue.

 

which render pipe u using and what version of unity?

 

In the off chance you're using the winky faces to soften a counter argument, it can easily come off as smarmy.

It's ironic that the video of your air force game focuses almost entirely on close in shots of character models, and super tight shots of airplanes and cockpicks. It's almost as if the rendering technology of unreal best shines from a specific zoom level. The baked lighting, texture fideleity, fog, etc, are all designed to function better closer up in a smaller scale FPS environment.

A few unique adjustments for a custom planet setup that better transitions to a space view also doesn't invalidate all the mountains of tweaking to make the smaller scale rendering really shine. I'm sure you would also agree the real "money shots" in that video are when you're on the ground level where the best of the engine is on display.

I'm not sure where all this hostility is coming from. I posted a pretty centered message that didn't call anyone out.

No wonder Unity doesn't engage with this peanut gallery...

Edit: @MothDoctor you are right though, it's not JUST that they tune their engine for a specific FPS render setup. They DO simply have a wide variety of better tools and this is a larger part of the equation. But the fact that they focus more on high fidelity from a specific viewable angle does also contribute and is also the reason why so many of these tools are considered "default" and play nicely together. It's why Unreal has such a list of tools that just sing so well together.

When i think of unity at its best, i think of a vibrant phone game with cartoony graphics ported to a variety of platforms, when I think of the best of unreal, I visualize a slick FPS game with incredible visual fidelity. There are multiple variables that put Unreal several orders of magnitude above the visual fidelity of Unity in the FPS space.

TLDR you could match Unreal in Unity MUCH EASIER in visuals if you were making a space scene, a stylized top down game, a purely simulation flight game (without cutscenes), etc. than if you were trying to compete in the VR/ FPS space.

 

Exactly
It could be easier to make some FPP with customized render in Unity. It could be easier to make a stylized top-down game in UE4 if using the perspective camera would be suitable.
These two engines got surprisingly more and more overlapping areas/uses, so its a wonderful time for developers. If a single thing fails in the engine, he could switch to another one. Not the easy to put a specific engine on the shelve of specific genres, and that's awesome

Not hostility, just consistent myth-busting. That's a weird notion if some engine goes for realistic, physically-correctly rendering, it's for FPS games.

It's weird when I post game trailer about airplanes which mostly render far planes, decent atmosphere and stream a lot of terrain under the airplane, but someone says "nah, it renders airplane nicely, still like FPP-focused engine, renders nice what close to camera".
The recent sky atmosphere updates are all about rendering atmosphere for huge worlds, planets, cosmic scale. Hardly to make "smaller scale rendering shine"
And that's also money shots

More precisely, I would say that Unreal rendering is focused on the PBR-based, perspective camera.
What's is largely ignored in UE4 is an orthographic perspective, this is the most voted (because ignored for years) issue on the public UE issue tracker.
https://issues.unrealengine.com/issue/UE-11026

Totally. Ease to break PBR rules and set up custom, heavy-stylize rendering is what makes Unity different and where Unity should focus its efforts IMHO

UE4 updates bring more and more tools to be cinematically-correct out of the box. There was renderer refactor under the hood (Render Graph, similar in concept to Frostbite or Unity setup) to make customizing engine less "you can do everything, but need to modify the engine". It's still the domain of rendering programmer to handle this. I got a "scriptable render pipeline" in C# as a promise that games with stylized rendering passes would be easier to do in Unity.

Although there dozens of stylized games done in UE4, it just usually stylization on the top of the stock renderer. Most games might be fine just with that (just an opinion).

 

By this logic I'm frankly amazed you can make a post to this forum. There's 101 keys on a standard keyboard alone which you could press at any time... that's 2^101, plus your mouse and all of the possible things you could click on the screen...

That line of argument only makes sense if:
1. Your user is uneducated, or
2. The options available are confusing.

2D or 3D should be a no brainer. If you don't understand enough about rendering to make an informed decision about a render pipeline then one of them is called "Universal", I'd start there. You don't need to know what packages to import at the start, and each one has a clear purpose so you can just grab them if and when they're useful to you.

Yes, managing dependencies is a bit of a pain, but it's a pretty normal part of software development.

 

Oh, I failed to mention it was an old renderer before they even add new ones. I'm aware of shaders/plugins to make look nicer in Unity - that was an example of comparing designs of engines

 

1. Unity documentation on modules is very poor to terrible in places, show me the learning resources to provide in depth information on why I need and what I can do (that can provide information to noob Unity developers and experienced pro developers) with all 60 odd packages and I will give you this point.

And you will have slayed me if you can show me a Unity system that allows noob developers to input their game type and outputs the modules and settings they will need in Unity. Bonus points for pointing said noob towards learning resources that are up to date.

Or can you read through all the package manager modules and know what they are and what features they provide this ability does not prove your point as it's only a sample of N=1.

2. AR Foundation, Alembic, Advertisement, Adaptive Performance, Android Logcat, Barracuda??? I would say 50% of the packages would be alien to a noob and the few lines of information on what they do could even be more confusing.

Think of the noobs or modest developers who only want to answer the question "What do I need to make my game in <this genre> with this <set of styles> for these <platforms>?"

Hence my previous point:

Only also with higher level generics along the lines of Style, Genre, Pace, Multi:

• 2D Shooter Real Time Singe player
• 3D Racer Multiplayer
• 2D Strategy Turn based Multiplayer

Or some other templating system that maps well between desired game/platform/features and packages needed.

Even sub groups in Package Manager could help a lot grouping packages together by topics instead of one long list.

 

I just looked in 2019.4, which should have similar packages to 2019.3, and I have well over 100, and that is not including the built-in packages which for some reason are not included in "All packages". I think your platform choices might influence how many packages there are, plus .

It is good that there are packages, as it stops things being included in the build sizes. The problem is all the packages that are enabled by default and I won't use. It takes time to disable them, as they have to be done individually and they are slow to respond. Starting a new project takes too long (there is also disabling the skybox I have never used, and very much doubt I ever will, but keeps popping up).

I'm not sure how much the packages contribute to the enormous project file sizes, but I wish they were all not included by default.

 

I was looking at "In Project," not "All Packages." I don't think the packages in "All Packages" that are not in "In Project" show up anywhere else in the interface, so they won't be cluttering anything up unless one adds them deliberately.

I just looked at "Built-in packages," and I have 32 in there, but few of them appear to be directly shown in the interface anywhere else, and if they are they're pretty obvious. "AR," "VR," and "XR" are pretty clear in what they're about. I can ignore them without adding to my cognitive load.

I'd agree not all of these are necessary for every new project, but I don't think they're adding much to the complexity. That comes when you have two ways of doing something, like "Button" and "Button - TextMeshPro."

 

I can tell easily whether or not they're relevant to me, which is all I need at that point. Remember, your use case here was starting a new project and it just working. You don't need to manually import any packages for that to happen.

If you don't understand what a thing is then importing it is a bad idea anyway (except if you're just messing around).

These people don't need to start messing with non-default packages. They have plenty to learn with the stuff packaged in Unity by default. When they reach limitations within that then they'll have learned enough to make informed decisions about related packages.

You've got to walk before you can run.

While I agree that it's not all easily digestible the information is there for them. I'm not of the opinion that everything has to be newbie friendly. Advanced topics and tools are allowed to target advanced users.

Certainly if I start doing stuff in a field that's new to me I don't expect advanced stuff to somehow come easily. If I start learning guitar it's not the guitar designer's fault that some techniques are hard to learn. I'm just going to have to put in the time to practice and learn like every other musician has before me.

If your game engine can tell you how to make your game then it may as well automate the implementation, too. So is the next step complaining about the lack of a make MMO button?

 

I believe some game engines have templates that start you off with a good basic set of systems that lend themselves to rapid game development... considering the vast range of modern game styles, genres and platforms maybe Unity needs a more advanced templating system.

Lets do the sums from this side how complex is modern game development when just starting a project:

3 x Styles: 3D Low End, 3D High End, 2D
59 x Genres (source)
2 x Pace: Single Real, Single Turn
2 x Player: Single, Multi
19 x Platforms

Or about 13,452 game targets that a developer could be making.

 

At this point you've shifted from "how complex is Unity" to "how complex is gamedev."

 

My point has two aspects game development is complex and Unity is becoming too complex.

IMHO a game engine should make game development easier not add to the problem.

 

Stop demanding "make game" button. Instead, learn to use existing tools.

Package manager approach is way better (than it was been prior).
Modularity == lesser build size, less editor loading time, less compilation time, list goes on.

If you don't know what URP, or HDRP or whatever should be the pick, Google might be the best starting point.

 

At no point did I ask for a "make game" button. I'm asking for a system that works with the developer to help them navigate the complexity of making games with Unity.

I'm not saying remove the Package manager, I'm asking for improvements that make working with the package manager easier and faster for developers.

If noob developers with Unity are best off starting with Google then I think Unity are not helping developers enough. Thank you for making my point for me.

 

What about package updates and dependencies you could need an update in one package to fix a bug that then causes a bug/issue in another package.

Could Unity improve packages with a similar Long Term Support set of packages that are guaranteed to change little during your games development and only to fix bugs and add optimisations?