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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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).
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).
> 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.
> 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.
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.
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.
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?
>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.
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.
I think the main problem here is with transitions between animation states and matching each animation to the context.
If ML motion matching[1] becomes popular in the industry, I think it would smooth out these issues a lot.
I remember this being solved over ten years ago, without ML, there was this software that seamlessly blended between poses and activities (morphine or something like that?). I wonder what happened to them. Unreal 5 also has similar tech.
can't find anything on "morphine", but animation blending is something that Unity/Unreal/etc had for a while. Although, I don't think any publicly available engine solves this like Ubisoft ML models do. Usually it requires at lot of work to look seamless
The demo was a blender-like environment, with opaque white human models. You could shoot arrows at them, bullets, switch between poses and animations or set up obstacles to watch them react realistically and tumble around.
I use it to receive money from another country and exchange for USD in a local exchange point.
It may sound like a boring case, but if you find yourself in a foreign country without working bank cards, it might save your ass
I've heard good things, but I've only played the voiced-over version of DE - I'm not sure if I'd be down to read everything, and the different voice actors really add another layer
torment is better imo with writing on par with disco. Disco is great but depressing. Torment is more escapism while still being similar to disco in that it's intensely original like nothing you've ever seen before.
Coincidentally, I've never played Torment and installed it just 2 days ago.
Disco's world is depressing, but because the world is so dark, any light in the game stands out so much more. It's depressing world make good people in it and any small kindness matter.
torment is pretty dark too. It's gritty and harsh, but it leans more in the fantasy direction rather then down to earth the way Disco is.
Also disco is more of a slice of life while the plot of torment though still incredibly dark is more epic. Disco bleeds immersion. But to achieve it they stripped out pretty much all the fantasy elements out of the setting and story. Torment manages to achieve immersion while at the same time making the setting more epic and fantasmic then anything you've ever even seen. The writing and setting is better then basically almost every fantasy novel out there.
In fact Disco reads more like a contemporary novel then it does fantasy or sci-fi. Torment is grounded in fantasy but it's dark and gritty enough that it doesn't feel fake like the final fantasy games. I would say it lies somewhere in between a standard bioware RPG and Disco.
Back in the day, when protocols were more trusting we would play games by storing data archives in other people's SMTP queues. Open the connection and send a message to yourself by bouncing it through a remote server, but wait to accept the returning email message until you wanted the data back. As long as you pulled it back in before it times out on that queue and looped it back out to the remote SMTP queue you could store several hundred MB (which was a lot of data at the time) in uuencoded chunks spread out across the NSFNet.
I watch these things and I begin to realize I'll never be as intelligent as someone like this. It's good to know no matter how much you're grown there is always a bigger fish.
I agree that there will always be smarter fish, but you can definitely be this smart it just takes the proper motivation ( or weird idea ) to wiggle its way into your brain.
I have an LG flip phone that I use for testing phone systems. I believe it runs some form of Android. It's mostly okay, but typing messages with the keypad requires much slower input than the flip phones of yesteryear. Otherwise, typing too quickly will miss inputs. The rate is something between half a second to a second every time you press a key
