[saint_angels]

Unity is a prime example of getting it wrong, as they aren't making their own games with their engine. When you go beyond small experiments with it, you realize that many undercooked, janky, abandoned features were driven by business needs, not developer needs. If there is only one reason why unity was never as good as Unreal for "serious" game development - it's this.

[cnity]

Unity actually started doing this while I was working there[0], and then eventually axed it[1] as part of a broader shift towards low quality high revenue mobile development (acquiring ironSource, for example). This shift was highly demoralising for the entire organisation, as it included laying off huge swathes of creative staff from Gigaya development (and other teams) and hiring in areas of monetisation (read: advertising and tracking).

Unity is no longer a games engine company, it is an ad company. It is taking surprisingly long for people to see it this way.

It was really sad to me, because (possibly naively) I saw joining Unity as a potential opportunity to pivot more closely to game engine programming (from web), but that was an uphill battle given that the resource allocation was massively in the opposite direction.

0: https://blog.unity.com/games/introducing-unitys-latest-sampl...

1: https://80.lv/articles/unity-stopped-the-production-of-its-s...

[johnnyanmac]

Yup, real shame. There were also a number of teams working on internal projects specifically for dogfood-ing as well. To my knowledge those teams all dissolved as well (but that was nearly 2 years ago now, maybe things changed for the better).

>Unity is no longer a games engine company, it is an ad company. It is taking surprisingly long for people to see it this way.

to be honest, I wasn't aware half of unity's revenues were ads until I worked there. Online gaming discourse has such tunnel vision for AAA console games that it is very easy to miss how over half of gaming revenue is mobile, which is where Unity rules in terms of market share.

[saint_angels]

thanks for sharing this, I guess Gigaya was announced and axed in such a short timeframe, that I've completely missed it

[dindobre]

Couldn't agree more on the business vs actually making a game needs, the amount of half-baked stuff in Unity is shocking. Our docs are littered with pointers to forum threads explaining why some workaround has to be done because yet another known for years problem is still unsolved

[mihaaly]

Its kind of funny trying to figure out how something - and actually what - could be done with it together with scores of clueless - and many times unpatiently frustrated - community participants. I feel like the Unity developers find it funny to watch too, otherwise they would not redo half baked essential 'solution' (inaccurate choice of word here) units into a different but a little bit more complicated half baked solution without proper explanations, so using Google in lack of real help would shuffle clueless chatter of the poor bastards ironically titled 'users' and 'community' ('support group' would be more proper) about multitude of versions together. Nice game of puzzle trying to figure out what the heck is this about on the end. If you are there just for fun.

[npinsker]

Plenty of "serious" games are made in the engine -- Genshin Impact, Hearthstone, Marvel Snap, Among Us, Pokemon GO, Beat Saber... is there a reason those games are worse than something made internally?

[PeterisP]

Yes, the point is that having an internally developed game would mean that when issues and inconveniences are identified, they force valuable improvements/fixes to the engine (which benefit the product and others) instead of workarounds by the external game developer in their particular game.

[saint_angels]

it's possible to make good and big games in Unity, but you can't rely on many Unity features in that case. Like, I'm sure there is barely any "Unity" in Genshin Impact, I bet they replaced most of the engine with custom tooling.

[whstl]

It's been a while, but I worked on some Unity stuff in the past (I had a decade of C# experience back in 2013), and this is what I saw for a lot of mid-size-to-large games (but nothing AAA, and definitely nothing compared to Genshin Impact!).

On a lot of those, the engine is more of a bare-bones renderer: only one Scene is really used, all entity instantiation and level loading is done by a user-land script. Some physics/collision was very custom too. Editors were also almost always custom, on larger games you write custom tooling, mid-sized ones preferred packages from the asset store.

Perhaps things are different now. Character movement was 100% offloaded to packages, but now there are more capable systems (I haven't kept up). But I still see a lot of chatter about how to do this kind of thing in forums, etc. Anyway, that's what I remember seeing, so: IME and YMMV, of course.

[saint_angels]

> Perhaps things are different now.

hehe, no. Things are pretty much the same. Source: I'm working with Unity daily.

[Log_out_]

All those don't use in house tooling for lots of stuff. This is a situation similar to android were some libraries from Google are useless basic implementations. Pointing out that android is widespread does not invalidate the point.

[bzzzt]

Talented developers will overcome the 1000 papercuts and build something worth playing. That doesn't mean it's the best solution.

[Ekaros]

Also pouring enough time and money and resources in product will solve issues eventually. But does not mean things could not have been better or cheaper.

[speps]

Unity did start making their own demos, but it seemed more to catch-up with Unreal Engine which did it since the start (eg. Unreal games where the name comes from).

[mihaaly]

Feels like they had a grand idea but got tired pretty soon after starting to realize. Now it is just fiddled around like with any Microsoft products.

[Dzugaru]

There are far more games that were made with Unity, not Unreal, I would even say an order of magnitude more. So I don't really get your point? Unity is vastly easier to jump on, so a lot more people actually make games and test things (not knowing the quirks of the engine inside out, like a game engine developer would).

[saint_angels]

> There are far more games that were made with Unity, not Unreal, I would even say an order of magnitude more.

that's correct. As the saying goes, it's easier to start making a game in Unity, but it's easier to finish it in Unreal. Most games in Unity are pretty small, or unfinished.

[KronisLV]

> Most games in Unity are pretty small, or unfinished.

By that reasoning, aren't these games the majority of the market and therefore the engine is a good fit for it - starting and working on arguably smaller indie projects and such, as opposed to some hypothetical huge game, of which there are decidedly few? I think that's why Godot is also a pretty good engine, even aside from it being open source, even if the features aren't all that mature - it's easy to iterate in it, even faster than in Unity.

I found some stats: https://steamdb.info/tech/

  Unity has 42160 games.
  Unreal has 11701 games.
  GameMaker has 4498 games.
  RPGMaker has 2939 games.
  PyGame has 2273 games.
  RenPy has 2213 games.
  Godot has 1170 games.
  
  All the other engines together have around 6000 games.

[PoignardAzur]

Steam used to be notorious for hosting a massive amount of shovelware and asset swap (I think they tightened it up a bit?), so I don't think these stats are as significant as you imply.

[KronisLV]

Ohh right, then we might need more data about the ratings and/or profits of each game, to properly figure out the relative... utility of those engines, in making profitable and well received games?

[johnnyanmac]

>aren't these games the majority of the market and therefore the engine is a good fit for it

it's the Pareto principle, I suppose. There are tons, tons, tons more small games than large ones, but the large ones take the lion's share of the revenue. So it depends on how you approach games.

[PeterisP]

The point is that the engine developers don't get a reality check that a particular feature is janky and needs a change, since noone in their organization has ever actually used that feature, and the external developers who could identify that need have no ability to change it.

[raincole]

JavaScript is the most popular programming language on GitHub.

It doesn't mean it's a good example of how to design a programming language.