Comment by reactordev | Hacker News Reader

Comment by reactordev | Hacker News Reader

Unity has a unity problem.

While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt).

The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications.

There is the problem. The scripting ending designed around mono doesn’t translate as well to CoreCLR and using the same Behavior interface gets a little more complicated.

There are times (even with my own engine) that one must let go of the old and begin a new. Dx7->dx9, dx9->opengl, opengl->vulkan, vulkan->webgpu.

EDIT I was just thinking, returning to this a couple of minute later, that if Unity wanted to prove they really care about their Core, they would introduce a complete revamp of the editor like Blender did for 3.X. Give more thought to the level editors and prefab makers. Give different workflow views. Editing / Animation / Scripting / Rendering / Post

As it stands now, it’s all just a menu item that spawns a thing in a single view with a 1999 style property window on the side like Visual Studio was ever cool.

I think the major problem with Unity is they're just rudderless. They just continue to buy plugins and slap in random features but it's really just in service of more stickers on the box and not a wholistic plan.

They've tried and failed to make their own games and they just can't do it. That means they don't have the internal drive to push a new design forward. They don't know what it takes to make a game. They just listen to what people ask for in a vacuum and ship that.

A lot of talented people at Unity but I don't expect a big change any time soon.

The talent left ship years ago. The core engine’s graphics team is all that’s really left.

They also hired Jim Whitehurst as CEO after the previous CEO crapped the bed. Then Jim left as he just didn’t understand the business (he’s probably the one responsible for the “just grab it from the store” attitude). Now they have this stinking pile of legacy they can’t get rid of.

Has the talent moved to anywhere in particular?

Nicholas Francis manages a fund for AgTech after a decade making games with Unity (the engine he made). He left in 2013 so I don't associate him with Unity today but it was his product.

2018 We get the new HDRP and Shader Graph.

2019 there were sexual harassment lawsuits.

The other co-founders left after they announced runtime fees in 2023 and the community fled.

2024 the URP team basically imploded. Leaving everything basically flat.

I've seen it happening time and time again in similar companies, and this is a symptom of a problem at the upper levels, which means it won't change.

C-level set goals are abstract and generic, or sometimes plain naive, and this is often coming from generic requests from the board or VCs.

"Hire as many developers as you can, even if there's no work right now", a Softbank request.

"Don't build, just acquire similar products", from a Brazilian capital management that ended up killing that company.

"Kill this team, their product doesn't sell. I don't care if all our other product depends on theirs", from Francisco Partners.

Employees who stay can't really rock the boat, so it self-selects for non-boat-rocking people. Rockstars who stay must adapt or suffer. Eventually you get so many bad people that you do layoffs.

The thread in all of them is that the CEO listened to other people’s advice instead of leading themselves. When a ship loses its captain…

That's a good point.

If the CEO is just a parrot repeating what the board says, you get a company full of parrots too. No pirate to guide the ship.

The best CEOs I’ve seen balance board requests with what they themselves want to do and where they see their market going. Standing on the shoreline when the armada of prospects come sailing in for provisions.

When there’s a gold rush, sell pickaxes and shovels.

The biggest problem IMO is that they never finish new features. They start the work on implementing new tech/assets/plugins, then abandon them halfway through just as they are becoming useful for prod. There are tons of would-be-amazing tools but they are all stuck at "0.x-preview" versions, and eventually after 5-10 years either stop working completely or are over-shadowed by newer, shinier assets, which often re-invent the wheel and/or do things worse than the previous attempt. I stopped trying out new tech until its 1.0 (or preferably later, 2.0+ is safer) because I'm afraid to be bitten (again) becoming dependent on abandoned plugins and have to at some point update to something else. It's a lose-lose-lose proposition: Unity throws away time and money re-inventing plugins, we throw away time and money having to port to functioning tools, customers lose time because they get to discover bugs caused by outdated plugins/assets that cause weird errors that are hard to track down.

