hckrnws

https://nitter.net/OSSInsight/status/1703087927763542305

Which just links onwards to https://ossinsight.io/collections/game-engine with a screenshot: https://nitter.net/pic/orig/media%2FF6KVDQPb0AAi4Lj.jpg

If you click through to pull requests or issues created, the trend is between modest and potentially not statistically significant (there's also a lot of red digits).

The stars graph from godot is vertical since last month though, especially given that they already had the most stars by far (67k in August, compared to 43k for the runner-up pixijs) and an account has only one star to give so that's a lot of new interest.

Godot actually has a bit of an issue with too many PRs. Lots of them are just small changes, usability or documentation changes, but they still have to be reviewed.

They need steady funding to have a team of capable full time devs. Their fund seems a step into this direction.

Wait until Hacktoberfest

submits four PRs with spelling fixes for comments

Missteps implies accidents. This was not accidental, it was an attempt at extracting rent - retroactively.

Purely conjecture, but somehow I suspect that private equity has crunched the numbers and decided it's time to milk this one dry.

> but somehow I suspect that private equity

Unity is publicly traded: https://finance.yahoo.com/quote/U

Can’t blame private equity for this one.

> crunched the numbers and decided it's time to milk this one dry.

More realistically, they crunched the numbers and saw that they aren’t making enough money to keep the company going forever. It’s not a secret, because it’s a public company: They need to make more money to survive.

More monetization was inevitable. I know it’s unpopular public opinion, but Unity as it is today cannot exist forever on the monetization model they had in the past. The numbers didn’t add up. They had to change something.

They tried to take sustainable B2B middleware business and make new Google out of it. And they keep failing, but still paying exorbitant amounts to their execs.

According to their SEC fillings their staff almost tripled in just 4 years

> Dec 31, 2022 7,703

> Dec 31, 2021 5,245

> Dec 31, 2020 4,001

> Dec 31, 2019 2,715

Development of game engine is costly and take a lot of resources, but they already had a successful product back in 2019 and long before that. With all that hiring quality of their software was more or less constant (and not too high as always) which means all recent growth was not in their core business.

It's relevant to also add that the entirety of Epic Games is less than 4,000 people worldwide. That's not only for a vastly more advanced game engine, but also for numerous projects like Fortnite, a game store, just absurd amounts of educational material being published, and so on.

I don't really get why companies keep hiring themselves to death. It clearly does not translate to meaningful productivity gains, yet sends their labor and related costs skyrocketing. It's so alien to me from the outside.

Companies don't hire themselves to death. Managers hire themselves towards promotions and kill the company in the process.

That’s not at all now this works. It’s a convenient myth for senior executives to absolve themselves of their own failure to build incentives and sustainable culture.

Managers don’t get headcount without allocation. It needs to be budgeted and approved.

Managers need budget and headcount to hire against. This is given to them by the company with the goal of growing.

In almost every large company the incentive structure is such that hiring is a "win" for everyone involved. It's a win for the HR team doing the hiring, often they have quotas. It's a win for the manager getting more headcount under their umbrella, adds perceived value and status which leads to promotions. It's a win all the way up the ladder, because it adds perceived growth (remember how many VCs used to tell startups to hire and spend fast?).

The decision maker at the top is usually too disconnected from the rank and file to see the bloat. And the ones that aren't tend to be ruthless about headcount.

This is what happens when you are publicly traded. You become a slave of 3rd party Wall St analyst revenue expectations. Only a few CEOs like Jobs can effectively deal with that. Having a CEO like Riccetiello exacerbates the problem.

Most of their losses was in the last 1.5 years. They actually could have been profitable. They are not sustainable because of mismanagement and massively failed bets. “We got greedy but don’t worry, you’ll pay for it” doesn’t have the best ring to it.

They were profitable from 2013 until around 2016, beginning the buildup to IPO...

I don't think that people realistically oppose monetization going up. The main complaint is adding retroactively a new form of monetization with a unverifiable metric that is not bound to revenue.

Sure people wouldn't have been happy with higher fees, but current clusterfuck is an order of magnitude worse.

Charging per install would have been the death of free to play gaming, or just the death of Unity as a mobile games engine.

> would have been the death of free to play gaming

That would have been ... perfect. And when did they back up on charging per install?

That would have been a good thing, to not see "free" services, due to anti-competitive reasons.

Companies subsidize "free" by redirecting money from successful areas to fund new or unsuccessful areas. And in this case of "free" (advert, data collections) games, is basically a anticompetitive dumping ground and is a common trend with monopolists.

> The numbers didn’t add up. They had to change something.

This seems likely, but from what I've been hearing from game devs, the issue isn't the increased fees so much as the fact that they retroactively changed licensing. That they did this (again, after promising not to the last time) indicates that regardless of what the fees actually are, you'd be a fool to enter into a business relationship with them.

> (again, after promising not to the last time)

The lesson to be learned here is to never trust a "promise". Enter contracts that one party can't change on a whim. If a product you're using to run a business can pull the rug out like this, maybe move your business to one that can't.

Unity did have such a clause in their contract until 2019 when they removed it in a click through contract on an update.

So the moral here is "don't patch your software without having a lawyer diff the TOS?" I don't think that's the world we want to live in. I don't think that leaves consuming proprietary software as a feasible option in today's fast moving security landacape. It's fair to call out bad actors who muddy the water to make the world that way.

Sure, but thinking just because it's a publicly traded company "anything goes" is equally deeply misguided. Whoever owns your company or organization, we should always respect and try to do the best for our customers and everyone involved -- we don't get to destroy things in the name of profit.

This behavior is not only destructive of their legacy, the promises they kept, but of course of their own reputation as a game company... I don't see any independent developer choosing Unity from now on (without a radical change for the company) in their right minds.

I'm pretty sure this wasn't the only solution to the situation. If they're going to ruin the company anyway... might as well make it open source. Start charging a large amount for a license. Cut the company size (maybe competition for other open source software is too great, and they couldn't survive at that size!). We have the choice to do the right thing, although many times that isn't the easy thing to do.

This goes even to society at large. No social or economic system can exist without ethics -- to believe so is delusional. Not communism, capitalism, social democracy, or something else(and I think we need some other ideas in the mix... but that's another story!) can function well when individuals don't have a good grasp of ethics. Governments are made of people making decisions, and companies likewise. No matter how much structure you impose on top, if people don't generally cooperate, a good outcome is impossible (garbage in, garbage out). So, like a friend says, "Be excellent to each other, or else..." :)

All that said... Free Software is just a great idea. Why would you not use an engine open to collaboration, an engine that's a public resource, an engine that could never truly pull the rug on you? An engine that can be forked, go in different directions, copied, redistributed.

And we need to support free software too. If you use it, please donate :)

Unity (ticker symbol “U”) has a price to earnings multiple of negative —11.74 and a (quarterly) earnings per share of -$0.51 which was a decline of -26% year over year. That’s pretty much unacceptable for a company that’s as mature as Unity. Most companies are either growth or value stocks and Unity is neither.

Unity’s value was previously in the hype and now is possibly in the voting rights by shareholders. With enough voting rights, I bet you could vote for a 0% commission for your video game company and offer to vote out the CEO/COO/ECT or anyone overpaid if they don’t concede to your demands.

If a company can't get by without mistreating its users/developers, that company should not exist.

> Can’t blame private equity for this one.

Yup, it's Epic which is the private equity rollup. They're innocent, unless there are some Stephen Elop-style shenanigans going on.

