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

221–230 of 294 posts

Re: Unity Software Inc S-1

#221

Post by zemo »

furyofantares wrote: post #193
virgil_disgr4ce wrote: post #125

Earlier quoted context omitted.

Have you done any game programming before? A heavy reliance on an interactive GUI is very common because there are many things for which you want visual interactivity, such as placing 3D objects in relation to each other. That kind of task is either difficult or impossible to do effectively purely in code.

I have. Placing objects in an editor is obviously essential, I agree. I just expect to find code at the bottom driving it, loading the map etc, and it doesn't seem like any example projects or learning documentation for Unity is geared that way. Basically I expect to follow code at the bottom until it loads some asset, which may create a bunch of objects, and register some scripts. Then I return to the code which can…

sure but like, you don't have that expectation of a browser, right? Like to write a web page, you don't create an instance of an HTML parser and call a parse method on some text, and then walk the tree and tell it to draw each element, right? Same deal. Just think of the scene as being a DOM in three dimensions.

Re: Unity Software Inc S-1

#222

Post by nikki93 »

johnfn wrote: post #212
danbolt wrote: post #200

Earlier quoted context omitted.

My biggest thought about game programming not necessarily having the same engineering culture as the web is due to the financial/business incentives for various engineering practices. I think React and a lot of other web tools are designed for programmers creating services that continually operate and generate revenue. Meanwhile, a video game's development is closer to a theatre production or a film. Traditionally, a…

That's a really interesting thought. It makes a lot of sense. Here's another one I've had that I'll throw on the pile: video games are generally highly demanding of the CPU. They'll use every cycle they can get their hands on. Web apps, on the other hand, have a ton of downtime and generally don't need to hit 60FPS (with rare exceptions). This means that they can spend their extra cycles on better abstraction layers,…

That point (keeping interactive rates) is basically one of the most important factors driving the architecture of game engines. I found this talk to be quite a good one regarding architecture for game engines (it's about the ECS in Overwatch): https://www.youtube.com/watch?v=W3aieHjyNvw

I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence checks / branching" is starting to feel out of fashion as of late, and the ECS approach is something folks have come around to.

I've been playing around with such an engine for a side project. Here's a quick video -- https://imgur.com/a/BcnWJha -- you can see what the in-game editor looks like + some of the physics of the game (the game and editor run both in web and natively). I think with the ECS-queries approach the code comes out to be quite ergonomic. For example, I've highlighted the logic that makes the player be obscured by objects in front of them here: https://gist.github.com/nikki93/8cc5d99e45ad74e7f1053dbef287... The game-specific code for the whole game is in that 'main.cc' file and comes out to about 500 lines. The game also includes custom inspector UIs for the 'Sprite' and 'Feet' components that are defined right in that file on line 288-314 and you can see them in the video.

Re: Unity Software Inc S-1

#223

Post by yokto »

DizzyDoo wrote: post #75
brundolf wrote: post #59

Earlier quoted context omitted.

What I've heard is that many of the problems are growing-pains; Unity has some really deep technical debt and they're (perhaps too hastily) ripping it out and updating things, which is causing angst for devs when a) their existing projects break, and b) in some cases the old system actually gets deprecated before the new one reaches parity. But it also sounds like all of the completely new stuff that doesn't involve…

I really, really wish it did. Here's just one concrete example: real-time point-light shadows in the Universal Render Pipeline. URP is the new 'default' way of rendering, the old renderer is being phased out, this is the new way of doing things - as you say; technical debt as they re-engineer. But how horrid has this process of eliminating technical debt been? You've got Unity proudly announcing that URP was 'product…

I've tried to customize their open source HDRP to add a shader feature and the whole pipeline was astonishingly messy and super convoluted. I'm really not optimistic on their chances of shipping a decent production ready pipeline before the end of 2021.

Re: Unity Software Inc S-1

#224

Post by danbolt »

nikki93 wrote: post #222
johnfn wrote: post #212

Earlier quoted context omitted.

That's a really interesting thought. It makes a lot of sense. Here's another one I've had that I'll throw on the pile: video games are generally highly demanding of the CPU. They'll use every cycle they can get their hands on. Web apps, on the other hand, have a ton of downtime and generally don't need to hit 60FPS (with rare exceptions). This means that they can spend their extra cycles on better abstraction layers,…