I think what you're describing is a symptom of the issue. The issue is talent churn. Bright folks who start a feature get poached and leave and the feature dies on the vine. Or that the feature, which started off great in it's own little corner of the engine, was a mess to integrate with the rest of Unity due to it's architecture and the fear of breaking backward compatibility.

The problem now comes not from tech-previews but from the quarterly forced releases because it's now a subscription. The entire business model is flawed and outdated. Same with Unreal. The difference is Unreal tech is exponentially better than Unity architecturally and they know their audience very well so they were able to get in with virtual stage production, games, movies, you name it. They were successful in expanding beyond their core. Unity, can't. They don't know how.

It's a tough spot to be in. I knew my place when I shut mine down and open sourced it. I couldn't compete. For Unity, they have a loyal fanbase that wants them to succeed but I'm afraid it's going to take breaking everything they know in order to do it.

That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS.

On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases where the performance should be identical to DX12; AMD does not suffer from this bug.

If you care about performance, you will call Vulkan directly and not pay for the overhead. If you care about portability and/or are compiling to a WASM target, you're pretty much restricted to WebGPU and you have to pay that penalty.

Side note: Nothing stops Windows drivers or Mesa on Linux from providing a WebGPU impl, thus browsers would not need their own shim impl on such drivers and there would be no inherent translation overhead. They just don't.

I’m foreshadowing a future where they do. Please don’t kill the dream.

I'm not killing it, but there is no C API written verbatim. WebGL was fucky because it was a specific version of GLES that never changed and you couldn't actually do GL extensions; it was a hybrid of 2.0 and 3.0 and some extra non-core/ARB extensions.

WebGPU is trying to not repeat this mistake, but it isn't a 100% 1:1 translation for Vulkan, so everyone is going to need to agree to how the C API looks, and you know damned well Google is going to fuck this up for everyone and any attempt is going to die.

Chrome is the cancer killing desktop computing.

So use dawn.

The problem is the same as it was 20 years ago. There’s 2 proprietary API’s and then there’s the “open” one.

I’m sick of having to write code that needs to know the difference. There’s only a need for a Render Pass, a Texture handle, a Shader program, and Buffer memory. The rest is implementation spaghetti.

I know the point you’re making but you’re talking to the wrong person about it. I know all the history. I wish for a simpler world where a WebGPU like API exists for all platforms. I’m working on making that happen. Don’t distract.

And Web, because nowadays when people complain about standards, they mean something that only Chrome or Electron crap does.

I wouldn't call it nonsensical to target WebGPU. If you aren't on the bleeding edge for features, its overhead is pretty low and there's value in having one perfectly-consistent API that works pretty well everywhere. (Similar to OpenGL)

WebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers.

You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.

We already do this by exposing the canvas surface with a semaphore lock. The browser can flip the surface to the canvas (or your app can flip it onto a window surface).

It’s just a HINSTANCE pointer.

You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.

wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).

You've mentioned dawn more than once, but isn't dawn dead since the team at Google that was working on it isn't part of either the Android nor Chrome teams, and Android and Chrome both have their own (and incompatible with each other) preferred API manglers?

WebGL and WebGPU must robustly defend against malicious web content making the API calls, just like other browser JavaScript APIs, which makes for some overhead and resulted in leaving out some features of the underlying APIs.

Vulkan has also evolved a lot and WebGPU doesn't want to require new Vulkan features, lacking for example bindless textures, ray tracing etc.

All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.

Programs can use Vulkan, D3D, OpenGL, OpenCL, etc, to ex: read memory that isn't in your program's space via the GPU/driver/OS not properly handling pointer provenience. Also, IOMMUs are not always setup correctly, and they are also not bug free, ex: Intel's 8 series.

Using hardware to attack hardware is not new, and not a uniquely web issue.

> All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.

This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.

The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.

Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.

To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as