A revenue share or a price hike could have sufficed. Not this weird junk

[dead]

They are making a billion dollars loss a year. So with no vc cash available they need to get profitable if they want to survive. You can argue this is wrong way to go about it but they do need to get profitable.

They miscalculated, which is a risk with investments. Miscalculated badly and executed worse. They bet on ads and ads is not the growth market it used to be. They bought IronSource and their main competitor, AppLovin is kicking their ass.

The neglected the core product and have the gall to justify their retroactive change of terms (after sneakingly deleting assurances to the contrary from the TOS and deleting the github repro that tracked transparency after their last PR disaster) with rising costs of maintaining the runtime that’s been falling into disrepair.

Investments carry risk. Investors may dream that it’s ok to get made whole by the game industry they tried to take over using VC money to build a dominating position and then changing terms and extracting rent but this is such an open and shut case of corporate mismanagement, deceit and hubris, no point in even trying to justify that.

If they want to survive, they fire the CEO, claw back bonuses and shares from executives and shrink the company to a size that’s warranted.

Unity can die in a fire, anyone with a choice will know better than to get into a relationship with them now. There’s enough landlords in the industry already with platforms, there’s no room for another extracting value of the hard work of creatives.

Accepting their terms requires broad changes to the industry business models - back to old EAs dream of charging by the download. And it requires open eyes walking into a relationship with a company that every time their CEO makes a shitty gamble will extract the losses from developers.

Burn it with fire.

They bought IronSource because the VC funds that owned IronSource offered a billion investment, they were still bleeding money before the acquisition.

And before the acquisition, AppLovin even offered to buy Unity for $17 bil. I'm skeptical it wouldn't have turned into a shitfest in that direction either given that they would have either focused on mobile exclusively or worked to turn normal PC gaming into adware.

Even now, Unity's quarterly statements are wtf, wth are they spending $500 million a year on "sales and marketing" for.

Unity had 7000+ employees before layoff.

Valve maintains one of the biggest platforms, and their own game engine. Valve also developed CSGO, TF2, and Dota, all popular online games that need constant maintenance (and even big content updates sometimes). Valve also invested in VR and sells hardware.

Valve has 1200 employees.

To me it's easy to see why Unity lose money.

Unity are currently asking for 4% of revenue over $1M for developing the engine and toolchain that game developers will use all day every day. Valve skim 30% of the retail price of the game for the priveledge of hosting a game on their storefront. This is why Valve makes money.

Valve delivers massive value equivalent to entire departments in a publisher through their steamworks system.

Distribution, Analytics, Multiplayer, Anticheat, Publishing Services, Anti Piracy, Storefront, Sales, Mods, Custom Content Integrations, Localisation, and most importantly discovery (things you pay for dearly outside on mobile).

They never had need to convince developers that the fee is worth it and they never had to retroactively change terms of service. They have continually invested into the system and built the trust.

Most of all, Valve chose the long term sustainable business model when everyone else in the industry tried to extract per download charges from gamers. So gamers chose the company that sold them their game collection, just in the cloud instead of nickel and diming.

And developers chose valve because they were infinitely more trustworthy and offered better tools than any of the legacy publishers. They never increased the fees because they made bad bets either (and they had a few like VR)

Yes there’s a case to be made that the 30% should be reduced now, but realistically few could compare Valve to Unity when it comes to execution and long term value balancing for developers and gamers.

I just find it really strange to think of Valve's 30% cut to be value, when its main advantage is being an oligopoly, but Unity's 4% cut to be rent-seeking, when it's the foundation and toolset for the software being made.

It's both rent-seeking.

But I can't help but feel you're willing to twist the facts to defend Unity. I'll list some facts for the readers:

1. The 4% cut is a rumor at this point. It's not confirmed.

2. Unity didn't just announce a 4% cut at the first place. They announced a fee per install. It's an unprecedented business model. No other semi-popular game engine does that, ever.

I'm not defending Unity, I'm just not defending Valve/Steam (also App Store, Play), which is a much, much bigger drain on revenue.

The Unity pricing structure is complicated and badly managed. The fees were previously uncapped, and it allows for edge cases where the fees look like they could exceed revenue. It causes problems for givaways, bundles and Gamepass deals.

Still, for many situations the math works out so Unity is cheaper than Unreal, even before this 4% rumour. You wouldn't want to accidentally hit one of those edge cases though.

The baffling thing is that the new monetization scheme seems especially designed to destroy the freemium/mobile market, which is exactly the market they've been so actively courting the last few years.

If you told me that Unity was going to try and monetize through some strange approach, I would have guessed that the scheme would have favored the freemium approach, not turned it into an extremely risky gamble.

They were going to waive the fee for anyone switching to Ironsource from applovin. They just got too much backlash.

I think it's easier for people to rationalise a simple cut of each sale rather than a fee for each "unique" installation. In the first case you can calculate that percentage easily in a spreadsheet and account for it in your business. In the second case it's totally unknown how to budget for. Should you assume 1, 2, 5 installs per purchase? How much of your revenue does that account for?

People would rather have a higher fee that is certain than a lower but uncertain fee (of course no fee would be best).

It's difficult but you can certainly budget for some truly ridiculous scenarios.

e.g. what happens if you get 20 MILLION installs in a single month?

Answer: You pay $400k with a Pro licence, $200k for Enterprise. Which sucks if you are only bringing in 400k/yr revenue, but with 20M installs this is what you call 'a good problem to have.'

I think the best argument you could make to say steam is a monopoly is to say that their plan is roughly:

1. Make a platform gamers love to use so much that they will still use it even if other stores are literally giving the games away for free

2. Build a brand that your target audience recognizes worldwide and trusts with their entire game collection.

3. "Exploit" the fact that your audience loves your product and brand so fanatically that you can charge the same amount on an open platform (PC/windows/linux) that other app stores need walled gardens (apple/android - literal lockin and literal near-monopolies/duopoly) to be able to charge.

I really struggle to find a way to frame Valve as the bad guy here. It's PC. There's literally nothing stopping you from just installing as many app stores / launcher platforms as you want. And it's not all-or-nothing - people DO use multiple launchers/stores. What gamer doesn't begrudgingly have Origin and at least one of EGS or the Blizzard/battlenet launcher installed alongside steam? And yet people still use steam, and spend the most money there by far.

> What gamer doesn't begrudgingly have Origin and at least one of EGS or the Blizzard/battlenet launcher installed alongside steam?

That's me! Not that I could have had any of those, as far as I'm aware. When it comes to Linux support, Steam isn't just the best, the others are actively bad.

I have EGS installed literally because they give away free games. But their storefront/launcher is extremely slow and buggy in comparison to Steam's.

Yes, tool makers just can't take the same margin as publishers/platforms do. It's nothing new. Microsoft Words can't take 80% (like a traditional publisher) of your book's retail price, nor even 30% (like Amazon).

I'm not "defending" Valve (actually I find it's very worrisome that they're a game developer and a platform at the same time.) I'm pointing out the fact in no way Unity can sustain 6x of employees than Valve.

I'm betting that Unity's customers, which includes a horde of mobile app developers, are a bit more demanding to have (and keep) than the few - if any? - outside Valve who license Source 2.

It would be great if you could be Valve. Everyone wants to be Valve. But you are not Valve. Especially not if you're publicly traded or a private equity rollup - things Valve has stubbornly resisted becoming.

Massive over hiring and random acquisitions are there main reasons why are they here. If they hadn't increased their headcount by 5k and continued focusing on their core products the company would already be profitable (even if revenue would be lower).