That point (keeping interactive rates) is basically one of the most important factors driving the architecture of game engines. I found this talk to be quite a good one regarding architecture for game engines (it's about the ECS in Overwatch): https://www.youtube.com/watch?v=W3aieHjyNvw I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence chec…

> I think with the ECS-queries approach the code comes out to be quite ergonomic.

I tend to agree, and I think it's something that doesn't get promoted enough as an advantage of ECS compared to cache hits and parallelism. When a programmer wants to add a new feature to a game, they can slot their system into the game's tick and avoid stepping on their peer's work as much. They won't need to edit `Entity.cs` or an inheritance tree, and it's much easier to reason about the order of updating game data per frame. It also makes code ownership and code reuse a bit easier to divide up too. I'd take an ECS system even with a performance penalty, as the organizational benefits really add up over time.

Re: Unity Software Inc S-1

#225

Post by DonHopkins »

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.

But Unity isn't an IDE, it's a game engine. Totally different things. Better for Unity to spend their time and energy on the game engine and editor, not making yet another half-assed IDE. Developing an entire IDE simply isn't in their wheelhouse. While it's a lot easier for somebody like Rider who already has a full blown C# IDE to support Unity.

Re: Unity Software Inc S-1

#226

Post by nikki93 »

danbolt wrote: post #224
nikki93 wrote: post #222

Earlier quoted context omitted.

That point (keeping interactive rates) is basically one of the most important factors driving the architecture of game engines. I found this talk to be quite a good one regarding architecture for game engines (it's about the ECS in Overwatch): https://www.youtube.com/watch?v=W3aieHjyNvw I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence chec…

> I think with the ECS-queries approach the code comes out to be quite ergonomic. I tend to agree, and I think it's something that doesn't get promoted enough as an advantage of ECS compared to cache hits and parallelism. When a programmer wants to add a new feature to a game, they can slot their system into the game's tick and avoid stepping on their peer's work as much. They won't need to edit `Entity.cs` or an inh…

Glad to see some agreement there. I'm interested in building an ECS-based approach for a UI system at some point. The Yoga layout engine (implements flexbox -- https://github.com/facebook/yoga/tree/master/yoga) seems to actually be pretty amenable to just incorporating as a `Layout` or `Flex` component, then you could have components for platform-specific renderings (eg. `iOSTextInput`, `AndroidTextInput`, `DOMTextInput` in wasm, ...) that could read from cross-platform common components (`TextInput`). A core aspect would also be a `Hierarchy` component that just has a parent entity id and a list of child entity ids (that it keeps in sync properly). Then bind things to JS and allow you to code it from React, while still being able to eg. run an animation thread for some specific animations that just queries and reads/writes the `Layout` and `AnimationSpec`s etc. Interesting talk re: data oriented design for a webby animation engine here actually: https://youtu.be/yy8jQgmhbAU?t=620

Re: Unity Software Inc S-1

#227

Post by zemo »

squeaky-clean wrote: post #129
furyofantares wrote: post #111

Earlier quoted context omitted.

I'm a highly experienced programmer and I can't get started with Unity. Maybe I'm just an old curmudgeon now. But I just want to see some code and drive from code. The workflow of starting from objects and scenes in a GUI and attaching scripts is totally foreign to me. And then most of the tutorials seem to be videos, which I have no patience for, with text I can skip around and tailor my learning to my personal need…

I originally had this mindset. Still kind of do. But the way of managing things through gameobjects, serializable components, and the scene hierarchy UI is very beneficial when you have non-programmers working on your game with you. It's annoying when you're a solo dev who wants to handle everything in code, but they're definitely trying to optimize the workflow for a small diverse team rather than for a programmer o…

> the way of managing things through gameobjects, serializable components, and the scene hierarchy UI is very beneficial when you have non-programmers working on your game with you.

honestly it's extremely useful even if you're an experienced programmer working alone. Being able to pause the simulation, move some objects around in space, and then resume the simulation is extremely powerful. Typing out the coordinates into code would: be ridiculously tedious -and- force you to commit to disk (by writing the files) the changes to something you really only need in memory. Being able to play with the state of the simulation by hand is extremely powerful.

Re: Unity Software Inc S-1

#228

Post by pandaman »

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…

From my experience of shipping a few AAA games: a universal game engine will always be suffering from trying to balance efficiency vs universality.

It's not a big deal to write an OOP engine where you just insert objects into a scene graph and each has a callback to draw itself, write a whole library of different classes for all kinds of purposes and ship it. The problem is that it's going to be much slower than a game written from scratch by a semi-competent programmer.

It's also not a very big deal to write an extremely efficient engine that will render, for example, streaming landscapes very fast and in great detail but won't render anything else nearly as well.

It's believed that neither of these would sell well even though id software has allegedly made much more money selling their specialized maze shooter engines than selling their maze shooter games. Though probably nowhere close to the money Unity/Epic makes.

Unity/Epic try to make an engine with OOP APIs in the front and optimized pipelines in the back. This is very hard and this is why they: a) don't have much competition an b) are not very good.

In my opinion, the only threat they both face is some yet unknown universal rendering technique appearing and making both obsolete. Till then, they will always have a customer base of studios who do not know/want to write their own game and not satisfied with naive OOP engines (and there used to be hundreds of those, even DirectX had one built in, called "D3D Retained Mode").

Re: Unity Software Inc S-1

#229

Post by jayd16 »

alexbanks wrote: post #133
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…

This is my first time being involved in a game. Is there a way to make dependency/package management not abysmal? I was legitimately shocked when I realized that if you wanted to install a .net standard 2.0 library, you had to manually walk the dependency tree of that library and download/copy every single DLL into your app. Did I miss something? (probably)

You can get nuget to work by having it put the packages under the Asset folder but you'll need to manually clean up targets you don't want. Unity has its own (a few actually =/) package system.

Re: Unity Software Inc S-1

#230

Post by [deleted] »

defen wrote: post #181
xex70 wrote: post #82

Earlier quoted context omitted.

Game development historically and consciously does not use Git so you’re fighting a losing battle. There’s good reason for that. Git remains not a great fit for managing large projects of assets despite extensions and work put in, so I’d be cognizant of your projection of Web-centric preferences on another vertical. That’s a recurring theme from the Web vertical (why don’t you do things our way) and I can tell you I’…

> The AAA I’m working on has about 75 KB of code Do you really mean 75KB of code or is that exaggeration for effect? That comes out to, I don't know, about 2,000 lines of code? I assume you're not including engine code in here, but still - 2k just seems orders of magnitude off from what I would expect a AAA game to have. Is most of the logic not implemented using code, but rather some other method?

[deleted]
Post reply on HN