[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.

[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.

[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.

[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.

[$TBD][1506923] WebGPU High CVE-2024-0225

etc.

C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.

There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.

Yeah, I started a project in Unity a while ago, and tried out Godot in the meantime.

Unity really feels like there should be a single correct way to do any specific thing you want, but actually it misses <thing> for your use case so you have to work around it, (and repeat this for every unity feature basically)

Godot on the other hand, really feels like you are being handed meaningful simple building blocks to make whatever you want.

Bingo. They don’t actually understand their users. Instead they’re the Roblox of game making, just provide the ability and let devs figure it out (and then sell it as a script).

Unity somehow manages to break the API of their own features so bad every year or so that their own tutorials don't work. You have a solid baseline API that has existed since forever (with known limitations), with stuff like the legacy render pipeline. Every attempt to reform it has only introduced confusion, complexity, and is at some point between experimental and no longer supported.

I don't agree with you on the Asset Store, for the same reasons - the rate of breakage means that things that are not constantly updated no longer work - and multple versions need to be maintained for parallel engine versions. That combined with the dubious economics of Asset Store (I don't think it makes financial sense to even make these things, let alone maintain them), they mostly end up as abandonware.

And on the Asset Store if you make something indispensable (which is more often than not something the engine should'have OOTB, like competent text rendering), one of the following things will happen:

- Unity will buy you out, and plop your asset in the engine, without doing any integration work, and will stick out like a sore thumb (TextMeshPro). Good for you, bad for consumers, and sucks if you were making a competitor

- They build an in-house solution, that you obviously can't compete with, and will have a huge leg up on you because they have engine access (sucks to be you)

- The engine will never have that feature, because 'you can just buy it', meaning you have to either spends hundreds of dollars/euros on dubious quality assets or hunt for open-source versions with generally even more varying usability. UE4/5 has a lot of these built in, and AAA quality.

> with a 1999 style property window on the side like Visual Studio was ever cool.

I don't think this is fair. I'd say Unity's inspector window is one of the good parts of Unity because it not just a property window. It's an immediate mode UI that things can hook into to do a lot more than just property editing.

Yes, the last 8 years has seen that little side drawer used for every. single. unity. feature.

Thankfully there are tons of assets you can buy or download from github that will extend the functionality of the inspector windows, which IMO need a LOT of love. The last update I saw was where you can do math inside e.g. transform properties e.g. scale is 1, you can type in 1+2 and it will show in game/scene views immediately your changes, and if you press ENTER it will commit those changes. It's not really well-known (I discovered it by accident reading some changelogs at some point a couple years ago).

Not thankfully. The whole point of this thread is that Unity is barebones without community support. What you’re describing is that community support. Glad you like it. I find these kind of lack of attention to your product a huge turn off. Unity Community is naive in the fact that they allow this company to walk all over them because they lack the willpower to steamroll them. There are plenty of Unity community members that are capable of making a better Unity. Unity itself relies on their community otherwise who would pay for an engine? So by saying “just use this plugin” is basically just reinforcing my perspective.

I agree, hence "need a lot of love".

On the other hand, the lack of "love" from Unity's side (at least regarding Inspector) allows a thriving ecosystem for devs to build their own version of what an ideal Inspector drawer should look like, as well as potentially make a living from it. And to boot, who is to say what the ideal Inspector should look like? Do you trust Unity to make an Inspector that fits everyone's wants/needs? I definitely don't - so I'm glad they have a "bare-bones" version that allows us to customize it to our heart's content. Do you want them to be like Apple and "steamroll" everyone and make bad decisions for arbitrary reasons? I definitely don't and I personally HATE a ton of Apple's constant changes and lack of ability to change simple things, such as the inability to disable a lot of animations, which murders my VNC sessions, but I digress.

Regarding non-Inspector things: you already replied to my other rant about unfinished features, so yeah, also in agreement.

Reply on news.ycombinator.com