At this point it's too late to significantly cut costs, so yeah seems like they pushed themselves into a corner.

The sad part is that it was already perfectly obvious where were they heading after they IPO'ed.

Seems like they’re trying to fund their unprofitable acquisitions by harming their profitable core. They could have spent that money making unity better/more stable. I hope they make it out of this. The unity editor is pretty great.

> They could have spent that money making unity better/more stable.

Public shareholders don't like that. It's not good enough.

It's not at all obvious to me investors who bought their stock after they IPO wanted any of this.

The board and upper management together with their VC backers (they also gave Unity a significant loan to fund the IronSource acquisition which will be exchanged to stock in a few years) seem to be the main driving force behind this.

The only way most public shareholders can express their approval is by buying or selling stock and looking at the share price over the last 1.5 years they don't seem to approve that much.

Trying to run a publicly traded company like a VC bonfire - what could possibly go wrong.

Why would they even IPO if they are bleeding money as fast as they were? Was it one of those SPAC pyramid scams just to get fresh money from people?

because early VCs wanted someone else to hold the bag

The fact that people still don't understand that this is what any IPO is about is funny and sad.

Well because profitability was just a few years away according to their prospectus.

Which to be fair wasn't that inaccurate. Had they stopped expanding like crazy for a year or so the company would've been profitable (with minimal damage to their core product, if not the other way around).

"Purely conjecture, but somehow I suspect that private equity has crunched the numbers and decided it's time to milk this one dry."

They are a public company at this point. Not a fan of PE but no need to blame them for everything.

Unity is a public company, they IPOed years ago.

Instead, look at their EPS. They have been negative since they IPO and never posted a profit.

They can only get anything from it if the stock price goes up though. So far this isn't helping. Also it won't be several quarters until the additional revenue kicks in, by the time they might already be losing significant numbers of customers which the market won't like even if the financial start looking a bit better.

Milk dry, or try to start making money?

That's not true—"misstep" only implies that something was a bad idea, not that it wasn't intentional and calculated.

the missteps was thinking they could get away without so much trouble

Thanks for pedantry, but misstep means "error" or "blunder", not "accident."

No a misstep implies bad judgement, not necessarily an accident.

How is it retroactively? Publishers are only charged for new installs from next year on.

It's retroactive because the publishers originally signed a contract that didn't have any per install fees for that version of unity they're using.

Now, they will be charged, despite not changing the unity version, as if next year. Retroactively applying the new contract terms to the old one.

I don't think what you describe is the case. My company works with Unity and is not worried about any change until the license runs out. Only then will we form a new contract and accept the new terms and conditions. Changing a contract one-sided is not really legal in the EU https://europa.eu/youreurope/business/dealing-with-customers...

What they described is exactly the case. Hence the controversy. Your company should be worried because these ToS changes have been applied retroactively. I agree with you that this is not legal but that is what's happening. Check Unity's own FAQ:

https://forum.unity.com/threads/unity-plan-pricing-and-packa...

Q: Are these fees going to apply to games that have been out for years already? If you met the threshold 2 years ago, you'll start owing for any installs monthly from January, no? (in theory). It says they'll use previous installs to determine threshold eligibility & then you'll start owing them for the new ones.

A: Yes, assuming the game is eligible and distributing the Unity Runtime then runtime fees will apply. We look at a game's lifetime installs to determine eligibility for the runtime fee. Then we bill the runtime fee based on all new installs that occur after January 1, 2024.

Unfortunately, the Unity contract most developers signed ("Terms of Service" I think they call it) allow for them to change things when they feel like it.

This retroactive change is one of the things which people are very unhappy about.

Some more info here, under the "ToS Update" heading:

https://www.gamerbraves.com/unity-silently-deletes-github-re...

That being said, multiple people seem to have different interpretations of it. And Unity has reportedly said they'll be walking back at least some of the changes due to the very public outcry.

It isn't retroactive -- that would mean that they could charge you more for games you sold previously. I'm not sure I would call it retrospective either, as it doesn't change the conditions for existing licences, because you already agreed to their ability to change the price when you first agreed to the licence. Many people were unwise in agreeing to this contract.

You would be able to argue that their various statements over the years have applied constraints on what those changes could be, but I think it is clear they could increase the price. Changing the transition from $0 to non-$0 probably wouldn't stand in many jurisdictions, and they seem to already been walking that back.

It's retroactive.

https://forum.unity.com/threads/unity-plan-pricing-and-packa...

Q: Are these fees going to apply to games that have been out for years already? If you met the threshold 2 years ago, you'll start owing for any installs monthly from January, no? (in theory). It says they'll use previous installs to determine threshold eligibility & then you'll start owing them for the new ones.

A: Yes, assuming the game is eligible and distributing the Unity Runtime then runtime fees will apply. We look at a game's lifetime installs to determine eligibility for the runtime fee. Then we bill the runtime fee based on all new installs that occur after January 1, 2024.

It isn't. Look at the words you quote: "Then we bill the runtime fee based on all new installs that occur after January 1, 2024." The new installs are new instances of the Unity runtime.

I'm really sorry they are screwing you but words have meanings, and this is not retroactive. One legal scholar writes:

"A retroactive statute is one that operates as of a time prior to its enactment. A retrospective statute is one that operates for the future only. It is prospective, but it imposes new results in respect of a past event. A retroactive statute operates backwards. A retrospective statute operates forwards, but it looks backwards in that it attaches new consequences for the future to an event that took place before the statute was enacted."

And of course retroactive and retrospective changes cannot be made to contracts (vs law) without the agreement of parties, or a court decision. Unity is saying you have already agreed to these terms for existing licences, and must agree to new terms for new runtime licences. Something you can dispute in court, but not without significant financial risk.

This is retroactive. The license is accepted via the Unity engine. The games include a Unity runtime and this fee applies to new copies of all existing games. How is this not retroactive? The games were bundled with the runtime in the past. Plus the new license applies to all previous versions of the Unity engine that have already been installed. This is 100% retroactive.

They say that the new licence does not apply to existing installs. However, those installs are counted for determining if you cross the new sales threshold. That is a prospective change.

You're complaining that the licence for runtime instances should be locked to the one that was in existence when you wrote the game (using the editor). This is entirely reasonable, but not a right you have under the old or the new licence. They could change it again!

You had that right under the old license before it was changed and the repo tracking the ToS was deleted. This is a retroactive change. If people are downloading your installer that was published a year ago, people running that installer after January 1st will now cost you money.

The license text being deleted doesn't change the contract, it is still extant, and hence nothing retroactive about it.

You should absolutely disable installations in the future. Pull all binaries from the web and replace them with ones that require an activation key.

If you have made a best effort to comply with the new terms, they cannot come at you for people running an old installer.

"One legal scholar"?

https://www.canlii.org/en/commentary/doc/1978CanLIIDocs18

They used to have a clause that you could use the old terms of service from when you published your game. But it was removed in favor of even games developed under those terms of services needing to pay. That is very much a retroactive change.

I still don't see how that is retroactive. The TOS changed, but I only accepted the TOS how they were when I paid my license. So the new TOS do not apply until my contract ends. That is the law (at least here in Europe)

Because it's not software you can (reasonably) swap out later. Once you've developed your product, it's part of your deliverable. It's like a company changing terms on their engine once you've already built a car around it, and sold them to someone.

Unless your licence says otherwise, each sale is newly licencing the Unity runtime.

The plus side from this will hopefully be people reading contracts more closely before basing their income stream on it.

