Threads like this tend to become occasions for responding generically to stuff-about-$THING (in this case, the game), or stuff-about-$RELATED (in this case, the framework), or stuff-about-$COMPARABLE. There's nothing wrong with those in principle but each step into genericness makes discussions shallower and less interesting. That's why the site guidelines include "Avoid generic tangents" - https://news.ycombinator.com/newsguidelines.html

This sadly tracks with my own experiences with Unity's tooling, where DOTS did ship but its implementation rots on the vine like every other tool they acquired. The company is woefully mismanaged, its been mismanaged, and given the very public pricing incident from a few weeks back, they aren't focusing on improvements to the engine, but on any way to scrap money from its users.

Bevy's ECS implementation is really good, and I want to see it succeed here, in addition to Godex.

Godex is ultimately putting lipstick on a pig. it can improve performance a bit, but ECS isn't some magical optimazation to slap on as a plug-in. cache coherency in the gameplay layer can't fix engine level bottlenecks.

Company wasted so much money, then the org shut down for spending $500 per customer per year in maintenance (this was a health insurance company) whereas the main company would only spend $70 per customer per year. You'd think leadership of the org would get fired for this but they were rewarded with other positions within the company to do the same thing.

Unreal. Why do shareholder's put up with this? I guess the healthcare monopoly is the only reason to.

Edit: some companies have >20k employees. My first years at MS (late 90s) had these "war room" like 2x a week, 50 people, multiple VPs in the room, 2h. But there were other groups doing their war rooms too.

Although to build DOTS they did poach a lot of ECS and Data-Oriented folks like Mike Acton, who left earlier this year.

Account Number:

Your CellFin card account number. It is 13 digits and starts with 358.

Branch:

Local Office or Truncation Branch

Routing Number:

125270007

You have to remember, Unity usually sets the bar very low for themselves, comparing their ancient Mono implementation (they still use the Boehm GC, written in the 1980s!), and when a shiny new performance 'fix' like Burst/DOTS drops, they proudly proclaim how much faster they managed to make things, never mind a modern .NET implementation, like Microsoft's CoreCLR would achieve the same performance without any proprietary tech, without any code modification.

Besides that, they made a bunch of proprietary changes to Mono to make it run on their engine, and to be able to export to literally any platform under the sun.

A lot of platforms, like iOS and consoles have (or had) a strict no-JIT policy, so they needed to come up with statically compiling code to said platforms. One of the methods they used was IL2CCP, which turned .NET bytecode, into horrible looking C++, full of goto-s, weird labels and structs getting passed around.

Considering some platforms had limitations like you had to compile the game solely with the C++ compiler the platform supplied, not sure if they had a better solution, but it's still horribly hacky.

They've been manually syncing up changes from the more recent versions, but I can't really tell, at what pace.

But the thing is, even the official Mono has never really kept pace with MS's implementation, and recently, after the acquisition, Mono was dropped by MS in favor of the CoreCLR.

I have a 3080 and it basically moves it from "unplayable 10fps in the main menu" to "works just fine, no issues in game" with medium-high graphics.

> This pass is surprisingly heavy as it takes about 8.2 milliseconds, or roughly about far too long, ...

Edit: Checked the vert & poly counts with Renderdoc. The example scene in the article processes 121 million vertices and over 40 million triangles.

I call this kind of thing the “kilobyte rule” because a similar common problem is shoving tens of megabytes of JSON down the wire to display about a kilobyte of text in a browser.

Also, does that mean that easy fixes are available or is this so core that solutions would require going back to the drawing board?

But… why?

It's completely normal in AAA games to have a few imperfect and in-optimal things. Budgets are always limiting, and development times short. Plus, it's a hit-driven industry where payoff is not guaranteed. There are some things you can do (which are usually management-related and not dev-related) to make the game a success, but estimated bookings are rarely on-point. So trade-offs have to be made to de-risk - corners cut where possible, the most expensive part - development - de-prioritized. These are much bigger trade-offs than a single mesh being unoptimized. A single mesh is nothing.

It's a fun fact that this mesh is LOD0, and so is the teeth mesh. But that alone doesn't tank the performance of the game and is probably unlikely to be addressed in lieu of actual performance fixes. The fixation on these meshes in the thread is kind of excessive.

A lot of these comments are quite galvanized so I don't want to add to that - just giving more context.

Finding objects with ridiculous triangle counts is one of the easiest things to do when you have known performance issues.

