Hacker News Reader

Comment by initplus | Hacker News Reader

Unity are spending too much money to develop far too little. New engine features are almost universally half baked (DOTS, UI mess). They acquire in demand features from the community just to let them wither (pro builder). The only thing that's consistent between different Unity features is how unpolished they seem.

Notably the mess they have made of DOTS seems to have been partially responsible for sinking Cities Skylines 2.

Just points to a mess at the leadership level. Their failed relicensing debacle shows the poor level of judgement of the C suite.

View on HN

No love for Unity here, their licensing debacle was horrendous, but I've seen no indications that DOTS is responsible for CS2 perf issues. Everything I've seen points to other things lacking in the engine (a decent LODing system for example), general optimization issues that'd be present in any game shipped too early, and inefficiencies in the rendering pipeline.

"Unfortunately a lot of the graphics-related issues are indirectly caused by the game’s use of DOTS"

"The cause for unnecessary geometry is both the lack of simplified LOD variants for many of the game’s meshes, as well as the simplistic and seemingly untuned culling implementation. And the reason why the game has its own culling implementation instead of using Unity’s built in solution (which should at least in theory be much more advanced) is because Colossal Order had to implement quite a lot of the graphics side themselves because Unity’s integration between DOTS and HDRP is still very much a work in progress and arguably unsuitable for most actual games"

https://blog.paavo.me/cities-skylines-2-performance

I think if a game development team is going to try ECS for gameplay, they need to have the resources to go ensure it’s comprehensive enough for their needs. It can be challenging to “bolt on” a data-oriented design and have it interface with the rest of the code base. Conway’s Law will apply if not everyone’s on board with it.

At some point, that in house engine is going to be cheaper and easier to work with.

Alternatively, a tough conversation needs to be had with the team about complying with unity's way.

Battlebit runs on the same engine, but I think they made exactly the right trade offs to achieve their experience.

I don't care if the game world looks realistic. I just want it to be fun. Simulations are a nuanced point of this, but even so if CS2 looked no better than the original, I probably wouldn't have noticed.