> The plus side from this will hopefully be people reading contracts more closely before basing their income stream on it.

I thought the point of all this was that they changed the license. So you sign a license to use the product and spent time and money to develop your product... then they change the license so it's no longer profitable for you to sell it.

So I guess the only reasonable solution to prevent that type of thing is for the license to include wording that you have the right to continue to license it under the same conditions (and presumably price limited) perpetually.

You got it. But I'd go further -- what use is thousands of dollars in engine-specific assets for an unmaintained engine version? You should have the right to use new releases of the engine with the existing licence, and maintain feature parity and get security and bug fixes.

I'm sure someone at Unreal is working on asset conversation and API shims to allow porting Unity games, but it's a big change and costly for the developer.

> So the new TOS do not apply until my contract ends. That is the law (at least here in Europe)

Correct, it's illegal. They are trying to do an illegal retroactive change. That's the point.

When does the contract end for someone who started selling their game in June 2023? If it is January 2024, then I don't see how a change to the contract starting on that date would be illegal. If it is June 2024, then I could see how it could be illegal.

"Murder? No, they can't do that! That's illegal!"

Except that here they will not do something to you like a murderer. They might ask you to pay money. But if you refuse I believe they will at most sue you for the money and then lose if it was illegal.

Can you afford to pay the legal fees to prove that it's illegal, even as Unity continues to drag out the fight with procedural motions, appeals, etc?

Can you afford to bet on winning?

It really shouldn't be this way, and I hope that we will see a time when "that's illegal" means that a company like Unity wouldn't even consider doing it. But as things stand, something like this is often only illegal in practice when it's done by people without the resources to fight lengthy legal battles.

Yes, it's illegal. They are still doing it. Make sure they don't have your payment information when they start the first wave of billing in February.

Yeah, and everyone will be back to Unity in a month. People need to make a living, y'know. They need to make games/assets NOW, not in 3 years once those engines are ready.

For example, I see my Twitter timeline full of people slowly realizing that Godot is not Unity 2, and complaining about the UX, GDScript, C# and performance problems.