If they didn't have time to do the first, easiest chunk of the work, then something was far more dysfunctional than "it's one of a million things to deal with".

Staying on top of poly count budgets is like game dev 101.

I don't think it's uncommon even outside of gaming for modern software to have these sort of "hidden fires". Games just get a lot more conversation and a lot of niche problems as a 3D real time application.

No, mate, stop. The state of C:S2 is well beyond anything we should accept as "completely normal". It's a defective product that should not have been released. Stop normalising this crap.

Gamedev has many shortcuts, and some things simply fall through the cracks. Some are caught and fixed, some are caught and not fixed, some just aren't caught at all. I imagine it's the 2nd case here; There's a unfortunate large amount of bgs these days caught by QA but not given time to fix before publisher mandates.

The game runs fine and it's really fun. This "controversy" really drives home for me how detached from reality online discourse often is

It should be better optimized, but calling it "defective" does nothing but make people dismiss your comment.

All this crying when they could have simply returned the product or not buy it at all. Colossal Order themselves warned about the performance before it was even released. There were plenty of reviews that said the same thing.

So to get up in arms about the performance means they are just being exceptionally stupid and entitled, and they should just grow up and stop crying over their toys.

Colossal Order can release whatever garbage they want to. And you can choose to buy it or not, or even buy it and return it (fight for better return policies if you want something positive).

Chances are a nearly complete version of C:S2 was playable and they “broke it” at the last minute by not finishing the optimization process.

“Now you might say that these are just cherry-picked examples, and that modern hardware handles models like these just fine. And you would be broadly correct in that, but the problem is that all of these relatively small costs start to add up, especially in a city builder where one unoptimized model might get rendered a few hundred times in a single frame. Rasterizing tens of thousands of polygons per instance per frame and literally not affecting a single pixel is just wasteful, whether or not the hardware can handle it. The issues are luckily quite easy to fix, both by creating more LOD variants and by improving the culling system. It will take some time though, and it remains to be seen if CO and Paradox want to invest that time, especially if it involves going through most of the game’s assets and fixing them one by one.”

IE: The the game would have looked nearly complete even if none of these meshes where in use. Meanwhile the buildings themselves are optimized.

This really smacks of late asset delivery, which probably happened because delivery dates to the rest of the dev team kept being bumped.

Then, by the time the assets were finally delivered, it was recognized they weren't optimized (as expected), but there wasn't any time to fix that.

Or the same thing with an internal asset team.

Although honestly, you'd think after seeing the performance numbers they would have implemented an "above X zoom level, people / anything smaller than this are invisible" sledgehammer fix, until LOD could be properly addressed.

Better to deal with pop-in than have everything be unexpectedly slow.

If you aggressively min-max development cost & time vs features, there are big external costs in terms of waste (poorly performing software carries an energy and hardware cost,) end-user frustration, stress on workers, etc., which is how I justify voting with my money against such things.

What I don't understand is - how did they not notice that the performances was horrible even high end hardware? How did they not decide to take the time to investigate the performances issues and find the causes we're talking about now?

Optimization is not done throughout the process and later there’s not enough time. Assets are made with bad topology and it would take time to redo them. Or it would take time to write a tool that retopologizes them automatically.

What I’m saying is by the time it’s “time” to optimize, there’s not enough time to optimize. It happens very commonly. But the alternative is taking development slower to do things right. And you simply don’t get investment for schedules like that in most companies. Not to mention that it’s goddamn hard to do when the execs lay off people, ask them to RTO, and induce serious attrition otherwise. Sometimes the team just can’t settle into a good process as people leave it too much. So you’re between a rock and a hard place — on the one hand: attrition and low morals, on the other hand: a tight schedule. This doesn’t apply to Colossal Order from my knowledge, but it does apply to many AAAs.

There is a problem at the root of this - extremely over-ambitious production schedules as norm. Most other things are symptoms. Most of what I described is a symptom.

The scope of work done for this game was exceptionally large for a company with 40 employees, assuming it was done within the usual AAA timeframe.

They even posted on social media 1 week before launch warning people to expect lower than expected performance, and raised the system requirements.

If companies have to decide between prioritising features that they've advertised, show stopper bugs, and performance, guess which one always takes the back seat :)

This is a cop-out. This doesn't seem like an oversight but rather blatant incompetence. You don't just "not pay attention" to this.

This is a well known property of log scaling.

Or both?

