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

151–160 of 294 posts

Re: Unity Software Inc S-1

#151

Post by bcrosby95 »

johnfn wrote: post #72
synaesthesisx wrote: post #50

Earlier quoted context omitted.

After watching how many SaaS companies with "weak" engineering have soared to astronomical valuations, I would say I'm quite bullish on Unity (as a stock), irrespective of what developers think. At the end of the day, fantastic marketing is what gets CXO's and decision makers to buy-in. Look at MongoDB's performance since IPO in 2017 for perspective.

Honestly, that's a good point. As an engineer I can definitely get a little too focused on the engineering side of things. The MongoDB example is fascinating to me. I'd love to know why they're doing so well.

It's because generally, software developers don't have to deal with the downsides of MongoDB, ops people do. At a lot of companies it seems to be mostly developers picking technologies, so especially if they're inexperienced then they tend not to consider the other side of their decisions.

Re: Unity Software Inc S-1

#152

Post by serverholic »

Unity has completely destroyed my faith in their ability to deliver on anything other than marketing.

- It took them YEARS to deliver their new input system. Think about that. A company with Unity's resources took YEARS to develop a system that takes inputs from keyboards, mice, and gamepads and routes them to C# callbacks. YEARS.

- They completely abandoned their networking system (UNET) without a replacement system... This was YEARS ago and we STILL don't have a production-ready replacement.

- They wrote a new render pipeline called the Universal Render Pipeline (URP) and marketed it as a production-ready replacement for the old built-in renderer. However, the new pipeline isn't even close to feature-parity and the remaining features are still in development. How in the world is that a "production-ready replacement"???

Re: Unity Software Inc S-1

#153

Post by DonHopkins »

ImprobableTruth wrote: post #114
johnfn wrote: post #51

Earlier quoted context omitted.

It's really not as much of a stretch as you might think. Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws lou…

>GetComponent , possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.

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 called very frequently. For example, MonoBehaviour.Update is called every frame, as is LateUpdate, and FixedUpdate can even be called multiple times in a single frame. Rider treats all of these methods as performance-critical, and will highlight the method in the editor gutter.

[...]

>Once inside a performance-critical context, Rider enables a number of inspections:

>Avoid usage of GetComponent methods

>Avoid usage of Find methods

>Avoid usage of AddComponent

>Avoid string based method invocation (Invoke, SendMessage, etc.)

>Avoid Camera.main

>Avoid null comparisons for Unity objects

>The links above will take you to the documentation pages for each of the inspections, which provide more details of why the method calls are highlighted, and what you can do to avoid them. You can get to this documentation straight from Rider, like with many other inspections, with the “Why is Rider suggesting this?” Alt+Enter menu item.

Re: Unity Software Inc S-1

#154

Post by jayd16 »

serverholic wrote: post #152

Unity has completely destroyed my faith in their ability to deliver on anything other than marketing. - It took them YEARS to deliver their new input system. Think about that. A company with Unity's resources took YEARS to develop a system that takes inputs from keyboards, mice, and gamepads and routes them to C# callbacks. YEARS. - They completely abandoned their networking system (UNET) without a replacement system…

Its not that they can't build anything. URP is ok. It cuts out features that made it slower so its not going to ever hit feature parity. The problem is indeed that the marketing oversold it. They should have never suggested devs "move" to URP. For new games its alright.

Re: Unity Software Inc S-1

#155

Post by johnfn »

xex70 wrote: post #149
johnfn wrote: post #143

Earlier quoted context omitted.

A few quotes that I found particularly rough include: > Several of your points are misunderstandings, several are just wrong Like I said, I'd be happy to hear ways that I can improve. You saying that I am wrong but not providing specifics makes me feel bad without a way to improve my thinking. > “that person is going to have a hard time if they pursue professional game development,” You're passing judgement on my pro…

Perhaps your error is marrying yourself to your creative output and taking criticism thereof personally. Your essay is all over the place and plays a tune many folks in AAA have heard from many folks who got their start in Web development, and I was illustrating the broader context that, again, makes your intended audience develop that conclusion. Honestly, it reads like a projection of your expectations of software…

EDIT: Fair enough, I'll remove my lecturing.

I understand your point about not elucidating the why. Thing is, I'm not an AAA developer, so often times I don't know.

All I'd like to know is a bit more on why specific points my essay were wrong. Like, if you don't think the thing about clearing the Debug window is correct, I'd like to know why that is.

Re: Unity Software Inc S-1

#156

Post by jayd16 »

echelon wrote: post #65

It seems like Epic is going to trounce Unity when they go public. They've got a more powerful engine, megahit game, and distribution platform.

I would switch to UE but first class C# support is just so nice.

Re: Unity Software Inc S-1

#157

Post by swyx »

supernova87a wrote: post #128

It is clear from the financials that in the coming months/years, they will be pressured (or simply need to) cut back massively on R&D, marketing, etc. They have a gross profit margin of 78% in the last 2 years (revenue - direct operating costs), but then if you subtract R&D, sales + marketing, admin, it drops to -30% net profit. Not even knowing that much about them, you can see what's about to happen.

this is the story of almost every tech company at ipo, whats the big deal?

Re: Unity Software Inc S-1

#158

Post by jayd16 »

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…

The pain comes after you finish 80% of the game and start to work on the 2nd 80%.

Re: Unity Software Inc S-1

#159

Post by johnfn »

DonHopkins wrote: post #153
ImprobableTruth wrote: post #114

Earlier quoted context omitted.

>GetComponent , possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.

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.

Re: Unity Software Inc S-1

#160

Post by nikki93 »

johnfn wrote: post #118
ImprobableTruth wrote: post #114

Earlier quoted context omitted.

>GetComponent , possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.

That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense. If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the c…

Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.
Post reply on HN