Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unity Software Inc S-1

sec.gov

Post reply on HN
Print view View original

201–210 of 294 posts

Re: Unity Software Inc S-1

#201

Post by ezconnect »

johnfn wrote: post #159
DonHopkins wrote: post #153

Earlier quoted context omitted.

You should usually only call GetComponent in your Awake function, then cache the result in a strongly typed instance variable. This is widely known standard operating procedure with Unity. IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method. https://blog.jetbrains.com/dotnet/2019/02/21/performance-ind... >Unity has a number of methods that get…

Totally and completely agree with everything you've said, but the fact that Rider - a 3rd party IDE - has to ensure all these things rather than them being baked into Unity is part of the problem.

Unity is a game engine first, the quality of their product will suffer if they have to teach all their user to program properly.

Re: Unity Software Inc S-1

#202

Post by gentleman11 »

formalsystem wrote: post #22

Out of any software tools I use frequently, Unity is the one that brings me the most joy. Any reasonably complex interface is essentially a game whether it's a music composition app, simulator, MMO or even a basic form. The basic abstractions of entities and components sometimes feel like they could apply to any software project. It's seamless to animate something, add physics, style in ways that would seem mind bogg…

I was a fan of unity until they retroactively changed their asset store license. They revoked some of your usage rights in a cash grab in February (specifically, the right to let freelancers use your assets, so now you have to buy them their own copies). How can you depend on a company like that for the crux of your business when they use their “we can modify these terms at any time” clauses in a predatory way against you?

Re: Unity Software Inc S-1

#203

Post by ezconnect »

nabla9 wrote: post #105
volkk wrote: post #38

Earlier quoted context omitted.

Alternatively, I found Unity super intuitive and straightforward when learning game dev. I was doing some random 2D platformer tutorials on udemy, along with a bunch of others and I always thought it was almost..easy to build that kind of game. I'm sure 3D is a different beast. Full time I'm an SWE, and I realized the way you structure your code depends on you. Disclaimer: I didn't get VERY far and didn't make huge g…

Is Unity still "Easy to build, impossible to maintain", always breaking code after you upgrade?

Yes, that's why you can have different versions of it on your development PC and run the version you are using.

Re: Unity Software Inc S-1

#204

Post by johnfn »

Vermeulen wrote: post #199
johnfn wrote: post #100

Earlier quoted context omitted.

Absolutely. Here's a few examples, though I could produce a hundred more: AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html . They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated.…

The 'Addressables' are a abstraction layer on TOP of AssetBundles. AssetBundles aren't deprecated. Honestly most of the criticisms you've gave are you not understanding how something works - like GetComponent. I do agree with you on 'null' though! And how Unity uses it. I think that decision came from them trying to make it more beginner friendly to deal with destroyed/removed objects when it first started - then the…

If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of my argument here, which is that in Unity it's often incredibly difficult to figure out which of 5 vaguely-similar-looking APIs you should be using, and it's a bad sign when the best source of info is a "coming soon!" message on an out-of-date tutorial not even linked from the documentation.

Perhaps you should explain how I've misunderstood GetComponent.

Re: Unity Software Inc S-1

#205

Post by formalsystem »

trynewideas wrote: post #175
akersten wrote: post #26

Earlier quoted context omitted.

> Any reasonably complex interface is essentially a game whether it's a music composition app, simulator, MMO or even a basic form. I've been out of the game development arena for a while, but I can't help but pause here. Are people really writing DAWs and big desktop app interfaces in Unity ? The last time I played with a game engine, I would have said UI was its weakest aspect. Clunky, slow controls, visually unapp…

> Are people really writing DAWs and big desktop app interfaces in Unity? Arguably the biggest non-game applications are in virtual cinematography, architectural visualization, non-game simulations, and immersive art installations. Most of those uses don't result in discrete "apps", though, they're just workflows within Unity designed to produce a specific type of output. One prominent example of a discrete pro app m…

Just wanted to say thank you for the excellent resources

Re: Unity Software Inc S-1

#206

Post by erlend_sh »

johnfn wrote: post #33

I'm quite bearish on Unity in the long run. Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering department. I've tried to use Unity off and on for years and every time I spend time learning it, I regret it. I'm a full-time React developer, and the difference in engineering culture and best engineering practices between Unity and React is massive. The Unity ex…

If you’re interested in Rust, you might like Bevy:

https://bevyengine.org/news/introducing-bevy/

A lot of people with experience in React are influencing the UI design.

Re: Unity Software Inc S-1

#207

Post by Vermeulen »

johnfn wrote: post #204
Vermeulen wrote: post #199

Earlier quoted context omitted.

The 'Addressables' are a abstraction layer on TOP of AssetBundles. AssetBundles aren't deprecated. Honestly most of the criticisms you've gave are you not understanding how something works - like GetComponent. I do agree with you on 'null' though! And how Unity uses it. I think that decision came from them trying to make it more beginner friendly to deal with destroyed/removed objects when it first started - then the…

If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of…

The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense

Re: Unity Software Inc S-1

#208

Post by specialist »

akersten wrote: post #26
formalsystem wrote: post #22

Out of any software tools I use frequently, Unity is the one that brings me the most joy. Any reasonably complex interface is essentially a game whether it's a music composition app, simulator, MMO or even a basic form. The basic abstractions of entities and components sometimes feel like they could apply to any software project. It's seamless to animate something, add physics, style in ways that would seem mind bogg…

> Any reasonably complex interface is essentially a game whether it's a music composition app, simulator, MMO or even a basic form. I've been out of the game development arena for a while, but I can't help but pause here. Are people really writing DAWs and big desktop app interfaces in Unity ? The last time I played with a game engine, I would have said UI was its weakest aspect. Clunky, slow controls, visually unapp…

"...I have a really hard time taking them seriously for UI-driven application development."

It's been a long time since I've done serious UI work, so am not aware of the latest grievances.

But it'd be great if stock UI frameworks were more like game (simulation) engines. Scene graphs, composition, event loops, command objects, etc.

Just like sufficiently complex C programs become buggy implementations of LISP, interesting UIs eventually recreate a poorly conceived and terribly implemented simulation engine.

Re: Unity Software Inc S-1

#209

Post by nottorp »

iaml wrote: post #89
adamnemecek wrote: post #45

Earlier quoted context omitted.

Unity is nothing like react.

Actually, AFAIK react event loop is based on game engines, so at least a bit of similarity should be there.

You mean react renders the UI at high FPS needlessly, regardless of any changes?

Re: Unity Software Inc S-1

#210

Post by johnfn »

Vermeulen wrote: post #207
johnfn wrote: post #204

Earlier quoted context omitted.

If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of…

The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense

I understand that GetComponent is a runtime lookup, and what I'm arguing is that Unity made the wrong choice. Runtime lookups lead to more bugs. They lead to slower code.

The best practices that have sprouted up around GetComponent say "Use GetComponent only in Awake(), and don't use AddComponent or RemoveComponent at all." But once you start following all these best practices, you've lost all the benefits of having GetComponent be dynamic in the first place. So just enforce it at a code level, and give me the benefits of static typechecking and compile time errors when I screw things up.

Post reply on HN