sounds like someone never worked on a 1000 dev team. random quirks either go unnoticed or are de-prioritized all the time. Most are minor, more and more moderate to major ones are getting through. That's definitely a publisher issue.

Part of the problem is that AAA is just (IMO) too big and expensive. Devs might actually have to ship a broken game around holiday time just to get enough sales to survive.

And the other extreme can be dangerous too, like how Mass Effect Andromeda's development dragged on forever, and EA let it happen because its such a golden IP.

I think the ultimate solution is to just scale down most studios a little bit, so the studio and publisher can afford to delay. Medium sized studios are the sweetspot, especially going forward with GenAI.

Any small indie studio have to deal with it.

This makes it a 'race to the bottom' style (or a race to the top?) competition, where higher funding gets you more marketshare, but only against lower funded studios. It's akin to advertising budgets. Mostly a zero sum game in the end.

This is not necessarily true any more. I think smaller studios chipping away for a long time are making better games than most big ones.

Well, yes, because it doesn't matter. It is on the top seller list on Steam. I agree with you, but we can discuss fixes till our fingers bleed. In the end, the problem is capitalism.

https://store.steampowered.com/search/?supportedlang=english...

It's not like Sonic 2006 that is forever broken, sold decently at launch and then cratered the series for the next decade to come.

Is this sarcasm? I’m asking seriously. If not, then how is a poorly running game the result of capitalism, and what is the alternative economic model that would produce only high-performance / efficient games?

It's a bit trite to sum that down to "capitalism", but sure. it's the underlying societal buzzword issue

surely, it is the underlying economic system ruining the art of modern video game development!

I got a tremendous amount of enjoyment out of the first instalment of the game, it's a big bummer that I can't give this one a go

I have a M2 Max and GFN is much much easier than trying to set something up with GPT (Game Porting Toolkit) and Whisky, and much faster & quieter too. An RTX 4080 running in their data center means no local heat and noise.

Even with GFN it's laggy and stutters. Totally agree with the article.

Also way fewer cards needed this way, with users being able to share cards through the day instead of each needing their own.

Basically mainframes all over again :)

I don't think this actually tracks, unless the heat is actually being put to use. You don't need HVACs when you have the machines distributed.

> If you're having issues with performance, we recommend you reduce screen resolution to 1080p, disable Depth of Field and Volumetrics, and reduce Global Illumination while we work on solving the issues affecting performance.

This is all I had to do to get smooth performance on an AMD Radeon RX 5700 XT

[1] https://www.youtube.com/watch?v=rX0ItVEVjHc

Maybe they could have gotten away with this with UE5's Nanite, but that much excessive geometry would have brought everything else to its knees.

Exactly.

If unity actually delivered a workable graphics pipeline (for the DOTS/ECS stack, or at all keeping up with what UE seems to be doing) these things probably wouldn't be an issue.

>Unity has a package called Entities Graphics

Well that's news to me. Which means that package probably isn't much older than a year. Definitely way too late for game that far in production to use.

oh, so they rebranded the hybrid renderer. That makes a lot more sense: https://forum.unity.com/threads/hybrid-rendering-package-bec...

I'm fairly certain the hybrid renderer was not ready for production.

Even if DOTS was perfect, the GPU would still be entirely geometry throughput bottlenecked.

Yes, UE5 has a large competitive advantage today for high-geometry content. But that wasn’t something Unity claimed could be automatically solved (so Unity is in the same position as every other engine in existence apart from UE5).

The developer should have been aware from the beginning of the need for geometry LOD: it is a city building game! The entire point is to position the camera far away from a massive number of objects!

> Unity has a package called Entities Graphics, but surprisingly Cities: Skylines 2 doesn’t seem to use that. The reason might be its relative immaturity and its limited set of supported rendering features

I'd hazard a guess their implementation of whatever bridge between ECS and rendering is not capable of LODs currently (for whatever reason). I doubt they simply forgot to slap on the standard Unity component for LODs during development, there's got to be a bigger roadblock here

Edit: The non-presence of lod'ed models in the build does not necessarily mean they don't exist. Unity builds will usually not include assets that aren't referenced, so they may well exists, just waiting to be used.

Luckily it seems like there are pretty simple reasons for the poor performance so I'm hopeful they can at least do something even if they don't have a ton of rendering expertise.

But that means that everything is solvable. There's no need in this game for 100,000 vertices for a logpile, so that should be a relatively straightforward task to fix. And someone can rip out all the teeth and put "Principal Tooth Extraction Engineer" on their resume.

