It might be a case where they're projecting costs and a pessimistic Fortnite market a few years out. I doubt this something you do after the money is gone. You'd look ahead and see your runway in a down market is way too short and cut costs.

You can't just bet the farm on dropping a new $5B/year game.

The point is that Proton puts them in a win win position. If Windows stays popular, they're fine. If Windows tanks, they're fine.

If Windows tanks their fountain runs dry.

What is the scenario where windows becomes so unpopular, computer games stop being made entirely instead of another OS filling that gap?

The industry will adapt quickly, especially the part that's using multiplatform mainstream engines like UE/Unity.

Lots of new/recent native MacOS releases nowadays: https://store.steampowered.com/macos

A game can be massively popular but many many games fail to hit the mark. Many do not see success and many do not even ship.

Ok, but Fortnite is a massively popular success, even as its popularity slips. Fortnite's run so far could have sustained Epic for years, even without other revenue they get from things like Unreal Engine. Games as a whole may be a risky venture, but we're talking about Epic here; the mystery is not how to succeed in games, but how a company that had an earth-shattering run of success in games is now in such a position.

Just because it's popular, doesn't mean it's financially successful. Take a look at YouTube. They lost money hand over fist for decades.

We put AI in our AI so the AI is already baked in.

AI hallucinates, AAII stutters

You'll note that those are both B2B fumbles. The savvy end user usually doesn't have the needed weight.

I think the real sin is just cutting against the grain on your services and library boundaries.

It's not that hard to version and deploy multiple services and libraries. If you need the flexibility of that separation, it can very much be worth it.

But if you separate them and still treat them like you're in a mono whatever and you cut corners on keeping your separation clean and clear, you're going to have a bad time.

Either pattern has its advantages. It's best to remember that they're just a pattern and you should be doing one or the other for a reason.

Look at Mr. Never seen an off by one error over here. I realize that putting a remote service call in between functionality adds complexity, but this is just so laughably hyperbolic.

I've found fencepost errors but AFAICR it was always somebody calling somebody else's code with the wrong semantics.

To be fair, those markets are dominated by entrenched market leaders.

Can you name one? Why so coy?

Was it actually correct? How would they tell?