So, they either have to live on that hill and contribute to Godot (And sometimes these problems are by design! Godot is made to be slow so it can have more usability, just check out the creator's Twitter),

or, y'know, they can (And will) just go back to Unity and keep making stuff, even if they at any moment they'll put a knife on your throat.

Look, Unity did have performance improvements in some aspects over the years but their output / productivity was really really really poor in the last 3 years related to their core product, the Engine.

This is the reason people were already fed up with it, this license change just pushed some over the top.

The trajectory of this project is not good at the moment and that is as much of a problem for users as the recent events.

I started a project 3 years ago and none of the features I based it on shipped with production quality in the meanwhile (and that was the assumption when going in back then, that this will eventually be fixed while development of the game was going on).

Godot is certainly not optimal, that is what people are discussing. The C# and expert userbase was missing. But the fact that people are raising these points meens that they see it worth to comment on. If Godot leadership takes the hint, they might bring their project to a trajectory which allows serious projects to give it a shot. So this time now will be critical. For both, Unity and their competitors.

I think none of the conversations and comments put out there are surprising. But I would argue that if people already had the motivation to switch, they might just go to Unreal if Godot gives them not enough performance. Or stay with Godot if their project is simple enough to be not effected.

Unreal is a viable option for most people. Epic is the devil we know.

It's not. Most of Unity games are mobile games, or indie games that don't require the GPU usage bloat Unreal has in order to achieve better graphics.

If Unreal was ever an option, developers would've been using it instead of Unity in the first place.

In case anyone cares, this commenter is absolutely incorrect; Unreal does support mobile development, and it obviously uses a more lithe package than its full GPU stack. Using only the UI objects, 2D is pretty simple and I haven't had any major package size issues. Using a 3D context to render 2D as planes in the scene, I can still get a package down around 70MB with optimizations left on the table. It's harder to work with 3D-as-2D, but that's why I use the UI system. It's robust.

I certainly like Unreal, myself, but I can't say it's an easy move from Unity to Unreal. That aside, one of the very first options you see is whether to scope your game for mobile or for "desktop", so I'm not sure why this commenter thinks that Unreal would not be an option for mobile development. It sucked before UE5, so maybe that's the hang up, but so did a lot of things.

[flagged]

A sample of apps larger than 70mb on my android device:

- The built in Contacts app

- Degiro (investment management)

- Doubletwist (music player)

- Sony Headphones

Some apps above 150mb:

- Element (chat)

- Kindle reader

- Pocket Casts (podcast player)

I don't have too many games installed but layton and the curious village, a point and click DS port, is 700mb (10x larger than on its original platform of the DS). I guess a lot of that increase is replacing 200p backgrounds with 1080p and midis with audio recordings.

Filesize is a weird one to complain about - that ship has long sailed.

Try not to worry too much about the zealots backlash. Ne thinks I'm attacking a worldview instead of just pointing out factually incorrect information.

It's true that 70MB is very small for games, especially if you're talking about something with 3D contexts and meshes. But it is also true that most mobile games could be built with Javascript and still be just as performant and served as Progressive Web Apps in less than an MB. So, in the frame of reference, 70MB is gargantuan. I certainly understand why OP took offense, because their frame of reference isn't "all games", it's "games that focus on these very specific metrics I care about".

If that's your only criteria, then obviously Unreal would be bad because it doesn't optimize ONLY for size, it optimizes for a bunch of other stuff, and leaves a lot of optimization on the table for devs to do on their own. Of course, all of that is true of Unity too, which is why you can get smaller package sizes (20MB is not impossible for Unreal, but it's easier with Unity), but you still can't come even close to something that is "efficiently" packaged. For that, you'd need to move into lower level stuff like engines and frameworks in Rust or C++. Eschew the niceties of the IDE and really get that package size down to zero!

Of course, that's not feasible for a lot of people, so (as always) you're talking about what kinds of things you're trying to optimize for. And Unreal produces package sizes well within the range of acceptability for even Unity games. Most of those are at least 200MB+. So it's a petty complaint made from a place of self-interest, that is only true in contrived instances, which seemed worth pointing out.

As a stray aside, though: I have had games developed in both Unreal and Unity on the play and app stores and no one ever said anything about performance on either of them, so I really don't know what kind of devving OP is talking about that results in such poor performance. I can't imagine I'm doing anything uncommon, so I'm very curious as to what the hang ups are, mainly in a "are you sure you're doing this the Unreal way, instead of trying to force the Unity way in Unreal?" kind of way.

Yet, it is a common subject on Apple and Google conferences regarding mobile best practices.

Not everyone is living in the first world with flagship devices, unless you mean only those are entitled to play games.

> Not everyone is living in the first world with flagship devices, unless you mean only those are entitled to play games.

Right, but unity and unreal performance were possible to make adequate on my HTC One M7 a decade ago, a device so old that you can't publish apps compatible with it to the play store any more because of the minimum target SDK version rules.

I know. I was pointing out the app size since he said that it's 70mb, and that's absolutely not good compared to Unity (10-20mb).

To be fair I don't care about the app size either (Though once you reach a threshold, you'll have to care, since extra config is involved in the stores), I just wanted to point across how much work you have to do in Unreal to reach what Unity does by default, and app size is just an easy unit to explain.

> To be fair I don't care about the app size either

> Jesus christ. You say I'm absolutely incorrect, yet you're happy with a default package of 70MB?

I highly doubt a 70mb download for a game is upsetting anyone outside of HN.

In fairness, a lot of game devs don't have to deal with high-quality assets which are a thing that can take up most of your space. When you don't have 80 to 100 100-500kb assets (audio, textures, etc), you don't see it eat up space and you don't have to hear consumers file issue with the quality of your graphics or audio, so it's reasonable to balk at such an 'abnormal' package size. Devs get a little too focused on their own metrics sometimes, is all.

All that said, yeah - 70MB is perfectly "small" in the context of a mobile game. Hell, I WISH 70MB was normal. These days, you'll eat up 300MB on a game just so it can serve you an ad network with 80% of your screen time. The mobile games market is a travesty.

Just a reference point, Genshin Impact is 21GB on Android, COD:Mobile is now 15GB, and even Hearthstone is 4GB,

I can thoroughly suggest that you revisit your assumptions post Unreal 5. Since it's current, I would suggest 5.3, but anything post 5 should do. There were plenty of improvements made that are well documented by Epic and many things have contributed to better runtime experiences across the board. You may still not be satisfied, but I can assure you that your current assumptions are out of date.

As far as "hacky workflow", I don't know what I said to make you believe that. The Unreal UI is a vector rendering process. Same as a browser's rendering context. Or most form designers like ImGUI or WinForm or Qt. I used the Unreal UI just like I used any of those APIs - using what they've already provided where it works and rolling my own controls were it doesn't. It's no different either in conceptual development or in literal programming routines than manipulating a website's DOM or a Canvas element with javascript. It is, in short, a 2D context; same as any other 2D context.

Yep, Unity wants 4% from me if that’s what they change? So be it. I can’t use Unreal for my studio and Godot is a pile of garbage for anything serious. Unity knows this.

https://sampruden.github.io/posts/godot-is-not-the-new-unity...

even if 90% of developers giving godot a shot will go back to unity, this will be a very good thing for godot

I’ve been enjoying all the new discussions, comparisons, and content surrounding open source game engines.

Even if it’s clickbait or shallow content, it still raises the awareness of these tools.

Had an audible chuckle the other day when I saw humble bundle's current massive Godot sale. Hopefully with this increased attention we can draw new programmers to gamedev with an approachable language like python.

> approachable language like python

Python doesn't really scale though and it's fine only for simple games/scripting (on top of a game mainly built with another language). If you're serious about game development you'll have to switch to C# or C++ eventually.

Also I don't see how C# is not "approachable" (C++ is another manner). If you're serious about programming you'll have to figure out static typing at some point anyway (and types is something you have to understand anyway when working in Python even if you can avoid that for some time).

> If you're serious about game development you'll have to switch to C# or C++ eventually.

Were the creators of Undertale, Hyper Light Drifter, and Hotline Miami not "serious" because they chose to use GameMaker? I understand the pitfalls of using lightweight scripting languages, but not everyone is trying to create Doom Eternal.

For a certain type of game GameMaker is fantastic. If you know that the game you’re making is going to work with it, or if you’re just starting out, it’s a great choice.

However, you will run into limits that have nothing to do with AAA graphics, and most people are going to eventually want to expand beyond those limits. Clearly not everyone, because there are plenty of people who’d be happy making pico8 games till they day they die. But most people in my experience.

You're right, it depends on the type of the game you want to build. Also I was really only thinking about the "programming" part of game development.

> Python doesn't really scale though and it's fine only for simple games/scripting

IMO GDScript (and any scripting language in games) should be treated exactly as a language only for that (scripting) and anything non-trivial should be done in C++ anyway.

This is often said, but is it really true?

Im thinking of libraries like torch, tensor flow, or pandas.

I'm not sure rewriting torch client code from python to c++ would typically be that much faster as most of the work is already being done on the GPU and is highly optimized (much like a game).

Gamedev - at least engine dev - bears some relation to the embedded & performance-critial world. You have this conflict between needing extremely performant code, as close to the metal as practical, but also needing rapid iteration and to represent high-level logic cleanly. This is why you almost always end up with the juxtaposition of a C++ core and an embedded scripting language like Lua.

Python isn't really performant enough, or at least hasn't been in the past. Performance still matters, even for a scripting language.

In general, if your engine does what you want right out of the box with no modifications, you can go a long way to writing a game in the scripting language and - if you're not pushing it hard - not suffer any real performance issues. But as soon as you want to chase framerates, or do something unique or time-critical or computationally difficult, which is often, you 100% need that low-level language.

It's true right now though there are a lot of people working on different ways to get python to have near native performance. I'd say it could be a fixable problem.

I was listening Lex Friedman's podcast featuring Chris Lattner a few months ago. He's is working on Mojo, which is basically a fast superset of python that can be fast (if you opt in to a few things) and worst case just falls back to being as fast as regular python. The intention is to give people enough means that they can optimize such code to be actually fast or just run it as is.

I'm not much of a python developer myself, even though I do have to deal with it occasionally. I liked the point that he made that, for whatever reason, there are just a lot of people using python and getting access to that community of people is a good way to get traction for your tool or technology. He was talking about machine learning specifically. A lot of the experts in that field are using python. Of course all the difficult bits and bobs are outsourced to native libraries. His vision is that a lot of that stuff should be written in mojo/python and that there are no good reasons why that should be any slower.

Probably removing the gil will help (everything blocking is not cool). And the language could use some better primitives for dealing with things like co-routines. They are kind of nice to have in asynchronous code bases like games or UIs. But those are things that could be fixable and might benefit the rest of the ecosystem.

> Im thinking of libraries like torch, tensor flow, or pandas.

Well the overhead doesen't really matter that much, who cares if you have to wait 10ms or 100ms etc. So yeah rewriting the Python bits is not worth it.

It's an entirely different use case though. In game dev you need fit your frame into 16ms or 32ms and you calling the methods hundreds or thousands of times every second etc. it all adds up.

Not everyone wants to create a AAA-level FPS. Most languages are fine for a large number of games.

> Also I don't see how C# is not "approachable

C# is powerful and performant. I wouldn’t call it approachable though unless your background is Java or C++

It suffers from the same problem as Java: verbosity with endless choices for syntax. Why is this a problem? The “paradox of choice” is debilitating for most people. Also, since there’s no universal consensus over style, you’re going to inevitably have convention wars.

Python has many problems, but it’s easy to see how it became so popular with its one way to do one thing

> you’re going to inevitably have convention wars.

Only if you choose to. Most developers use whatever convention they personally prefer when working on their own code. When you're working on other people's code, you use whatever convention was already in use. If you're working for someone else, you follow the convention of your employer. Simples. No fighting necessary.

Yeah, that’s true in an ideal world. Unfortunately, we don’t live in one.

My point is that each of us chooses whether or not to participate in arguments. Especially when it comes to programming holy wars, which are rarely of actual importance, we can choose not to.

It takes two to tango. No ideal world is needed.

For anyone else looking for any current Godot Humble Bundles: https://www.humblebundle.com/software/everything-you-need-to...

Sad for Unity devs' predicament here, but happy to see Godot gaining increased interest. It's still not as mature as Unity, of course, but they're making steady progress, it definitely seems to be headed in the right direction.

This rather dampened by enthusiasm for Godot: https://sampruden.github.io/posts/godot-is-not-the-new-unity...

It's carrying a lot of performance baggage and there seems to be no sense of urgency in fixing it.

FWIW from the comments i've seen on Reddit it seems that some of the reasons he brought up for wanting to do so many raycasts are already covered by Godot's functionality (in C++).

Also IMO unless you want to share C++ plugins with others (via GDExtension), if you are making a game with it you'd want to modify the engine itself for any non-trivial functionality anyway. Again, the situation he describes sounds like it would be much better done by writing the reusable controller itself as a node written in C++ inside the engine itself (not via GDExtension) that uses the fast physics API directly.

Basically what he describes is an issue only in specific situations and not something that would really stop someone from making their game.

I read that thread too and he just seems like a bunch of people denying there's a problem. The sibling reply here rather contradicts your point as do several others replies in the Reddit thread.

It's something that is known and a work in progress: https://www.reddit.com/r/godot/comments/16lti15/comment/k169...

This subthread is new since I read through and it is much more encouraging. Shame it got lost among all the people claiming there wasn't a problem.

Yeah, it's true that raw performance doesn't seem like a major priority for the Godot community. If it was, GDScript probably wouldn't be the default language. There also seems to be a lot of defensiveness around GDScript's weaknesses.

Personally, I found that signals were very slow for communicating node to node, was dropping information because it could take longer than a frame.

GDScript is much faster in Godot 4.

This is incredible news for those projects. What is the current exchange rate between Github stars and money?

Freedom-wise, Unity is a Delphi/PowerBuilder/Clarion/ColdFusion of game development. The "free as in beer" licensing was the main reason it stayed relevant until now.

I'm actually kinda excited to start learning some of these. How nice of Unity to force me out of my comfort zone!

Godot is quite easy to learn as far as general purpose game engines go. Lots of material around too, I know a lot of people like GDQuest and HeartBeast. Their subreddit and discord are also popular.

Godot seems to be the clear winner in all this.

quick qn for game dev's ?

why was C# adopted for game dev ? compared to java given that they're both similar langauges which use a vm.

I do understand that C# has a better native interop story. than java.

and probably the only notable jvm based game was minecraft

I'm not a gamedev, but my hypotesis is that one of the reasons is that Mono license at the time was way friendlier than risking having Oracle on your neck.

Modern C# also has more features that help avoid allocations, which in turns reduce GC pauses, which are the biggest enemy of a game

Unity and XNA, but mostly Unity.

Unity used Xamarin to target iOS and Android, so this meant using C#. As Unity's popularity grew, so did the use of C# in gamedev.

XNA was a very well-designed game framework (not engine) that allowed many people to get into indie gamedev without learning C/C++ and SDL or OpenGL. Java had nothing comparable, libGDX was released only in 2014. If you followed one of the indie stars and tried to emulate them, you were quite likely to learn XNA or one of its reimplementations.

IIRC they were using Python initially. Turned out it was way too slow (also it was the mid 2000s).

They hired the guy who created Boo (a python like programming language) and switched to Mono (I'm not sure why they picked it instead of JVM I guess it was possible related to licensing but because they just had people who were experienced with it).

Also C# wasn't even their primarily programming language until 2012-2014. It was UnityScript (JS like syntax running on Mono). The idea was that C#/static typing was too scary/complex for most of their uses.

I think its adoption was mostly influenced by XNA. A lot of small (and big) games used the XNA libraries, and by extension the .Net framework and C#.

Java is also adopted by game devs, even if to lesser extent, many mobile games, J2ME and Android, Minecraft, game tools.

However CLR has support for AOT and C++ since day one (even if NGEN isn't that great and only covers specific cases.

C# has thus access to the CLR features needed for C++, while exposing them in a more developer friendly way, and since C# 7 many of those features that required direct MSIL manipulation are being exposed as language features, making it even more easier to use.

C# has had mono which was open source and designed to be embedded, and now we have coreclr, which is also designed to be embedded, very easily. Meaning you can write critical parts of your engine in C/C++ but run C# for core gameplay logic and plugins/extensions.

The JVM isn't/wasn't the greatest to embed and it's kind of a lumbering beast even today.

Also you aren't embedding C#, but dotnet, with which you open yourself up to an entire ecosystem of languages (if you really want to write plugins in VB.NET or F# or IronPython), and a ecosystem of libraries and even Microsoft tooling that's way more polished than Oracle/Sun ever put out.

Do you mean why Unity adopted it, or why people generally use it for game dev?

Unity uses C# for historical reasons - when Unity started, Mono was one of the few options that fit their needs. Outside Unity, C# mindshare isn't that big I think.

Java has been used a fair bit for Android games for obvious reasons, but game programmers are rarely Java fans.

For anyone interested, LibGDX[1] is a very nice open-source game engine for Java. It is cross-platform (mobile, PC/mac, web). Very popular and well maintained, too.

[1] https://github.com/libgdx/libgdx

Probably because most games target Windows.

If the OSS game engines want to monetize their work, won’t there be a pressure to switch to a pseudo-open source license, then push for some kind of licensing structure ala Mongo, Terraform, and Elastic?

I just wonder if they become popular, either the companies that use them organize into a foundation to maintain the code. Or the grunt work has to be paid for somehow.

It's not clear that they are out to monetise, or they may not have made a FOSS engine to start with. Some (Godot, for example) have deliberately set up their ownership and governance structures to make such a source-available/open core pivot if not impossible, then very difficult.

Blender seems like a good example of gaining traction + keeping honest.

Hopefully Godot follows in their footsteps more than those other ones.

Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains.

In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me.

For example I can exchange the DI framework for the whole project in a matter of days if need be.

Which leads me to my question with the Unity debacle.

Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?

I am really interested if someone with more insight on game development could shed some light on that.

Thanks.

The problem is that Unity is a game engine, not a game framework. That means that any code you do will be following their architecture and using their features. The game logic gets really tight to the engine.

...unless you are Brian Bucklew https://threadreaderapp.com/thread/1703163364229161236.html

Note: That is not the "normal" way to use a game engine.

I'm pretty sure when Unity was new all games kinda looked the same. And killed my battery no matter how lightweight they seemed.

How is it today? I'm not sure what uses it and what doesn't any more. That's a good thing, i guess.

Holy porting Batman.

Caves of Qud is definitely going on my watchlist now.

That is glorious. I would recommend that you post it as its own thread.

It was posted recently.

That's absolutely incredible. I agree this would make its own great post.

Can you abstract away your website so it can run on node.js or angular?

Game development is typically very tightly linked to a mess of proprietary tools and products and platforms. It is the game engine itself that abstracts away for example) the payment/subscription api.

If you were to write your own game abstraction layer we would call what you did a game engine.

Secondly, performance (frames per second) is key in game software. Imagine if you wrote a lightweight abstraction layer for a physics/gravity engine. You’re effectively writing code to slow down your game FPS.

Thirdly, game development is often done by young beginner programmers, who often don’t even know programming yet. They get into game programming by following online YouTube tutorials in a specific game engine. If you know the importance of abstraction your already too high paid to work in a game development position :)

> Can you abstract away your website so it can run on node.js or angular?

This is an excellent point. At that point you'd need so much abstraction that you'd basically be building something as complex as the underlying engines.

In rare cases that works out, like for Caves of Qud, but mostly because of the nature of the game: https://news.ycombinator.com/item?id=37548720

The best most folks can dream of is decoupling some of their game logic or mechanisms from the engine somewhat, like what Captain of Industry did:https://news.ycombinator.com/item?id=31588018

That said, I'm surprised that engines like Stride or NeoAxis don't try to imitate the Unity API more - making porting from another engine easier, or being able to reuse some of your existing skills would surely be a good selling point!

I read the Caves of Qud post. What exactly is he using a game engine for in the first place? If it can be completely swapped out like that then maybe it wasn't that important in the first place.

Ease of porting and platform support.

Yea, to be fair, you can abstract away some parts of games to be sure. You can usually put non graphics related game logic, data persistence, networking into a shared library in your preferred programming language as long as that language can expose its api using a c layer or some sort.

>If you know the importance of abstraction your already too high paid to work in a game development position :)