I can easily see this happening though.

Artist starts making assets, asks "What's my budget for each model" and engineering/managers reply with "Do whatever you want, we'll automatically create different LODs later" and the day gold master is being done, the LOD system still isn't in place so the call gets made to just ship what they have, otherwise publisher deadline will be missed.

https://www.youtube.com/watch?v=FQ13OFmRF-4

That resolution is still fewer pixels than a simple 4k display, which modern games seem to drive at 60fps quite regularly if you buy beefy hardware. A graphical gore fest like Doom runs at over 100fps on 4k on the card the author has, so a mostly static city builder should also operate fine at a resolution like that.

It's more for race/flight sim type stuff IMO but if you got it, why not play everything at that res provided it performs well.

Look at images of it from the top, that'll help you understand how immersive it is.

I really wonder how they develop at that place. And what kind of QS they have.I think even applying a crude pareto would improve their games a lot.

Edit: I stand corrected. I wasn't aware that Paradox is also a publisher and even such a big company (over 600 employees!). Still makes you wonder how they go about their business.

…of course those were all built on Dragonfly/Bitsquid instead of Unity so that might be a clue about where the issue lies.

In a way that sent them straight to the top sellers list on Steam. Sadly, today, it just doesn't matter.

Edit: spelling

It's not a Paradox game, they're the publisher. Colossal Order is the developer.

It's a small developer out of Finland, 30-50 employees.

There is no excuse other than leadership are cashing the checks and squeezing the juice out of the company until they close it, which would make sense looking at their semi-recent merger and poor behavior by the CEO.

Seriously, I was looking into Unity at the start of Covid while laid off, and DOTS was "around the corner" even THAT far back!

They still don't have an answer for a network stack, and now LOD is broken? LMAO.

Unity has been a dirty word for me for a number of years. This is the pay-off for dismissing people's concerns and insisting it will buff out eventually.

Oh and I have to mention the cascaded shadow mapping: "taking about 40 milliseconds or almost half of total frametime. ". - 40ms is 25fps all by itself!

Imagine you have a web app written in Ruby using Rails with data stored in Postgres. You have a few hundred tables, millions of rows. Millions of lines of Ruby, CSS, and HTML. Thousands of images carefully exported as JPEG, GIF, or PNG depending on what they contain.

Now imagine being told you need to simultaneously port that to:

- Not run on the web. Instead be a native application using the OS's rendering.

- Not be written in Ruby. Instead using a different language.

- Not use Rails. Instead, use a different application framework.

- Not use Postgres. In fact, don't use a relational database at all. Use an entirely different paradigm for storing data.

- Not use CSS, HTML, and raster images. Instead, everything needs to be, I don't know, vector images and Processing code.

That's about the scale of what moving from one game engine to another can be like. Depending on the game, it's isn't always that Herculean of a task, but if often is. A mature game engine like Unity is a programming language, build system, database, asset pipeline, application framework, IDE, debugger, and set of core libraries all rolled into one. Once you've picked one, moving to another may as well just be creating a whole new game from scratch.

And if you've got a team of experienced Unity developers, some who've been working with C#/Unity for their entire game dev career, switching to C++/Unity isn't the most practical option. While many concepts are similar between engines, you're going to be back at the bottom of the learning cliff for a while.

It sounds like Unity isn't really the problem in this case, it's more about too many polygons, poor use of LOD, and sub-optimal batching (too many draw calls). It was probably more of a time pressure issue than a tech issue, as game development is usually a race against the clock.

Unreal really excels at action games, but you can absolutely implement custom camera RTS controls and such. Batteries included but replaceable.

The question "does X engine support this kind of game" is a bit.. off. You would be amazed at how many features these engines pack in. However: You would also be amazed at how NOT "plug and play" they are. It still takes a TON of effort and custom code to make a sophisticated game.

Microsoft has a similar problem where nobody gets promoted from fixing bugs or maintaining stuff, everyone gets rewarded for new innovative [thing] so every two-three years there's a completely new UI framework or similar.

Although I feel like wanting to start-a-new is a common tech problem, where there are problems and everyone wants to just reboot to "fix" it rather than fixing it head-on inc. backwards compatibility headaches.

Is there any big (or even medium-sized) company where this isn't true? I feel like it's just a rule of corporate culture that flashy overpromising projects get you promoted and regularly doing important but mundane and hard-to-measure things gets you PIP'd.

