Hacker News Reader

These issues are definitely real and need to be fixed. However, I do think that the URP/shadergraph pipeline has been unfairly maligned -- I've gotten some great results with very few bugs using HDRP as a solo dev (granted, the target platform is PC and it's running on a newer non-preview release). I made this game exclusively with shadergraph and HDRP deferred rendering and it runs quite well -- https://youtu.be/Vwu7gTVgDzo

That looks amazing! Well done.

Thanks! It's the first game I've made that will actually be released, I'm excited to see people play it.

I would also add their animation system is crap. If you try something like Animancer, you will never ever want to interface to the AnimatorController stuff because is so badly designed.

Overall their business model of providing some kind of foundation to be filled up with plugins is terrible. I don't have an issue with plugins, but needing to rely on plugins for the very basic things like input management, localization, animation, source control... Just so they do less, and earn more (because otherwise people would just wouldn't pay for that, presumably?). That's a shitty way to run a software company.

Only recently they have started to care, but I think it is too late, and it will be hard to beat the momentum that Godot already has. I would bet that in a couple years the tables will turn and Unity will be juggling to keep their market share.

Their WebGL export template update broke the loading bar (unityProgress callback returning 0% then 100%).

I got into an argument on the Unity forums with a maintainer about whether this was a necessary feature. That was surreal, and I think spoke volumes as to how it came to be broken in the first place.

> This is completely unlike Unreal, who has always released games using their own engine.

I wonder if the Unreal Engine team's testing includes recompiling and retesting shipped Unreal games to make sure engine updates don't break backwards compatibility.

That's an issue you don't have if you provide source code.

If a customer relies on bad architecture/undefined behaviour, that shouldn't pull back all the other customers that want their subscription materialize into engine improvements.

Then buy Unity's source code license.

Unity doesn't have a single source code license or price. It's negotiated per-contract and usually has strings attached (e.g. be the first to ship this tech, attend UnityCon and give this demo). They only do it for big companies as well.

I know, that is anyway what I am used to in corporate sales.

There are videos of a Gears of War PS3 port floating around, which was used for testing purposes.

I would also try to completely redesign how mobile builds work in Unity. Instead of Unity creating a brand new xcode / android studio project every build - it should be able to take an existing xcode / android studio project and just add the Unity build to it. That way, theres no more stupid post-process steps that inject all your native code plugins into your xcode project. This step is super fragile and constantly breaks. You can keep your xcode project updated manually and the mobile plugins would no longer need to develop their unity build pipeline.

I am quite sure Google, Microsoft, Nintendo and Sony gaming and AR/VR business units already test Unity enough to give it tier 1 treatment on their platforms and 3D API integrations.

I would add to this:

1. Their package/plugin system sucks (last I tried it anyway). It basically just seems to download a bunch of junk files for every plugin without any intelligence, and if the package updates you have a big mess on your hands, trying to combine your app code with the newest plugin code.

2. You are pretty much forced to use C#, even though the company has more money than god and could easily fund grants to allow for great variety of language options. By siloing themselves within the C# ecosystem, they will likely never have an ecosystem of third party development tools that could improve the lives of their users.

Agreed about packages - you can no longer make custom updates to them to them either if they are installed via the package manager. They didn't think through their package manager before rolling it out. And now that it's out, it's going to be super hard to change it.

Yes you can. Just copy the files into the Packages directory and edit at will.

Yeah, we just did this this week to work around a bug in the URP package, it does work.

The old package system definitely sucks. The new system has promise but until it works for asset store assets it's a bit limited.

You can actually use F# quite well in Unity, I've done it, you just need to develop in a separate visual studio solution. Debugging is a bit of an issue too but it is a reasonable experience overall.

You can also develop native plugins and doing so with C or C++ for certain things isn't uncommon. In this case you mostly want to avoid interacting with Unity APIs though and just write standalone code that Unity code calls into.

There's lots to complain about with Unity but it's not all bad.

Custom asset import is also much better than for Unreal, even making an asset exporter is easy.

If for example the target is to re-make an old game in a modern engine, Unity is the better choice.

They could have picked Python or something even worse like C++. At least they back-tracked from the absolute worst option - JavaScript.

> If I was Unity, I would setup 2 internal game teams. One team building PC & console games, another team building mobile games. Build real games, release them on the app stores, and keep them updated for 2 years. Who cares if they don't make any money, that isn't the point. This is a realistic usage of the engine and it would expose problems that Unity doesn't seem to know about.

The reason Unity doesn't do this is pretty simple, and it's the same reason people get really angry when Amazon begins to manufacture high margin products themselves and pushing other sellers out of the game.

Epic has no qualms with such things, and it seems like there's no end to what they can get away with, so why wouldn't they?

>The reason Unity doesn't do this is pretty simple, and it's the same reason people get really angry when Amazon begins to manufacture high margin products themselves and pushing other sellers out of the game.

I think you do not understand why people are angry with Amazon. Say there is a dude that discovered that he can make money if he sells coffee cups with black cats painted on them, Amazon then runs an SQL query or run some ML and find all profitable products including the coffee cups and they then find where the dude buys the cups , negociate a better deal with the manufacturer, make tons of money and the dude gets frustrated.

Unity making 2 games would not upset the developers, they could make the game "open" for all customers so anyone can learn from them.

> Unity making 2 games would not upset the developers

See Epic v. Apple.

Making games is a huge liability if you’re a game engine. Making a game store even more so.

Unity has made plenty of “demos” as you’re suggesting.

Why is it a liability? It’s how every other commercially licensed engine was built in the past. Unity is actually unusual in that respect.

See id, valve, unreal, crytek.

Because you're competing with the businesses who decide your fate as an engine. If you're Valve, you want games to be on Steam - and you'll push for that when games use your engine, even if it isn't explicitly stated or even intentional. This doesn't make Sony and Microsoft happy, obviously. You might argue that the platforms are different, but that continues to become more and more irrelevant as it becomes easier to release the same game on many platforms and crossplay becomes more commonplace.

As a result, these marketplaces will try and favor some other engine, such as Unity.

I think it's tough for the average techie on here to really grasp the nuances of business (mostly due to lack of direct XP), so I'm not going to belabor the point.

In theory you have a valid point, but in practice it just hasn't been an issue. See the previous commenter who pointed out that every engine company, with the exception of Unity, has always released games on their own engine. I have literally never seen any complaints about that.

I understand that there is potential a conflict of interest involved... but Unity's customers also want an improved product. It's a competitive disadvantage compared to unreal that they don't dogfood their own product.

Direct product flaws in Unity are more likely to push customers away to a competitor compared to nebulous business relations conflicts.

You seem concerned about app stores, I think this is a different topic, I do not remember of any engine that is forcing developers to use a specific app store but I could see it happening that some engine will get features that would create such a dependency if used.

A different solution I think works is to have the developers do support , you have your regular support handle the first contact but then have support forward non trivial stuff to developers and have them respond to customers. After a dev has to tackle same weird issue over and over again with support he will have the idea on how to make the thing more intuitive or less buggy.

Epic vs Apple is not about developers getting upset on an engine maker.