It’s briefly hinted at in the article, but this game uses Unity ECS. Unfortunately, the rendering side of things of that tech has been… garbage for a long long time. Even 1.0 comes with the caveat that it might be (ha) worse than the standard rendering paths.
It seems that their team fundamentally underestimated that risk and backed themselves into a corner of having to write their own rendering bridge layer — and failing quite spectacularly at it. Bummed for them.
I’ve shipped one very high profile game and another much less so that use ECS. For both games I was never so crazy as to commit us to any ECS packages outside of the core and NetCode. From the start of each project I knew that we’d be bridging the ECS sim with regular Unity GameObjects for visuals — which sounds crazy but actually works quite well . I hope that there is a day when a game can be full DOTS without caveats, because despite the tech’s struggles I remain quite a proponent of the design patterns.
> From the start of each project I knew that we’d be bridging the ECS sim with regular Unity GameObjects for visuals — which sounds crazy but actually works quite well
Yes! That's precisely what ECS makes sense for, complex internal game logic. It's questionable over-engineering at the game engine layer, where you care about rendering and physics and not much else.
Depends, if you just need to update position/rotations you can use a TransformAccessArray which is supported with jobs+burst.
When you need to pull data out of a dozen components to keep a renderer in sync, yea that’s not cheap. But there are ways you can flip things around, like have a job that outputs a native array containing condensed info about the entity that will be used for rendering. That avoids non-bursted random data access into the entity, but of course adds some additional complexity.
This approach won’t naively scale to thousands and thousands of GameObjects like all the (boring) “look ECS can do 10000000 entities at once” demos. I get so, so, so tired of “scale” being the only sexy reason why you pick DOTS. Both my games have a resident set of a couple hundred entities at any given time and still, DOTS works great for how we use it.
This is how you get people to never buy your games again. Please whenever you plan to release a game, add an entire year to that date, but work as if its due in exactly 1 year prior, and internally re-adjust and figure out "if I were to release in a month, what's the MVP", once you have a stable game, use the rest of your 9 months or so (assuming it takes 3 more months) and polish and add in any nice to haves that make the game feel more complete. I feel like Starfield could have used with maybe 6 months of content-only additions. Cities don't feel like in Fallout or Elder Scrolls, too many useless NPCs running about. I liked being able to stalk people into their homes and know their routines, its a little harder in Starfield to figure out who even is a non-useless NPC.
I got sidetracked, my original point was going to be, anytime Bethesda releases a new Elder Scrolls, Fallout or now Starfield esque game, the first thing I hear about is all the bugs, despite being a day 1 player and rarely running into bugs that really mean anything crucial (like crashing). Once you leave a rotten taste in your customer bases' mouth some of them will refuse to buy your game even if its the GOTY.
If you are a PM at a major game studio, start making a shift in how games are poorly made. It is really embarassing. I used to justify not pirating games because I know a lot of hard work goes into them as a developer myself, but with how crappy some games come out, I'm not sure I can justify buying or pirating games anymore, they're just so awful. Also all the DRM that does nothing to pirates, and ruins gamers systems in various unexpected ways.
The only thing worse for a company than burning customers who might choose not buy their next product is if they fold before having the opportunity to release another product.
Early in my career I was a minor participant in discussions like this (albeit not in the video game space) and no one was in denial about the massive reputational cost of prematurely releasing buggy software, they were just balancing it against the increasing probability of bankruptcy.
Established companies with deep pockets and startups with shoestring development teams and patient investors might be able to weather a delay of six months or more, but most companies don't have that kind of runway and must constantly weigh the bottomless desire for more time to polish and the need for cashflow to make payroll.
(Thankfully the last couple companies I've worked for have had deep pockets and a strong desire to protect their reputations, but I appreciate that this is a privileged position.)
Very good point, which is why I think its crucial to also stop and plan on fixing bugs as #1 priority and descope some features, or hide them altogether until they are ready. I can appreciate how complicated these things are, everything is a tradeoff. Thank you for your insight, I've mostly worked for reasonably large companies so I have not yet been able to see things from the perspective of a much smaller company first-hand.
Yes, the company I work for now is medium-sized but it is stable and run by engineers so fixing bugs take precedence over shipping a feature by some artificial deadline. At the end of the day our customers and field folks understand that our feature roadmap is an estimate and not a promise. From what I can tell, many of our competitors operate similarly.
But this approach is extremely difficult in some domains. If companies in a particular domain routinely make what you consider to be obvious mistakes there are a couple possibilities. It could certainly be herd mentality and they just need someone to remind them to do more QA and to fix bugs before adding features. But it could also be incentives that resulted in the companies that cut corners outcompeting companies that did things "the right way".
Let's say we wanted to adopt this stance. The world doesn't stop turning. How do you fill the year of gap you've now introduced? What do the quarterly financials for the next year look like? Is your plan to just tell all shareholders, "Our company plans to make $0 in the next year because we want to implement this practice which might make you more money in the long run - but no guarantees on that except that we'll definitely take longer to build"?
The answer is to have your cake and eat it, with Early Access.
You get a stream of cash whenever you launch an even somewhat finished game. You get a mountain of early feedback and real world testing, without the negative PR. And then, when the game is ready, you do the full launch + marketing with (from what I can tell) basically no PR/hype penalty from being in early access, as its a new game as far as the storefronts are concerned.
Maybe I am missing a big drawback, but it seems like such a no brainer. And it clearly works at any scale, see Rimworld (lone dev) and Baldurs Gate 3 (mega dev team), which coincidentally are among the most critically acclaimed games ever.
I agree, this is the sweet spot. It's a shame early access is full of worse games. It's funny because BG3 had a lot cut off from the early access for a while, which is what I would suggest, cut out all the incomplete things, feature flag what isn't working reasonably well, and enable it once its ready, much easier with Early Access.
Yeah, the most successful early access campaigns are started when the game is "finished and playable," but not necessarily complete
Rimworld was exactly like this too. It had a forum alpha, then a beta, then a polished early access release. The mod community was already raging before it even hit Steam. All this made the game that much more impactful when it hit EA and more features started rolling in.
Game studios want to plan to release a game in X months; the commenter you're replying to wants them to plan to release a game in X + 12 months.
Why not plan on releasing the game in X-6 months? Is their plan to tell shareholders "Our company plans to make $0 in the next 6 months because we want to implement this practice... etc?"
A company can also stagger game releases; work on more than one game simultaneously, offset by 12 months or so. You still get a yearly - or whateverly - release cycle, but you avoid the burnout and the bad press of a rushed release.
A company works on multiple games at the same time, yes. Some of those games are exploratory and have a low likelihood of seeing the light of day. Some are rehashes of proven formulas with good confidence that they'll be profitable.
Something goes awry. The "known profitable" game is very much so behind schedule. An executive decision is made to give development another year.
There is now a gap in the release schedule. Leadership shops around and talks to the other teams. They say, "If you can promise me that you can ship at this time then I can promise you your game will ship. If not, then I can't make any promises because our primary game is taking the launch slot a year from now and the world might be entirely different in two years."
Those leading the less important game go back to their team with the news. They say, "Hey. We have a real opportunity here for this game to see the light of day, but we will need to make concessions to do so. Do you want to try for it?"
Most sane teams respond by saying "Yes, we will make that work" because no creative wants to work on a game that fails to see the light of day.
This results in a game being shipped in a state that is perceived as being rushed by consumers. The game was rushed, but there was never a guarantee that the game would release if not rushed.
Is this an idyllic scenario? No, but it is a pretty good scenario compared to what could've happened.
But the finance people don't want THE game. They want A game that is ready to release that fits into their quarterly financial statements. Predictable cash flow has a lot of value. It's not just about knocking every opportunity out of the park.
Companies absolutely DO NOT want TWO games ready to release at the same time because the marketing attempts will cannibalize each other. So, when one game takes longer to develop than expected, and a release slot opens up, another game must fill that slot, even at the cost of quality, because releasing multiple games at the same time is untenable.
I'm not aware of how long this game had been in development, but with Starfield, Fallout etc, they're buggy at launch, but they at least have the content to justify release.
Sometimes the "release because it's Q4" approach is important simply because the game is such an irredeemable mess that delaying won't really help. I think simulation games are also likely to be more prone to this kind of thing because the content is more "centralized" (ie in Fallout you can have dozens of teams simultaneously working on unrelated side quests, but not really in a simulation game).
KSP2 being a glaring example of this kind of thing.
Personally I don't like how games feel when they are hitting sub-30FPS. Nothing to do with action or reflexes, everything just lags. Games, especially, should feel snappy at the least.
Honestly, as time passes the bigger issue is seeming to be issues in the core simulation. Parts of it aren't implemented, parts of it are tuned very weirdly, parts of it are just bugged, parts of it don't display information to you accurately, etc. You can find more and more complaints and weirdness as people dig into the game implementation via decompilation and manual testing. There's also issues like the mod system being promised right after launch (weeks/days?) and getting pushed back months. I think these are the issues people are more frustrated with at this point. None of this is the end of the world, but as someone who bought it, it kind of doesn't feel worth spending time on the game when it's clearly half-baked.
Strategy gamers are incredibly whiny and entitled in my opinion. I struggle to remember a strategy game or DLC released by a major studio recently that wasn’t review-bombed on release. And yet studios aren’t going out of business, indicating that people are getting value out of these products and repeatedly buying and enjoying them.
This really frustrates me because it makes it very difficult to actually determine what games or DLCs are worth buying. If every release is reviewed "mostly negative" on steam, then the reviews don't help inform you about the quality of a game.
If you look at steam reviews, it’s even more frustrating - you’ll get negative reviews with 20, 40, even 80 hours of playtime.
80 hours is a good number to review a game at though, you even saying this means you don't understand the basis for why people review games. If someone puts 80 hours into something and regrets it, it's useful information to know.
The opinion of someone who only put in an hour and got bored will be shallow. At best they can complain about new user experience, but that's it. an hour isn't long enough to understand the game systems of a sufficiently deep strategy game
I might have a lack of perspective here, but the line "If someone puts 80 hours into something and regrets it, it's useful information to know" just doesn't map for me. I can't imagine a game that someone is enjoying enough to play for 80 hours, but then they end up regretting it. That just doesn't seem possible. It might just be that I'm out of touch and experience games differently than others though.
To disagree a bit further - 80 hours is a really long time! If it takes you 80 hours of game time to notice an issue, it's probably not a major issue and rather you've gotten bored of the game and are now hyper-sensitive to every little bit of jank or questionable design. It's like the people who will leave a negative review on a survival game with thousands of hours played - the problem isn't the game, it's that they got bored! If after two weeks of enjoying playing the game full time you don't feel like you've gotten your money's worth, you might need to lower your expectations.
Oh - I'll throw a quick exception for games that are predatory. If after 20/40/80 hours the game changes such that you need to start dropping a bunch of cash to keep progressing, that's deserving of a bad review to warn others to stay away lest they end up paying much more for the game than the sticker price indicated. Addiction machines designed to absorb as much of your income as possible like some sort of drug-dealing mosquito suck and deserve to be called out.
Interactivity changes things. A lower frame rate can also make input feel less snappy, which is obviously something you don't run into in film. The frame rate in a film is constant, so there are no variations or drops as there are in rendered games. Those drops and variations can be more noticeable at lower frame rates, even if they don't affect playability in a simulation game the same way they would in a fast-paced shooter.
Films also naturally have motion blur which makes fast movement look softer and less jerky even at relatively low frame rates.
With that said, frame rates being around 30 probably shouldn't really be that big an issue in a simulation game. People who are used to faster frame rates will notice the difference -- again, games are different than film -- but it shouldn't be that big a thing.
But it's worth noting that if those are the figures people get with new high-end systems, that probably means reasonable but less high-end or slightly older systems will have to settle for even less, to a point where performance could actually be an issue.
Maybe if Mac didn't make for such an anemic gaming platform with weak hardware. Even the most powerful pc's can't run this, I don't expect any arm-based platform to ever outside some hobbled mobile variant.
It actually does run reasonably on a Mac if you run it under crossover with a patched DLL [1]. Even with the overhead of multiple translation layers I’ve seen people hit 30fps as a baseline. Not saying that’s great by any means, but it’s got three translation layers at that point.
Importantly, the game is largely CPU bound and that is something that the Macs are really good at. The game is really bad at taking advantage of high end GPUs but it actually scales reasonably as you go down the tiers precisely because it’s so bad at using the GPU. And yes I know it currently has bugs and comical oversights that thrash the GPU, but it does so pretty equally, seemingly responding better to more VRAM (which makes sense given the nature of their inefficiencies)
I’d also push back on the “anemic” wording. A base M series Mac is probably the best iGPU performance vs Intel/amd iGPUs. And the higher end MBPs (not accounting for value) are very performance competitive against similar form factor laptops. Where they fall behind is when you start comparing against larger desktop replacement laptops or on the desktop end against the top end GPUs. But I wouldn’t call them anemic by any stretch of the imagination either.
https://www.reddit.com/r/macgaming has a surprising number of people you can see messing around with running ports natively. I wouldn’t get a Mac for the express purpose of gaming but they are reasonably capable, and largely held back by lack of software not hardware.
M1 series is pretty solidly middle of the road hardware relative to the discrete laptop GPUs that dominate the Steam Survey results.
The bigger issue to me is that gaming on Macs has a history of mutual avoidance by both gamers and gamer publishers. Neither want to invest in changing the status quo.
Not sure why you’ve been downvoted when your statement is largely true. This isn’t even controversial. As with most public companies, the products WILL gradually get worse over time as the shareholders attempt to extort more profit from each customer while adding as little value as possible to their product.
Games are unique that folks seem to want to purchase on release. I have friends who will wait for the 3rd point release (or service pack/ whatever) of windows to upgrade, but will buy a game as soon as it’s available and complain bitterly about the bugs. Games aren't like they were when they were pressed to cd/dvd anymore. They don't seem to see the irony of this.
It's because games are more like media than software from a consumption perspective.
People want to watch a movie while it's still new, which is why theaters want up front exclusivity. Songs are "hot" for a while. TV shows are better when you're watching it around the same time as a lot of other people. Sure you can watch Breaking Bad for the first time right now, enjoy it, and have some good conversation about it with a few people. But it was different when every week half of your office or classroom was talking about the latest episode.
I still don't recommend buying games on launch date most of the time because of the current state of the industry. But it makes sense to me why people do it.
Those are very different things though in terms of risk assessment .
If you upgrade to a broken OS version, that affects a massive number of things you do on your system including possibly your livelihood.
If you install a broken game, the issues are almost always completely isolated to that single game, and games are things you can live with being broken.
I think the point is that these are people well aware that a new release of any software is going to have issues, yet they still buy the games at launch.
I think anything of any kind from publicly listed companies increasingly seems to suck. Only exceptions are a handful of companies where the brand identity or a very ambitious personality at the helm (Apple, Tesla, NVidia) allow them to make the kind of bold moves that private companies do. Apple doing Apple silicon probably would’ve made shareholders very uncertain, but they just did it and it was a great call. Tesla doing Dojo, Powerwall, Optimus, etc, is only because everyone can just point to Elon and say “he’s making us.” That’s private company energy.
There seems to still be a lack of incentives to write good software. Until the fines for data breaches or bad releases become dangerous to the existence of the company, this won't change.
Why are simulation games so hard? Because they try to do too much. Ideally a game should be from the point of view of one person - a mayor, a general, a President, ... Instead many such games go down into multiple levels, so you're not playing just the President, but all her cabinet members and technical experts.
That's definitely fair, and the sales for these games prove that point. Still, if you're making a game that has a high level of detail from multiple perspectives, that's going to lead to high performance requirements - Vic 3 being another example.
It seems that their team fundamentally underestimated that risk and backed themselves into a corner of having to write their own rendering bridge layer — and failing quite spectacularly at it. Bummed for them.
I’ve shipped one very high profile game and another much less so that use ECS. For both games I was never so crazy as to commit us to any ECS packages outside of the core and NetCode. From the start of each project I knew that we’d be bridging the ECS sim with regular Unity GameObjects for visuals — which sounds crazy but actually works quite well . I hope that there is a day when a game can be full DOTS without caveats, because despite the tech’s struggles I remain quite a proponent of the design patterns.