At another job, at a financial firm I got a big bonus after I went live on November 28th with an upgrade that let a system 10x their max throughput, and scaled linearly instead of being completely stuck. at their 1x. Median number of requests per second received in dec 1st? 1.8x... the system would have failed under load, causing significant losses to the company.

Prevention is underrated, but firefighting heroics are so well regarded that sometimes it might even be worthwhile to be the arsonist

So I wonder: do the same dynamics appear in any non-software companies? If not, why not? If yes, have they already found a way to solve them?

Engineers are also generally encultured into a professional culture that emphasizes disciplined engineering practices and technical excellence. On the other hand, modern software development culture actively discourages these traits. For example, taking the time to do design is labeled as "waterfall", YAGNI sentiment, opposition to algorithms interviews, opposition to "complicated" functional programming techniques, etc.

A huge number of roles casually use the "engineer" moniker and a lot of people who actually have engineering degrees of some sort, even advanced degrees from top schools, are not licensed and don't necessarily follow rigid processes (e.g. structural analyses) on a day to day basis.

As someone who does have engineering degrees outside of software, I have zero problem with the software engineer term--at least for anyone who does have some education in basic principles and practices.

A long history of blood, lawsuits, and regulations.

Preventing a building from collapsing is done ahead of time, because buildings have previously collapsed, and cost a lot of lives / money etc.