I was wondering if and how they were using DOTS with HDRP since (from brief pokes, I of course can't speak for all of DOTS) to my knowledge, there was no major work done integrating HDRP/URP. Both were moving targets that were probably moving even faster than DOTS.

I guess the answer is an unfortunate "we did not" as of now. Real shame because the ideas of a proper DOTS renderer (not a literal renderer, moreso an ECS oriented way to deliver data to the GPU. Likely HDRP/URP) was one rumbling for years. And probably still is. And with all the industry layoffs/leavings I hope they don't drain too much of the brain to get that off the ground.

No game engine can save a game from someone dedicated to being inefficient, like rendering high poly teeth on pixel tall models.

I would have assumed the game engine would be responsible for culling occluded objects. Isn't that one of the most basic parts of a 3D renderer?

Yes I would expect that from a 3d engine that I pay a license fee towards, but I also expect the developer to performance test and fix some of these things before release

Developer prioritize features and fixes. You don't know if there were worse issues before release. It should be on the managers and the publisher to set reasonable timelines and delay release when it can't meet expectations.

Occlusion culling is pretty usecase dependent if you want a performant solution. Unity implements frustum culling and Umbra which is a pre-computed solution. The latter is probably not great for CS2 and the former is basically the minimum. Unity have definitely slept on introducing more alternatives though.

Even if a 3D object is culled by the renderer, the mesh is still loaded in memory

For a zoomed out view with tiny people walking around, that would be mostly be a case for LOD, not culling. That is, you wouldn't render a highly-detailed character model and cull out each tooth mesh individually, which would still be very expensive, but you should render a simplified mesh to begin with.

In the case of this game, the mouths were never open, the teeth were never visible at all. Which is obviously a massive failure of the developers (using a prefab model with a ton of completely unused detail is a waste of everyones bandwidth, storage and memory), but the teeth should at least never be rendered by the engine.

For anybody else reading this and thinking (like I did) that these comments about teeth are a deliberately silly example invented for the purpose of this discussion - it turns out that Cities Skylines 2 really did have NPCs with teeth in their models, per this[1] story from up the thread.

1: https://blog.paavo.me/cities-skylines-2-performance/

this is very computationally expensive to do such operation (to understand that teeth is completely occluded by something else like mouth)

this is called occlusion culling and usually it brings a lot of problems on its own (it's CPU intensive and you need to apply it smartly only where it helps)

and even if this occlusion culling would be cheap, the way how it is usually done requires precomputing a lot of data - so occluders are static geometry

since character head is skinned mesh - so dynamically changes every frame based on joints positions - that will be another level of complexity

game engines are not really helpful here

Considering how long it takes to load games like Battlebit (super low poly 3D) or Graveyard Keeper (2D), speed/efficiency/optimization is not something I expect to see much of with Unity. While there are exceptions, its performance seems pretty consistently bad.

They pivoted from developing an engine to developing an IPO.

It's looking like there was no plan beyond that, once Riccitiello sailed off into the sunset with his loot.

There never is. This is how capitalism works. Cory called it enshittification.

they thought they had the Hollywood lock. Then turns out Hollywood isn't worth shit these days and treats em' like some post house on deathrow either way.

They bet too much, too hard, in all the wrong places. And tried lock-in and pricing out the indies. They should've done the Adobe thing and let those college kids pirate.

Dunno, very expected from this angle.

Why did they use Unity for Cities Skylines 2? Unity is widely known for performance issues in game dev community right? (I am not a game developer). Why not unreal engine etc?

I presume because they already used Unity in Cities Skylines (the original), and it would be easier to build and improve on the previous edition instead of throwing most of it away and starting a new project with a new engine.

People underestimate the cost of switching game engines.

While a lot of concepts are transferrable between engines, if you've got a team of experienced C#/Unity developers who haven't touched UE, switching to C++/UE is likely to cost a lot of time/money. A new engine can still be a steep learning curve for experienced game developers. You might be able to pick up the basics over a weekend, but reaching expert levels of knowledge takes years.

That cost increases further if it means restarting a project from scratch rather than building on top of an existing codebase (which will likely include not just the game itself, but also an assortment of tools built within Unity for building content and improving workflows).

Unity's killer feature for many is still its C# support. If you're a small team or solo developer who doesn't need AAA levels of performance, it can be a big time-saver over working with C++.

That's one of the reasons why Godot started brushing up their C# support recently.

For that that small/solo team it's also easier to switch engine and since they can't get custom license deals like the big boys having the same language may encourage some to invest the time and resources.

Wouldn't say its known for performance issues but it certainly is known for scale issues in open world games (Things like moving too far from 0,0,0 causes polygons to flail and physics to break, so you need to do tricks to work around that) which feel like the sort of thing you're going to encounter on a game world that exists from person scale up to plane scale.

In Outer Wilds, the player stays at 0,0,0 while everything else moves around them.

https://www.youtube.com/watch?v=LbY0mBXKKT0&t=1907s

I was under the impression this is how things always work in graphics pipelines. You don't want to give up on all the precision between 0 and 1

They were already entrenched with their first game, and used that opportunity to buy into the DOTS hype.

DOTS had a much troubled development cycle; most of what was promised was eventually abandoned, and the key people were laid off. Anyone that bought into it is now stuck in the hybrid-DOTS limbo, where they have to invest substantial amount of time into making the engine features work.

The issues with CS:2 are well documented and nothing do with DOTS; it was entirely the game developers fault.

The vendor of the tools should always try to empathize with the users of their tools and make the experience better.

Even if the user insists on being a little bit weird. Perhaps especially so.

We like to chase the most difficult customers. It forces us to have the best products.

Unity isn't one tool, however. DOTS does a lot of amazing things, but most of its job is done on the CPU. and issues here sound like GPU laden issues. DOTS could certainly do a better job talking to HDRP but DOTS has always been talked about as "in alpha/beta" until mid 2022. those integrations and polish are the exact reasons why, and I argue that it came out of beta much too early as is.

I think many of the issues with Unity are caused by them not using their own product. If they are never going to make games, then they need to listen to their customers far more closely.

What? DOTS is great and extremely performant. CS2 is completely the fault of the developers.

The real issue with Unity is that they don't double down on DOTS + HDRP/URP. I have not opened the editor for a few months but last time I worked in Unity the legacy render pipeline was still the default and documentation around DOTS and HDRP was somewhat lacking which is a shame because when you get it working, it works super well.

DOTS isn't ECS. DOTS was supposed to be, a Data Oriented Tech Stack. Currently it only has ECS with some extra bits. Ergo, DOTS is an unfinished mess. And that unfinished mess --along with a mandate to release for Gamepass-- culminated into CSII suffering from utterly ridiculous issues.

Reply on news.ycombinator.com