Way to tacitly admit the gamedev space is a fundamentally exploitive industrial vertical.

There's 3 kinds of dependencies. The best way to describe them that I have found is a metaphor with the Terminator movies.

* Libraries are tools that your app uses. For example, the JSON parsing library. They are relatively easy to switch from, as they are (usually) used for very specific tasks. For the terminator, a library would be a shotgun.

* Frameworks are pieces of software your app embeds into. They have a set of conventions and procedures that condition the shape of your app. In exchange, they provide a lot of baked-in functionality, which is usable by your app right away. Ruby on Rails is an example of a framework for web development. They are more difficult to switch from, because your code is "shaped" in a certain way and it relies on the framework to several tasks for them. For the terminator, a framework would be a motorbike. It's difficult to jump from a running motorbike to motorbike, if there's a T1000 chasing you on a truck (that would be a deadline). It can be done, though. Much easier to do if you prepare in advance.

* Game engines are similar to frameworks, except the dependency goes deeper. Your game is not embedded into the engine. Instead, it is made of the engine. Unity is a game engine. It's very difficult to switch from one game engine to another one. The engine would be the terminator's endoskeleton - the metal skull, torso, arms and legs, plus the initial "bios". Your game would be the living tissue put on top of that metallic frame, as well as the directives programmed in the brain ("Protect John Connor").