Original developer is long gone. Me and another guy are two of the only people (we aren't a tech company) who can re-learn Perl, upgrade multiple versions of Linux/Apache/MySQL, make everything else work like Kerberos etc...

Or maybe I'm one of the only people dumb enough to take it on.

Either way, nobody will get so much as an attaboy at the next department meeting. But, they'll know who to go to the next time some other project is resurrected from the depths of hell and needs to be brought up to date.

If anything, big companies are better about tech-debt squashing, and it's the little tiny companies and startups that are, on average, spending less time on it.

I will preemptively agree that this isn’t possible everywhere; but if you create a good work environment where people don’t feel like puppets executing the PM’s vision, they might actually care and want to do a solid day’s work (which we’re wired for).

Eventually things get so bad that there's no choice but to abandon feature work to fix them.

The business loses out multiple times. Feature work slows down as developers are forced to waste time finding workarounds for debt and bugs. The improvements/fixes take more time than they would have due to layers of crap being piled on top, and the event that forces a clean up generally has financial or reputational consequence.

Collaborative decision making is the only way around this. Most engineers understand that improvements must be balanced with feature work.

I find it very strange that the industry operates in the way it does. Where the people with the most knowledge of the requirements and repercussions are so often stripped of any decision making power.

I won't say procrastination is a virtue. But sometimes the deferred task really does cease to matter.

Valve?

Consultancies are by far the worst, a project is done and everyone moves on, yet the clients still expect quick fixes and the occasional added feature but there's no one familiar with the code base.

Developers don't help either, a lot move from green field to green field like locusts and never learn the lessons of maintaining something, so they make the same mistakes over and over again.

It’s very rare, this is one of the only places I can imagine something like that happening.

Edit: seems I misunderstood, ignore me

So old products are thrown away while new products with similar functionalities are being created.

Both teams are happy. The users suffer.

what does this mean?

Godot has this: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod...

Unreal has this (for static meshes): https://docs.unrealengine.com/5.3/en-US/static-mesh-automati...

Aside from that, agreed: the multiple render pipelines, the multiple UI solutions, the multiple types of programming (ECS vs GameObject) all feel very confusing, especially since the differences between them are pretty major.

They played around with the idea of automatic LOD, but the repo they had hasn't gotten updated in a while: https://github.com/Unity-Technologies/AutoLOD

The closest to that would be looking at assets on the Asset Store, for example: https://assetstore.unity.com/packages/tools/utilities/poly-f...

An exception to that is something like the terrain, which generates the model on the fly and decreases detail for further away chunks as necessary, but that's pretty much the same with the other engines (except for Godot, which doesn't have a terrain solution built in, but the terrain plugins do have that functionality). I guess in Unity's case you can still get that functionality with bought assets, which won't be an issue for most studios (provided that the assets get updated and aren't a liability in that way), but might be for someone who just wants that functionality for free.

[1] https://en.wikipedia.org/wiki/Level_of_detail_(computer_grap...

[2] https://en.wikipedia.org/wiki/Progressive_meshes

Just the other night I wanted to know what it'd take to do some AR development for the Quest 3 using Unity. 10 minutes in I was straight up confused. There's AR Foundation, AR Core, AR Kit, and I think at least one other thing. I have no idea the difference between those, if they're even wholly separate. That's on top of using either the OpenXR or Unity plugin for the actual headset.

Open XR is also an an attempt to make a cross platform layer for vendor specific APIs. Again not Unity's fault. The Unity plugin system is a common interface for all XR devices.

I'd generally support your sentiment but in this case you're picking on things where Unity had mostly got it right.

I know what Open XR is all about but again, it's not clear which you should actually use for development if you're only targeting Quest devices, for instance. A little extra documentation would go a long way.

The same goes for all of the other things so frequently mentioned like their renderers.

This write-up really points the finger at not solving occlusion culling or having good LOD discipline.

Give a person a dedicated optimization mandate and you can avoid most of this. One of the first things I do when I'm profiling is to sort assets by tris count and scan for excess. I wonder if they had somebody go through and strategically disable shadowcasting on things like those teeth? I am guessing that they made optimization "everybody's responsibility" but nobody had it as their only responsibility.

However, I also find the suggestion that because there are other high profile examples of unity projects with performance issues, it must be a problem with unity.

You don’t hear that about Unreal Engine, despite the fact that there are poorly optimized UE games.

Such a bizarre set of assumptions.

There are tools for creating automatic LODs that come with their own pro's and con's. A bad LOD chain can express itself as really obvious pop-in while you're playing the game. There's also these things called imposters that are basically flipbook images of an object from multiple angles that can be used in place of the true 3d geometry at a distance. Those are created automatically. They tend to be like 4 triangles but can eat more vram because of the flipbook sizes.

Unreal engine has nanite, which is a really fancy way to side step needing LOD chains with something akin to tessellation, as I understand it. Tech like that is likely the future, but it is not accurate to describe it as the "way most games are made today"

The fuck up here is whoever was handling the art assets. You simply do not ship a game with such detailed graphics and no LODs. They must've simply been downloading things off the asset store and throwing them in without any regard for performance.

It's not like there's just some "go_slow=true" constant that just needs changing.

I suppose the fact that it runs at all is stunning -- surely you could not get away with this a decade or two ago -- but perhaps it speaks to the incredible capabilities of modern hardware. This feels a bit similar to the Electron criticism, where convenience ultimately trumps performance, and users ultimately don't care. I wonder how this will play out in the long run.

Bizarre and at least for me, equally sad. I long for the days of a tuned, polished game engine squeezing every inch of performance out of your PC.

It is absolutely ridiculous that these developers can get away with releasing a beta (essentially what it is) and setting the full release price without the end user knowing they're a guinea pig.

https://store.steampowered.com/search/?supportedlang=english...

The terrible reputation is self-inflicted and deserved.

It makes the game stay in people's minds longer because people keep coming back to it asking "is it good yet, have they fixed it yet?". It kind of feels it has worked like that for Cyberpunk. If it's a finished game on launch day people will quickly make up their minds if it's for them and then move on.

Personally I would be on the fence about buying it even if it was good on launch and I would probably not buy it straight away. But I might just change my mind if I get reminded of it enough times. Then again I felt like that about Cyberpunk as well and I still haven't bought it.

It has some performance issues. Not the same thing.

But then there are stories No Man's Sky too, which had a miraculous turnaround as well. So maybe it can happen sometimes...

In my opinion, Cyberpunk was punked by the gaming industry to harm CD Project Red. I have no proof at all, of course.

That's a black swan that can't easily be replicated.

Cyberpunk was a good example of that. And the graphs make it really easy to see how it's changed over time: https://store.steampowered.com/app/1091500/Cyberpunk_2077/#a...

On the other hand, there are players who'd rather have the game earlier (like me) than a few months later, despite its launch issues.

The alternative approach -- Baldur's Gate 3 being in Early Access forever -- is fine too, but damned if that wasn't a long wait.

Maybe the compromise is bigger companies being willing to release in Early Access more often. That shouldn't be limited to just indie companies, but any publisher that wants early and broad public feedback.

Especially for a city-builder game (where there isn't really a campaign or spoilers), I don't see why not...

Also, I really wish Apple chose some other name for its Game Porting Toolkit... hard to find relevant discussions in the sea of "other" GPT talk.

CS2 -> Counter Strike 2 C:S2 -> Cities: Skylines 2