Hacker News Reader

Comment by thsbrown | Hacker News Reader

As a game developer with a released mobile game made with Unity I'll admit I had very mixed feelings about the news.

On one end it makes me wonder if Unity has it's priorities straight. On the other, I think there is definitely a lot of room for improvement with their own ad solution. Not too mention in order to fund any further improvements in the engine Unity needs to make money. Given that they produce no games of their own, it makes sense that they are expanding and improving their suite of services in order to bring in more revenue.

At least that's my hope. Unity has been in a rocky place for a while now (straddling the line between what it is and what it wants to be) and I think news like this combined with the layoffs can lead many to wonder if Unity is still committed to making a world class game engine that can grow with them for years to come.

View on HN

> Unity has been in a rocky place for a while now (straddling the line between what it is and what it wants to be)

Yeah, they tried to compete with Unreal for some reason, and of course they lost. And when doing so they made the engine worse for small creators. For example it got a lot slower after they changed the asset database in the 2019.3 version, it feels horrible to use after that and just creating a new project now takes minutes.

It feels like they tried to compete with Unreal in the same way that Apple tries to enter gaming: very half-hearted attempts that they think are very serious. With Apple it’s “hey look we are a serious gaming platform. Look we have 3 new APIs just to support gaming and we paid a AA/AAA developer to port their game eventually” and with Unity it’s “Hey we can compete with Unreal. Look we even have new render pipelines with some of the features Unreal has and we bought Weta for some reason. Look we even put out a demo that barely works that we will never update showing just how graphically advanced Unity can be.” They both think these meager attempts are actually some great effort when it actually requires large investments of time and money to get where they say they want to go. E.g. Microsoft buying their way into the console market with the original Xbox. Basically just hemorrhaging money for an entire console generation so they could finally compete the next generation with the 360.

microsoft could afford it though

And Apple can't?

Apple’s gaming “strategy” — air quotes seem mandatory — continues to baffle me. It’s as if every year or two they put more pieces into place for a future that never comes.

(I’ll believe they’re serious about gaming when they release their own port of Vulkan.)

As a game dev and not a small creator I'd say Unity feels far more consistent and bug free, both editor and runtime. I can't say it's much faster but I wouldn't say it's slower.

I profiled this before and after the change using the same code files, the asset reload time is definitely much slower, and asset reloads also triggers a lot of times unnecessarily, often it reloads assets once when you select the editor window, and then it triggers another reload when you hit play, and then it triggers another reload when you end play, effectively reloading the code three times every time you change anything and test. This doesn't always happen, but it never happened before the change for the same code, maybe you can work around it but it isn't obvious what is causing it. The engine isn't slower, but the editor is much slower.

It might be that this improved some things for larger teams, but for the projects I've worked on it was a huge downgrade. Unity marketing said this change would speed things up for large projects, but for small projects with small assets and mostly code things got much much slower than before, which was my point that when they try to compete with unreal they are making the editor worse for smaller creators.

I'm not the only one experiencing problems, here is a thread:

https://forum.unity.com/threads/assetdatabase-v2-refresh-sig...

Wasn't fixed last time I checked. Might be fixed in some beta release.

What do you mean by a reload, exactly? If the asset isn't changed it won't be re-imported. If you're seeing erroneous reimports, then that is something you can track explicitly.

If you're talking about code compiles or script reloads, that's not really what the asset database deals with. (Although you can script imports so its not entirely unrelated).

That said, they did a lot of work to allow you to handle larger projects with (albeit manual) incremental compilations with asmdefs and the like.

I'm also pretty sure they also didn't add more code reload points, they just added load bars for when they did the code reloads. If you don't want the code to refresh automatically, you can just turn it off.

> If you're talking about code compiles or script reloads, that's not really what the asset database deals with.

Editor profiler says the asset database v2's AssetDatabase.Refresh calls a function named roughly ~"reload all assemblies". That happens every time you add an empty line to a default code file and at many other times. This didn't happen before, and that is where it spends most of its time.

> That said, they did a lot of work to allow you to handle larger projects with (albeit manual) incremental compilations with asmdefs and the like.

I haven't been able to work around this with asmdefs, if you use an assembly then changing any file in it trigger the above mentioned code reload.

> I'm also pretty sure they also didn't add more code reload points, they just added load bars for when they did the code reloads.

Editor is unresponsive for longer. I know they added more bars, but it is hard to mistake an edit/play cycle taking a second in 2019.1 and then taking 10 seconds in 2020.3 in the same project.

> If you don't want the code to refresh automatically, you can just turn it off.

I want things to reload automatically, disabling that is not a fix.

Reply on news.ycombinator.com