It's not really possible because a game engine works differently from a library.

A library is a component that you add to your application. While it might be opinionated in the way it presents its interface, you can typically build some kind of abstraction layer on top of it and swap it out with something else in the future.

A game engine basically is the application, and your game builds on top of it, filling in the game logic, assets, level design, etc. The earliest game engines like Unreal Engine 1 were basically just the game Unreal with all the game-specific bits stripped out.

An engine is more than just opinionated. It determines the general application flow and structure, how each component is conceptualized in the architecture and how things connect. It even determines which programming language you can use. You also just use a lot of components from the engine: rendering, input handling, physics, animation, networking, parallelism, asset processing, etc. Things of that scale would probably be separate libraries for most other types of applications.

Beyond programming, much of your work will be in engine-specific formats that simply cannot be automatically converted to another engine: project files, level design, component connections and settings, graphical programming and shaders, animation state machines. You could design all of this in your own custom formats and build it programmatically, but why would you take that development overhead when engine's editor already does it so well?

That's not to say that porting from one engine to another is impossible. Assets like graphics and audio can be moved with no or minimal adjustment. Game design is still the same, and typically most concepts are similar enough between engines that you can do a line-by-line conversion for most of your code. And some games really do use Unity more like a rendering and input library, Caves of Qud is one example. But those are rare and most games will simply require a lot of elbow grease to shift engines.

In other words, game engines are frameworks. Porting from Unity to Unreal may feel like porting from Rails to Django: not an impossible task, and you can keep some key bits, but you have to rewrite and rethink a lot. (Ruby and Python are even closer than C# and C++.)

I would agree with the parent poster that game engines are more than frameworks. They often begin with a platform abstraction layer, contain a framework on how to structure your tools and data, often contain an embedded programming language, have custom data formats, and determine the syntax and semantics of how you build the rest of your game.

Then in order to move between one engine and another it is a far bigger task than just switching programming languages and frameworks (which in web development are very similar). You will need to do things like:

Re-import all of the external assets that you have created in external editors. Things like meshes, rigs, animations, textures, sounds, music, etc. These may require changes to adapt them to the new engine, and it assumes that you still have the original data for all of these (which is often binary and very large in size).

Then re-create all of the specific in-engine assets that you don't have external sources for. These are things that game designers often create and describe the elements in the game, like character, vehicle, item definitions, loot tables, experience curves, etc. In addition to these being engine specific they're also fairly manual to create.

This of course assumes that you can easily bring over the world/level data from one engine to the other. At best it will require sufficiently skilled programmers to write an exporter for the old engine and an importer for the new engine. At worst it will require designers and artists to recreate the levels by hand.

Then the last thing mentioned would be changing all of the automated processes to the new engine and educating everyone in the studio on how things are meant to work.

The web based analogy for all this would be rewriting the code in both a new language and framework, changing the frontend from HTML/CSS/JS to Latex (or something), moving the data in the database to another style of data storage, and converting all the images from PNG to JPG.

More than port, I would call it conversion.

I don't feel like an expert, but I'm a full time Unity dev with experience on non-Unity AAA projects.

There are the obvious advantages of having a pre-built editor, standard environment, fantastic build tools, and generally handling a lot of the complexity of managing a project, particularly in the early stages.

It's possible to limit your use of the engine to these time-savers, and essentially use it as a front-end for your game, however many workflows within the Unity projects make heavy use of engine-specific features which become an integral part of the game over time.

Rewriting scripts to not make use of the Unity engine's C# features isn't necessarily major challenge, depending on how reliant you are on engine-specific features. But when you've set up dozens of entities and items using Unity's animation state machine UI, laid out your levels in Unity's editor, and saved hundreds of different reusable assets as Unity-specific "prefabs", setting up all the relationships in your project which aren't determined by code would be a massive time sink.

> when you've set up dozens of entities and items using Unity's animation state machine UI, laid out your levels in Unity's editor, and saved hundreds of different reusable assets as Unity-specific "prefabs"

Perhaps this was a mistake.

Or may be not. People commit to use a tool, so why not doing it fully so you get the most benefit from it?

It makes everything harder if you want to use a tool without really using it so you can move to a different one if needed.

1. Unity projects mainy use C#. So that automatically limits the frameworks you can switch to unless you want to port to a new language.

2. A fair chunk of your code will be calling in to the Unity runtime to use functionality provided for you. This may not exist in other engines or exist in very different form

3. Unity controls the gameloop and the renderer. Other engines might have very different architectures and constraints.

4. Abstractions cost performance. You're usually trying to hit a very tight millisecond budget per frame so adding extra layers of abstraction is not good practice.

> In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. ... For example I can exchange the DI framework for the whole project in a matter of days if need be.

Game engines aside, this is a very late 90s/early 00s philosophy that has really not stood the test of time. The code that strictly follows this principle ends up looking like Enterprise FizzBuzz[0]. Trying to do this results usually in a lot of time spent building an abstraction layer around one thing, and that one thing not actually being replaceable because it was only ever built or tested with that one thing, so trying to replace Thing One with Thing Two is even more work as you now have to rip out both Thing One and adjust or remove the abstraction layer around it.

Abstractions aren't free, and the more complex the library you're trying to abstract, the more expensive they are.

There's nuances to this of course -- it's a lot easier to write a custom wrapper around a logging library than a DI framework, for example. But in general if you're using a third party library, things end up cleaner if you just commit to it rather than write an abstraction layer.

[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

My very limited understanding (speaking only as a professional software developer but not a game developer) is that there’s very rarely an abstraction that’s common across multiple libraries in the same domain, or that, in order to make an abstraction that could be adapted to different libraries, you would have to give up a significant amount of performance.

This worried me as well when I started looking at Godot. It seems like it is, like other game engines, designed to not really allow you to separate your code from the engine code in any meaningful way.

The only things I have thought of, or seen others do, is to separate the game into a native library, or even a separate server process, that handles the game-world part of the game, and then use Godot as the front-end (client) gui only. But you will miss out on many of the engine's features since a lot of it is built around mixing on-screen objects with game-world objects. There isn't really any separation at all between what happens "in the game" and what is rendered to the screen.

But building the game from the ground up using Godot nodes, with a bit of GDScript here and there to tie things together, is definitely easy and very tempting to do. It pushes you towards that easy way of doing things.

I'd say a big part of it (aside from the valid "framework" comments) is that game engines abstract over a large and complex mess related to graphics card APIs on different platforms. That abstraction is of the type that basically forces game engines to be frameworks, as opposed to libraries. If you want your game engine to run games on Mac, Linux, Windows, Android, iOS and the web, the game engine needs to "wrap" the game. Or at least this "wrapping" makes both game engine and the games simpler to write. But as mentioned, it means switching a game between game engines isn't really realistic - you write a unity game.

> Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?

The simple answer is:

Yes, you 100% can, if you code it like that from the very begninning.

No, most people don't, because most game engines are not desiged for this so it's extra man-hours with no visible value.

Yes, it is possible, but you need to use a game framework not a game engine.

Example of a game framework: http://www.monogame.net.

Still, if you don't map everything all the time, common value types will propagate through the codebase.

Even if you code against MonoGame/XNA or a similar framework, migrating to another framework is not a trivial task unless you have written an abstraction layer beforehand, cf. Player.cs from Celeste.

leave it to modern MBA's who see all businesses in terms of numbers on a spread sheet to send perfectly good dairy cows to slaughter for a short term payday.

harvard business school has ruined this country with their elitist graduates.

Remember the time when each game company had their own engine? And that led to many technological marvels, like RollerCoaster Tycoon by Chris Sawyer, to name one. Now innovation in game engines seems to be stalled, as big ones are just looking how to push more ads, instead of more polygons. Maybe building own game engine will become a thing again?

> And that led to many technological marvels, like RollerCoaster Tycoon by Chris Sawyer, to name one.

Game engines for modern AAA games are too big and complex to be just one person these days.

> Now innovation in game engines seems to be stalled, as big ones are just looking how to push more ads, instead of more polygons

This is just nonsense. Unreal 5 shipped with Nanite and Lumen for 'more polygons', and have been adding features to it over the last 3 releases. Unity shipped a bunch of features (I'm not as familiar with unity) related to raytracing in their most recent release.

Can you make a 3D isometric perspective game easily in Unreal? Can you do it in Unity?

Do you have to fight against the scene graph or whatever they use high level to do that?

In both cases, that's literally just a flag for the in-game camera.

Yeah but how about infinite tiles dynamically loaded, for example, like in any ARPG?

I have no idea, just thinking FPS roots means they're designed for discrete levels.

> Yeah but how about infinite tiles dynamically loaded, for example, like in any ARPG?

Yes, see [0]. As for procedural generation and that sort of thing, there is a new feature that supports it out of the box in 5.3 but before that you were able to write your own procedural generation (just as you would in unity, or your own custom engine ), and spawn actors.

> I have no idea, just thinking FPS roots means they're designed for discrete levels.

It's been a long time since that's all UE was suitable for. There's been JRPGs, third person shooters, racers, MOBAs, puzzlers, platformers, made in unreal in the last decade.

[0] https://docs.unrealengine.com/5.1/en-US/world-partition-in-u...

Stars are not feature parity.

Who is saying that they are?

The way people behave.

I'm still not fully convinced that Unity's new pricing is unfair. The retroactive aspect of it is certainly troubling and I've seen some fair points about how policy implementation will likely be messy. Moving onto the pricing itself, I've only seen it brought up on a couple occasions that the actual stores these games are being sold on are taking a way larger cut in most cases then what Unity is asking for (For reference, Steam, Apple, and Playstation: 30%, Google: 15%, Epic and XBox: 12% -- please correct me if I'm wrong about any of these).

The flat pricing model will disproportionately effect cheap mobile games, which I suspect was on purpose. Even then, I hardly see this as a problem. Just scrolling through the top games on any mobile store, most of it looks like low quality crap produced by large companies that figured out a successful formula for virile games. The only empathetic party I can figure in this mess is indie mobile game developers, which seems like a pretty small category of Unity users, certainly not commensurate to all the huff people are making.

So?

This isn't the first time unity made drastic changes without warning. Sure, people are upset above the new pricing but they're really also very upset about the rug pull.

Sure many people love free stuff. However, 1) Unity isn't free 2) People understand that businesses need to make money. If Unity instead explained that they're losing money hand over first and need to change things up and here's a bunch of ideas I bet Unity could've landed a run-time fee without all this complaining.

The App stores provide distribution for software. This is network, storage and eyeballs.

Unity doesn’t provide any value for the marginal install that it is charging for.

A better comparison would be to Unreal which charges a royalty after $1M of revenue. Kind of sucks that it is percentage based but seems more sane to tie it to revenue than installs.

Its the install tracking and fees related to non revenue metrics that really has people super mad.

The install tracking will be borderline malware based on Ironsource's reputation. All they needed to do was take a cut of revenue.

Without that, people wouldn't be as mad.

I think the core reason for how intense the outrage is is the installations are completely unpredictable for developers. If Unity had went to a revenue split it simple royalty per sale people would be upset but ultimately it would have died down. It's the unpredictabilty that is really the problem.

Indeed. As a user who has played Unity games in the past this change makes me want to stay the hell away from games built on Unity in the future. There has been little transparency on how they're tracking installs and what other data they're harvesting while they're at it.

> I'm still not fully convinced that Unity's new pricing is unfair.

Maybe. Although the per install stuff is beyond idiotic.

However, starting last week, no one can trust them to not change their minds at any time and retroactively.

>The flat pricing model will disproportionately effect cheap mobile games, which I suspect was on purpose. Even then, I hardly see this as a problem. Just scrolling through the top games on any mobile store, most of it looks like low quality crap produced by large companies that figured out a successful formula for virile games.

The point was for unity to make money off hugely profitable free-to-play games (like falls guys, among us, genshin impact, and pokemon go). Unity is not aiming to make the quality of games go up.

I think we are saying the same thing. In that quote, I am clearly am not claiming that Unity's aim is to increase the quality of games. Their new model is meant to cash in on successful games. Some of them, like the ones you pointed out, are good games that absolutely can afford to pay the royalty. Many mobile games on the other-hand, are terrible and really only profitable because they make slim margins on lots of downloads. I for one, don't really care that those games hurt as a side a effect.

The backlash wasn't against the new pricing but against the absurd metric and the retroactivity of the change. It broke the trust in the company

Why is heaps.io never in those lists? It’s not event in the wikipedia page.

I love Heaps! In general, game engines without builtin GUI clients aren't as "popular" on these lists.

I do recall Heaps initially not having a huge focus on beginner-friendly documentation (and lots of warnings about stability in general). I'm not sure if this is still the case. Other than Nicolas, there aren't many other devs working on it that I've seen.

Do those stars come with donations?

> Do those stars come with donations?

Some of them, yeah!

Godot has almost doubled how much money it gets from the community: https://fund.godotengine.org/ (though that sum should probably be much, much higher)

Here's their stats from a week ago: https://web.archive.org/web/20230912192257/https://fund.godo...

Sadly, those figures are for perhaps the most popular open source engine that's friendly to indie developers, which means that other engine developers really can't count on much funding at all being there. Reminds me of: https://staltz.com/software-below-the-poverty-line.html

Coco's Creator bucking the trend and dropping downwards, any obvious reason?