[HN Gopher] Unity Software Inc S-1
___________________________________________________________________
Unity Software Inc S-1
Author : swyx
Score : 355 points
Date : 2020-08-24 15:26 UTC (7 hours ago)
(HTM) web link (www.sec.gov)
(TXT) w3m dump (www.sec.gov)
| supernova87a wrote:
| 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.
| swyx wrote:
| this is the story of almost every tech company at ipo, whats
| the big deal?
| flexie wrote:
| Very, very few Danish tech startups are listed. There are
| literally years in between, unless you count NASDAQ First North.
| I guess this is the way to do it :-)
| ingenieros wrote:
| Are they even still Danish though? They moved their HQ to San
| Francisco years ago and the filing clearly shows they are
| incorporated in Delaware.
| whoisjuan wrote:
| Is Unity Danish anymore? I mean, it got started in Copenhagen
| and its founder is Danish but that's the extent of it.
|
| I don't think people say Basecamp is a Danish company just
| because DHH is Danish.
|
| Not trying to poke holes at your statement. Just genuinely
| curious on what determines where a company is from. In my book,
| headquarters location is the baseline.
| ppaattrriicckk wrote:
| According to the Danish Companies House they haven't been
| very Danish since 2015. They've moved ownership 100% to
| Singapore (and from there, who knows).
|
| Still 300 FTEs in Denmark, though.
|
| https://datacvr.virk.dk/data/visenhed?enhedstype=virksomhed&.
| .. (the original company with David Helgason etc)
|
| https://datacvr.virk.dk/data/visenhed?enhedstype=virksomhed&.
| .. (IP company)
|
| https://datacvr.virk.dk/data/visenhed?enhedstype=person&id=4.
| .. (reference to the Singaporean company)
| tick_tock_tick wrote:
| How attached to Denmark are they still? I know they moved head
| quarters to SF a while ago but do any of the C levels still
| work/live in Denmark?
| caymanjim wrote:
| There's no mention of Apple here, but I suspect the timing of
| this is directly related to Apple threatening to cut off Epic's
| SDK access due to the fight over app purchase fees. This was
| almost certainly in the works already, but now they need to
| accelerate it.
| reaperhulk wrote:
| In my experience it is exceedingly difficult to meaningfully
| accelerate the timelines on publishing an S-1. There are too
| many lawyers, financial audits, investor roadshow schedules, et
| cetera. This is likely pure coincidence.
| JamesSwift wrote:
| Thats what I assumed as well, and anecdotally I personally
| researched if Unity was publicly traded after the Epic v. Apple
| news so I could buy some shares.
| VonGuard wrote:
| This should be a monster. We have no direct game development
| tools exposure on the stock market, unless you count Autodesk,
| but their tools are usable by other industries. That means it's
| gonna be shouldering a burden for an entire industry, and one
| that the stock market doesn't understand or appreciate. Potential
| for going either way, really.
|
| Development tools have traditionally been a poor investment long
| term, but that's not been the case since about 2010, especially
| since Atlassian went public.
|
| Unity is also gonna be a proxy for Unreal. Since these two
| competitors are not directly competing on the stock market, Unity
| should be a bit of a mirror for what the market thinks Unreal
| would be worth on its own.
| binky wrote:
| Excellent point with regard to dev tools not being a successful
| LT investment, with Oracle being an exception. I find Atalassia
| being sellers of dev "app", a standalone final product rather
| than a component in an overall solution that is effectively tax
| on every copy.
| JamesSwift wrote:
| I agree until you say Unity will proxy Unreal. I intentionally
| looked for investment options for Unity in order to possibly
| _short_ Unreal based on the recent Epic v. Apple news.
| qppo wrote:
| Think less as in development tools and more as in content
| tools, and how hard it is to pick a winner for content (but
| it's been obvious that content is exploding!). Games and AR/VR
| are just another form of content.
|
| I put some money into a strategy around the proverbial shovel
| salesmen for content creation last year, and I really wish I
| put in more and bought the dip harder.
| chrisseaton wrote:
| > That means it's gonna be shouldering a burden for an entire
| industry
|
| > Unity is also gonna be a proxy for Unreal
|
| Why do you think it has to do all these things? Why can't it
| just be a stock on its own?
| wastedhours wrote:
| There's always a sector influence on the valuation of stocks
| - if an analyst writes a report saying the gaming sector as a
| whole is going to grow 1000x in the next 10 years, you can
| bet people will be looking for stocks to ride that wave.
|
| If Unity is the only buyable stock in the sector, then
| they'll feel the impact.
| Trasmatta wrote:
| There are lots of existing stocks in the gaming sector
| though, so it would need to be more like "game engines are
| going to grow 1000x".
| MaximumMadness wrote:
| Not 100% sure I agree with analysis, for two reasons:
|
| 1. While the primary use case of Unity originally may have been
| game dev, the ubiquity of the software for other use cases
| (primarily VR/AR and other forms of online media) has been
| what's propelled it to this level.
|
| 2. Epic Games is much much more than the Unreal Engine. Highly
| recommend looking into Matthew Balls' Epic Primer [1], but
| Unreal is one corner of the Epic flywheel. Which is probably
| why they opted to raise a billion [2] in funding recently
| instead of IPO-ing post-Fortnite
|
| [1]https://www.matthewball.vc/all/epicgamesprimermaster [2]
| https://venturebeat.com/2020/08/06/epic-games-unveils-1-78-b...
| nshm wrote:
| Audio recording API in Unity is awful, you can only record a
| short clip on button press and thats it. No continuous listening,
| no sample rate configuration, no realtime. And processing thread
| changes from version to version. We had big trouble implementing
| speech recognition with Vosk in Unity.
| asou wrote:
| Ehh.
|
| I really hope Unity raises tons of money , and inspires some
| decent competition here.
|
| Unity is the worst game engine, aside from all others. UE4 is a
| convoluted mess. I've tired several times , but even getting it
| setup with the C++ build chain is a pain.
|
| Godot ( which epic funded recently ) isn't done yet.
|
| I'm going to stick with Unity until someone else can build an
| easy to use game engine. Ultimately Unity does tons of very
| difficult things, like I wouldn't want to write build systems for
| a half dozen platforms solo.
|
| The asset store is easily Unity's greatest advantage. With about
| 1000$ and a month you can make a full playable games. I also owe
| Unity my career. I work far from game design , but Unity taught
| me how to program.
|
| In my dream Valve releases Source 2 , it's just as easy to use as
| Unity and then game developers have a real choice.
|
| Or I get a spare 600k to build something in UE4. I'm a fairly
| experienced programer and I still can't make heads or tails of it
| furyofantares wrote:
| 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 needs. And
| then I have no idea how to predict if any given video or
| documentation or sample project is out of date. It's extremely
| frustrating and makes me feel dumb and old.
| virgil_disgr4ce wrote:
| 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.
| furyofantares wrote:
| 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 then get those objects if it wants.
| zemo wrote:
| 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.
| swimik wrote:
| I work on AAA games and this is exactly how I feel,
| especially about the online ecosystem around Unity, it's a
| big pile of garbage with maybe 1% of it being reasonable,
| best-practices documentation/advice.
| squeaky-clean wrote:
| 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 or group of only programmers.
|
| > And then I have no idea how to predict if any given video
| or documentation or sample project is out of date.
|
| 100% agree with this. I wish I could just buy a comprehensive
| book on an older version of Unity and stay on that as long as
| I can. But I can't really find much for more advanced Unity
| that doesn't exist as a video or GDC talk. (though an
| exception would be the catlikecoding tutorials)
| zemo wrote:
| > 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.
| zemo wrote:
| the old tutorials were better. Roll-a-Ball is still the best
| intro.
|
| honestly just think of the scene as being analogous to a
| browser DOM and learn which methods the game engine invokes
| on the objects and in which order. That's described here:
| https://docs.unity3d.com/Manual/ExecutionOrder.html
| [deleted]
| BiteCode_dev wrote:
| Isn't UE4 free for all use cases under a million dollar of
| revenue ?
| asou wrote:
| My joke was it takes a much larger team to get anything done
| in UE4 .
|
| I couldn't imagine solo dev on an Unreal Project .
| tiborsaas wrote:
| We tried it for a hackathon and after a day or so we got
| some stuff going. Of course it's a monster engine, but you
| can learn it as a side project, then after a month you can
| start building something. I don't see why a solo dev
| couldn't handle it.
| asou wrote:
| C++ is hard.
|
| The available learning resources for Unity are much
| better than they are for UE4. I want to add X to my game,
| I Google it and find ether an asset or open source
| project within minutes .
|
| For my current project I found a half dozen templates to
| start from. Everything in UDK was ether half done or
| abandoned.
|
| Of course both , or even rolling your own , are fine.
| tiborsaas wrote:
| True, we haven't touched C++, only the blueprint editor.
| It takes you far.
| goodcjw2 wrote:
| Unfortunately , "ease of use" and "one tool fits all" are a
| pair of conflicting features. Unity really does a fantastic job
| in this regard.
|
| Ultimately, well resourced team may choose to develop their own
| engine for the flexibility.
| jarsin wrote:
| I think unreal is easier to use than Unity because Unreal comes
| with batteries included. Unity you have to fill all the gaps
| with 3rd party asset store plugins and deal with all their
| weirdness etc.
|
| Unity's recent changes into everything is a package is a total
| mess and reminds me of how Rails became a mess after it tried
| to move everything out of core and into gems.
| asou wrote:
| I'd rather buy a 3rd party asset for the exact type of game I
| want to make.
|
| You still have to put in effort, but if you find the right
| assets it can really make things happen faster.
|
| The training material for Unity is above and beyond UE4. Any
| type of game you want to create already has a template on the
| Asset Store. UE's asset store is still packing .
| TootsMagoon wrote:
| ^^^This...Can't be understated what a mess Unity is right
| now. Meanwhile Epic with Unreal 5 is simplifying its pipeline
| and looks better and better.
| m0guz wrote:
| I remember one Unity developer was talking about how Package
| Manager will enable them to deliver smaller install/download
| size on top of easy to update core functionality. This was
| like 2-3 years ago. Unity 2017 for Win64 download size is
| around 500MB today, Unity 2020 with Package Manager is 1.7GB
| johnfn wrote:
| 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 experience is riddled with bugs, poorly-thought-out
| workflows, and half-finished or obsolete features. Simple tasks,
| more often than not, become an exercise in frustration. I've
| written a blog post about this[1], though it's incomplete (mostly
| because somewhere after writing the 2000th word I wondered why I
| was even using Unity at all) so I've never published it anywhere.
|
| I've honestly wondered a lot why Unity is successful at all, and
| the only answer I can really come to is that their direct
| competition - Unreal Engine, and a few other studio-made engines
| like CryEngine - are even worse. (Which leads to another
| question: why is it so hard to make a good game engine? But that
| would be another thousand words, so let's not stray too far from
| the point...) Godot is a glimmer on the horizon, but it looks
| like it still needs a few years to catch up.
|
| I also have a sneaking suspicion that Unity is successful because
| it is used by a lot of people as their introduction into
| programming, and they simply don't know that anything better is
| possible.
|
| Still, I suspect that most developers who use Unity will
| eventually reach the same conclusion and move on, and this seems
| to be confirmed by the google trends graph, which has been
| sloping steadily downwards over the last 5 years or so[2].
|
| [1]:
| https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...
|
| [2]:
| https://trends.google.com/trends/explore?date=all&geo=US&q=%...
| erlend_sh wrote:
| 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.
| johnfn wrote:
| Very excited about Bevy. Course, if Godot is young, then Bevy
| is practically a newborn. :-) Still, I resonate very strongly
| with a lot of things that the Bevy authors care about.
| [deleted]
| abj wrote:
| > I'm quite bearish on Unity in the long run
|
| Unity definitely seems like it has lost sight of what made the
| engine rise to prominence in 2010-2015.
|
| > I've honestly wondered a lot why Unity is successful at all
|
| Unity was the least painful way to develop your hobby game and
| have it run on multiple platforms for people (artists, new game
| devs) who reasonably didn't want to leave a GUI.
|
| > Why is it so hard to make a good game engine?
|
| Really great question. I wonder if it's because the list of
| useful features grows so fast.
|
| Imagine you make an engine from scratch. Great news! You have a
| 3D cube rendering successfully.
|
| Now you'd like to walk around the cube. You now need a system
| to handle input.
|
| Maybe you'd like to import geometry into the engine? You now
| need to write an import script.
|
| Maybe you'd like a pbr shader on the cube. You've written a pbr
| shader, but artists don't want to edit the source of the
| shader. So then there's an ever expanding slider/node system as
| shaders get more and more complex.
|
| Each of these small features quickly become giant wish lists
| filled with complexity.
|
| One way to handle this complexity is to have a great open
| source community like Godot, which tirelessly develops feature
| and feature. In the last 10 years, the expected features of an
| engine have grow so large that it's hard for newcomers to
| compete.
|
| In Unity it's not exceptionally easy to find the "correct" way
| of doing things because these engines are balls of mud, with
| system after system pilled on top.
|
| Which is why we've ended up with hard to use large engines and
| easy to use small engines.
| volkk wrote:
| 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 games so maybe things become extremely painful
| later on. But for learning, it's a really great tool
| nabla9 wrote:
| Is Unity still "Easy to build, impossible to maintain",
| always breaking code after you upgrade?
| ezconnect wrote:
| Yes, that's why you can have different versions of it on
| your development PC and run the version you are using.
| OneGuy123 wrote:
| Comparing a web library to game engine is a bit of a stretch.
|
| Unity is very nice to develop actually. It's a lot more simple
| than UE4 for example, but UE4 is much better suited for more
| complicated games, but then again, Subnautica is made in Unity,
| so Unity is very flexible.
|
| Neither is "bad" or "worse". Unity is obviously not perfect,
| but video game engines move and change all the time, that is
| the nature of the video game industry.
|
| Unity is mostly used for mobile video games, to which UE4 is
| not that much suited because it's more complicated and requires
| a better phone + the apk size will be larger in the end.
| davnicwil wrote:
| > Comparing a web library to game engine is a bit of a
| stretch
|
| I don't necessarily disagree, but an interesting thing to
| point out here is that a lot of the inspiration for React in
| fact came from game engines!
|
| The ideas around virtual dom diffs, figuring out the minimum
| necessary set of deltas, and only rendering those because
| that's the slow part, in particular.
| johnfn wrote:
| 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 loud errors and warnings if you do something
| that could even potentially lead to an error down the line.
| They deprecate and eventually remove broken features. And it
| almost goes without saying, but they finish the features
| they're working on, rather than leaving them in the codebase
| in a half-finished state.
|
| Unity does none of these things. Unity doesn't mark old
| features as deprecated: you could be using a deprecated or
| obsolete API for months without ever recognizing it because
| the only communication Unity gives you is a post on the Unity
| blog post from years ago. (This has happened to be multiple
| times.) Unity doesn't tell you when you're doing something
| wrong - you can still StartCoroutine with a string, even
| though you should be using a function reference. Unity
| absolutely does not try to lead your code towards the happy
| path of fewer bugs - 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, so if you forget and remove it later, your code will
| crash. React is very intentionally designed _not_ to have
| problems like this.
|
| I wrote like 4000 words on this topic, if you want more
| detail. Feel free to dig in if you'd like: https://www.notion
| .so/UnityIsFundamentallyBroken-e3b1474e7af...
| TremendousJudge wrote:
| I'm currently learning unity, and even for very, very basic
| stuff it's impossible to know what's the "correct" or
| "intended" way of using the engine
| ImprobableTruth wrote:
| >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.
| DonHopkins wrote:
| 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.
| johnfn wrote:
| 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.
| DonHopkins wrote:
| 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.
| johnfn wrote:
| The thing is, avoiding usage of certain functions - like
| Find, Invoke, SendMessage, etc - does not have to be done
| at the IDE level. In fact, it shouldn't be, and the fact
| that Rider has to do these things is kind of a kludge
| already. These methods should be marked obsolete - or at
| the very least, they should have docstrings saying not to
| use them. Observe how the docs for SendMessage don't even
| discourage its use, for example: https://docs.unity3d.com
| /ScriptReference/GameObject.SendMess...
| ezconnect wrote:
| Unity is a game engine first, the quality of their
| product will suffer if they have to teach all their user
| to program properly.
| johnfn wrote:
| I can't understand how this is the case. Unity is a game
| engine which keeps users mostly by instilling goodwill
| that it's a productive environment and is saving them
| time over using another engine or homebrewing one. It
| would therefore seem to be in its best interest to
| prevent them from creating bugs where possible.
| johnfn wrote:
| 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 components they
| expect to need at edit time instead. The dynamism that
| Unity currently affords rarely improves my game, but it
| does lead to a lot of bugs. If users really want to turn
| components on and off, they could have an enabled flag.
| DonHopkins wrote:
| Well so much for dynamic and procedural and data driven
| content, under your reign as Unity Czar. People use Unity
| for a lot more than Flappy Bird clones, you know.
|
| Components do have an enabled flag.
|
| https://docs.unity3d.com/ScriptReference/Behaviour-
| enabled.h...
| johnfn wrote:
| Well, I would certainly hope that as my reign as Unity
| Czar would include guidelines for storing procedural
| content somewhere other than in Components :)
|
| I mean, if you're adding a new component to a GameObject
| for every room in your dungeon or something, you're doing
| something very wrong. At least in my opinion!
| nikki93 wrote:
| 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.
| xex70 wrote:
| AAA here. Actually, it is a stretch, because you're
| expecting an entirely different discipline of software
| development to reflect the trends, knowledge, and
| assumptions of your discipline. We are a CryEngine shop but
| I've used Unity extensively for MVP pitches, spec work, and
| side projects. I also left the Web vertical to do this so I
| still have context from your side as well.
|
| I took the time to read what you've written. Just about
| every single point you made in that essay can be distilled
| to "Web developer with strong convictions about Web
| software engineering and expecting game development to look
| like familiar territory," with only a couple exceptions. I
| read that essay and I walk away with "that person is going
| to have a hard time if they pursue professional game
| development," not the intended conclusion you had about
| Unity's lackings. That's reflected in nearly every concern
| about Unity expressed in this thread because this is a Web
| forum.
|
| Unity has deficiencies we are all aware of in the industry,
| but none of them are in your essay. Several of your points
| are misunderstandings, several are just wrong, and all of
| them paint a picture which also gives a lot of AAA shops
| pause about hiring Web folks (and that I've had to deal
| with): there's a pretty strong strain among the Web
| industry of "if you don't do software like FAANG does,
| you're doing it wrong and your stuff is terrible."
| Meanwhile, the stuff you call bad/terrible/worse is
| generating billions in revenue and employing thousands.
| Seriously, Unreal is worse than Unity? Nearly stopped
| reading there.
|
| I'm reminded of a friend who does control development for
| factories and had someone come in straight from a Google
| internship who started trying to reimplement SCADA from
| first principles using Kubernetes. The Web is one way to do
| software engineering. There are others, and one of those
| others is reflected in the design of Unity.
| tikhonj wrote:
| Game programming _isn 't_--or at least _shouldn 't be_--
| so different from other fields that fundamental software
| engineering principles do not apply. It seems like
| discarding criticism just because it comes from outside
| the immediate industry is going to lead to an insular
| culture and get in the way of any real change or
| progress.
|
| Doubly so for an industry that still has high-profile,
| highly funded projects (Battlefield V, Anthem... etc)
| flounder because of technical debt and poor tooling. (And
| yes, these issues are all downstream of awful management
| for those particular projects, but that doesn't change
| the technical side of things!)
| tikhonj wrote:
| This goes in the other direction too: other fields can
| and should borrow ideas from game programming. At the end
| of the day the goals of different software projects are
| pretty comparable: we all want to produce quality code,
| minimize bugs and do it as quickly and productively as we
| can. The details and trade-offs aren't identical, to be
| sure, but at the end of the day different programming
| fields are far more alike than not.
| stevofolife wrote:
| Your first paragraph is like saying ship building, plane
| building or car building isn't or shouldn't be so
| different from one another. Wait what?
| johnfn wrote:
| I'll happily hear examples of things which are
| "misunderstandings" or "just wrong". As your post stands,
| it's nothing more than a long extended ad-hominem - it
| roughly boils down to "your post is wrong, but I'm not
| going to tell you why."
|
| I accept that Unity and Unreal Engine are doing fine
| financially and will probably continue to do so for a
| long time. That's no reason that they can also have
| issues.
| xex70 wrote:
| Quote one sentence where I attacked you personally. I was
| quite careful to speak about your essay and its
| conclusions from the perspective of the intended
| audience, and if you think I'm going to engage after
| having that called an ad hominem, you don't really
| understand the investment of time that would entail and
| why I'm strongly disincentivized.
| johnfn wrote:
| 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 professional abilities,
| which makes me feel pretty bad. It's also an ad hominem:
| you've stopped attacking my argument and you've started
| attacking my professional character.
|
| > "if you don't do software like FAANG does, you're doing
| it wrong and your stuff is terrible."
|
| Is it really necessary to include the thing about FAANG?
| I'm not even employed by FAANG. To me it feels like
| you're casting me out to be a FAANG elitist, which feels
| pretty alienating. It's also an ad hominem: you've
| stopped attacking my argument and you've started
| attacking me as a FAANG employee.
|
| > all of them paint a picture which also gives a lot of
| AAA shops pause about hiring Web folks
|
| Is the absolute "all of them" really necessary? That you
| dismissed every one of my points is pretty rough. Can you
| imagine if you wrote a 4000 word post and someone said
| "yeah I read it and every point you made gives me pause."
| and that's all they said, no further explanation? You'd
| probably be pretty frustrated, wondering what could
| possibly be wrong, but having no clue with which to even
| start understanding their different perspective.
|
| > I'm reminded of a friend who does control development
| for factories and had someone come in straight from a
| Google internship who started trying to reimplement SCADA
| from first principles using Kubernetes.
|
| You're comparing me to a friend that overengineers
| things. If you have specific things you think I'm
| overengineering, I'm happy to hear them, but a comparison
| like this without any concrete steps makes me feel bad
| without providing me a way to improve.
| xex70 wrote:
| 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 development, and that's
| what I'm trying to tell you.
|
| I was not accusing you of overengineering, I'm not
| accusing you of working for FAANG (I don't even know you,
| come on), I was making the point that people default to
| where they're comfortable, and if you're going to put
| yourself in a a position of authority and claim that
| Unity is bad (and Unreal is worse), you need to be
| comfortable in the environment and practices in which
| they are intended to be used. There is a minimum level of
| comprehension required to criticize an implement of
| another profession, otherwise someone proficient in COBOL
| would pick up a torque wrench and ask "why is this
| necessary? This design is just bad."
|
| You used subjective indictment terms ("bad," "worse") to
| describe positions that you don't have experience to
| develop. That's fine. Elevate your argument and
| understand the _why_ behind some of them. Example: we
| don't give two shits about deprecations because they're a
| distraction from a ship date and we ship vendored
| artifacts including the engine.
|
| You selectively quoted more than one thing I said to
| twist a personal attack from them, by the way, but that's
| your prerogative. It's also odd to do when you're crying
| ad hominem foul.
|
| Edit: I took the time to read your essay, respond to it
| candidly, and we are ending this conversation with you
| lecturing me on tone, politeness, and productivity. Even
| in the face of great hems and haws I doubly endeavored to
| remain polite. One would be forgiven for thinking you are
| not approachable with criticism.
| johnfn wrote:
| 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.
| SXX wrote:
| I'm too lazy to write 1000 word essay from my phone, but
| having a bit of experience in both webdev and c++ gamedev
| on custom engine I certainly can say one truth here.
|
| FAANG literally spend billions of dollars on developer
| tools alone, not even including browser runtime itself.
| There are thousands of engineers who work full time to
| make web and tools both fast and easy to use. There is
| also tons of open source developers competing to create
| best tools for other developers. And let's be honest
| tasks that average web developer has it's not rocket
| science.
|
| Gamedev is nothing like this: resources are ever limited,
| budgets are tights, and there is almost never ending
| crunch to release ASAP. Till recently every AAA company
| mostly used it's own tech and everything was not only
| proprietary, but always closed source so only papers were
| shared. Oh there also proprietary secret under-NDA
| targets called consoles where you cant just expect user
| to buy faster hw and more RAM. And skills you expected to
| have to work in AAA as C++ programmer can be more than in
| let's say SpaceX.
|
| So first of all you don't see how much better gamedev
| tools became in last decade. Other issue is that no one
| gonna hold your hand and force you into best practices
| because all games are mostly built of hacks and if you
| gonna enforce some strict rules it's mean developers wont
| be able to get those extra FPS, or better network latency
| or some absolutely unsupported feature that no one ever
| needed before.
| andybak wrote:
| > Unity doesn't mark old features as deprecated
|
| Are you sure? My IDE (Rider) shows gives me a tooltip for
| any methods that Unity has declared deprecated. There's
| also console warnings and big notices at the top of the
| docs.
|
| Package Manager also clearly marks certain packages as
| experimental or deprecated.
| johnfn wrote:
| 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/Scr
| iptReference/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. We now
| recommend using Addressables for your projects"
|
| EditorUtility.SetDirty(). Rider says "Marks target object
| as dirty. (Only suitable for non-scene objects)" and it's
| not marked obsolete or deprecated. Seems fine, right?
| Nope, it's been deprecated since 5.3. To their credit,
| the full Unity docs do reference this, but who is going
| to consult Unity docs for literally every Unity function
| they ever use, in their entire project? It should be
| right in the IDE. Better yet, the function shouldn't even
| exist! Unity 5.3 came out over 5 years ago!
| Vermeulen wrote:
| 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 they had to live
| with it
| johnfn wrote:
| 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.
| Vermeulen wrote:
| 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
| johnfn wrote:
| 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.
| andybak wrote:
| Hmmmm. Is it possible that a tutorial is deprecated
| without the actual feature itself being deprecated? i.e.
| there's no intent to get rid of AssetBundles in the near
| future but they don't want people who are just starting
| out to go down that path?
|
| I can see that's a gray area (you are kinda deprecating
| it by doing this) but the strict definition of
| deprecation probably involves a pledge to remove that
| feature in a certain timeframe.
|
| I'd be much happier to bitch about the stuff Unity has
| officially deprecated without having a good timetable for
| a replacement (Networking, Real-time GI) or done a
| terrible job of communicating the situation (Steam VR is
| "not officially supported" sounded pretty apocalyptic
| whereas it turned out to be not quite so bad - Valve had
| taken over responsibility for support and their solution
| was released to beta with a month of the doom and gloom
| corporate-speak announcement)
| johnfn wrote:
| Maybe we're talking about two different things? To me,
| once you add a new feature intended to replace an old
| one, the old feature should be deprecated and should
| eventually be removed. Even if you _can_ use
| AssetBundles, there 's no reason you ever _should_
| because they 've been superseded.
|
| I've always thought that that is deprecation, but I could
| see your argument that it's not.
|
| Fortunately I haven't had to deal with the officially
| deprecated features without a clear replacement. I can
| imagine that would be very frustrating.
| dmurray wrote:
| > Even if you can use AssetBundles, there's no reason you
| ever should because they've been superseded.
|
| You might have to use a superseded feature because you're
| maintaining old code. If Unity cares about backwards
| compatibility (admittedly, I'm not convinced they do),
| they need to keep supporting and documenting the old
| features even as they nudge you away from them.
| johnfn wrote:
| Sure, but if that's the case, you should really be
| pushing new developers away from using the old thing and
| towards the new thing. Mark it obsolete in the editor.
| Update your docstrings to point towards the new thing.
| Maybe even give me a warning in my console if it's really
| serious.
| spyke112 wrote:
| Why on earth would you compare Unity to React?
| johnfn wrote:
| Again, I'm talking about the engineering culture fostered by
| the two projects. I'm not literally comparing a game engine
| to a web rendering library.
| Pfhreak wrote:
| To provide more color to the parent comment, the scope of
| React vs the scope of Unity is several orders of magnitude
| different. (In fact, I've seen games that use React inside to
| manage their UI layers.)
| danbolt wrote:
| 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 video game has a point where development stops
| and is never resumed again. In the past this might have been
| lot check or "going gold"; today it might be a few post-release
| patches. There's a point where you don't keep working on your
| entertainment product and resources are invested elsewhere for
| more revenue. I think this means that the value of paying off
| structural technical debt might be always less than the revenue
| from your first month of sales. I think that changes the
| decision-making of management as their game's performance might
| be better off with a month of heroics and duct-tape rather than
| missing a holiday release date. I don't get the impression that
| profit incentives are the same with most typical web services.
|
| There are big exceptions to this, of course. Many more games
| are service-based these days. I think we're starting to see
| them adopt more stable practices like the rest of software
| engineering at both big [2] and small [1] scales.
|
| [1] https://www.youtube.com/watch?v=t9HRzE7_2Xc [2]
| https://www.gamesindustry.biz/articles/2017-08-04-bungies-13...
| johnfn wrote:
| 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, like React and Redux. Using React to render a bunch
| of game entities would make no sense because just running the
| reconciliation step can take 16ms, which is your entire
| rendering budget.
| nikki93 wrote:
| 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/8cc5d99e45ad74e7f1053
| dbef287... 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.
| danbolt wrote:
| > 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.
| nikki93 wrote:
| 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
| danbolt wrote:
| My general suggestion for programmers trying to understand
| something strange or seemingly odd in the games industry is
| to check for an economic/value incentive rather than a
| technical one.
|
| Unity has a lot of warts like your article indicates, but
| it gets a huge amount of bang/buck producing a not-big-
| budget multi-platform title with a multidisciplined team. I
| think that provides a lot of value for developers; so much
| that it outweighs the snags involved in Unity's technical
| shortcomings. Unity's roadmap is probably about expanding
| shipability for smaller developers and why Unreal is trying
| to commoditize that with Godot.
| whywhywhywhy wrote:
| >why is it so hard to make a good game engine?
|
| Game engines basically seem like magic if you compare them to
| other creative tools, being able to build and manipulate
| systems and tooling.
|
| Imagine if Adobe products could work like that.
| tanilama wrote:
| I don't think React vs Unity is the debate that we all cant
| wait for it to happen?
|
| After all, Web has DOM tree as its fundamental data structure
| to fiddle with, while Games are just a series of objects that
| can orient/interact with each other however they like.
|
| And obviously performance reason will affect abstractions as
| well, e.g. the Micro/Macro Kernel debate.
|
| To say Unity isn't good enough because React is good at
| abstracting Web development away doesn't seem to hold too much
| ground in terms of logic coherence
| adamnemecek wrote:
| Unity is nothing like react.
| iaml wrote:
| Actually, AFAIK react event loop is based on game engines, so
| at least a bit of similarity should be there.
| adamnemecek wrote:
| Not all event loops are the same.
| iaml wrote:
| Specifically, it looks like doom 3 engine
|
| https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196
| nottorp wrote:
| You mean react renders the UI at high FPS needlessly,
| regardless of any changes?
| johnfn wrote:
| Again, I'm talking about the engineering culture fostered by
| the two projects. I'm not literally comparing a game engine
| to a web rendering library.
| [deleted]
| adamnemecek wrote:
| Right however Unity is much more complex so it's not a fair
| comparison.
| johnfn wrote:
| Why not? It's easy to learn from the things that React
| does right and compare to see if Unity also does them
| right, or not.
|
| For example, React has a principle that components can
| freely be removed from the render path of their
| parents[1], since React (in the general case) does not
| allow parents to imperatively call methods on their
| children. Unity has no such prevention, so if you remove
| a child component you could be triggering a bunch of bugs
| when GetComponent<> calls fail to find the component you
| deleted.
|
| It seems clear to me that the way that React guides the
| user towards avoiding writing bugs is a good strategy.
|
| Why would we NOT compare these two? Why would we NOT say,
| "aha, it looks like React has a smart design that allows
| engineers to write code without unintentionally creating
| bugs, and so we should consider if something like that is
| possible, or perhaps think of a different way to solve
| this problem." Putting our heads in the sand and refusing
| to make comparisons between these two projects to see the
| similar issues that both projects run into means that
| Unity developers are doomed to repeat the same problems
| that React engineers have already solved.
|
| [1]: https://overreacted.io/what-are-the-react-team-
| principles/
| andybak wrote:
| Weirdly enough I got into Unity to give myself a break from the
| waking nightmare that front-end development seemed to be
| turning in to. I still dabble in back-end Django and a bit of
| framework-free front-end but I've been enjoying Unity/C# for
| non-commercial projects.
| formalsystem wrote:
| If you go through this list
| https://store.steampowered.com/curator/31285130-Unity-Engine...
|
| Most of it is a lot more impressive than projects completed
| with React.
|
| Unity has a high learning curve once you want to move away from
| tutorials. I believe React is the same, I kept trying to learn
| it but would get discouraged with the new tooling and
| eventually give up.
| johnfn wrote:
| I hear you that Unity has created some great projects, but
| that's kind of like saying that C is a better language than
| your favorite language because C was used to write Linux and
| your favorite language has never made any project that
| impressive.
| TillE wrote:
| I've been using Godot lately, and while it has many flaws (an
| over-reliance on strings as identifiers, for example), I think
| the fundamental design is sound and easy to work with:
| everything is a node in a scene tree.
|
| The engine code, while not up to modern C++ standards, can be
| pretty easily understood, modified, and then fully recompiled
| in just a few minutes. It's not suitable for a AAA 3D game, but
| it's the first engine I've found for 2D C++ development which
| actually helps me more than it gets in my way.
| synaesthesisx wrote:
| 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.
| hobofan wrote:
| > Look at MongoDB's performance since IPO in 2017 for
| perspective.
|
| I know that this opinion goes against the hivemind, but I
| wouldn't call them weak in engineering by a long shot. They
| obviously made some questionable/bad decisions regarding
| defaults (write acknowledgements, security) in order to have
| a lower barrier to entry, but apart from that I've had a
| pretty good experience with it as a stable product and good
| timeframes for bug-fixes.
|
| Unity is a stark contrast to that. The few years of using it
| sporadically for hobby projects has been a wild ride.
| Bugs/crashes seem to be everywhere, and when/if they are
| fixed just seem to be replaced with new ones. I don't know
| how full-time Unity developers can deal with that. Their
| speed of progress is also meh.
|
| Overall, if they were to stick to their (mobile) gaming
| niche, that probably wouldn't be a problem. However it seems
| like they are looking to mainly grow via other industries,
| and with that shoddy engineering and their development pace,
| I don't see them making a lot of headway there.
| chaostheory wrote:
| The important question is how does it compare to Unreal in
| terms of bugs, problems, and usability?
| hobofan wrote:
| Not only Unreal. I think the even bigger question is how
| does it compare to all the incumbent tools of the
| industries they are trying to replace.
| chaostheory wrote:
| Well, who are the other leaders in the industry? Is there
| any other major player besides Unity and Unreal? (I'm not
| overly familiar myself?) What's their respective market
| share?
|
| EDIT: Never mind, I found it.
|
| Unity and Unreal are the market leaders with
| approximately 15% & 25% market share respectively.
| Nothing else including Havok, Godot, Cryengine or Source
| even come close.
| johnfn wrote:
| 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.
| bcrosby95 wrote:
| 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.
| serverholic wrote:
| How can the people replying to you be so fucking stupid? My
| god, OP isn't comparing React and Unity at a code level. He's
| comparing the engineering culture surrounding the two pieces of
| software.
| johnfn wrote:
| Lol, thanks.
| TillE wrote:
| I've found nerds can be extremely literal about analogies
| when the two things being compared don't line up in every
| respect. Kinda misses the point of analogies.
| ingenieros wrote:
| They were the first commercial game engine to offer iOS support
| and this pretty much cemented their place in the market. Unreal
| used to cost upwards of 6 figures to license per game and this
| left indies nowhere left to go. Godot shows a lot of promise
| and has been steadily growing its userbase over the years, but
| its MIT license makes it really difficult to export to close
| source platforms and ultimately most devs want their games on
| consoles which are notoriously closed behind NDA's and other
| legalese.
| https://docs.godotengine.org/en/latest/tutorials/platform/co...
| dgellow wrote:
| I don't see how that's caused by their choice of license. I
| read your link, there is nothing related to their license
| either. MIT is permissive, as far as I know it is commonly
| used by 3rd party libraries for games, even on consoles.
| pandaman wrote:
| 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").
| barbecue_sauce wrote:
| Hopefully this will allow them to start a grant program in the
| same vein as Epic MegaGrants.
| echelon wrote:
| 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.
| jayd16 wrote:
| I would switch to UE but first class C# support is just so
| nice.
| swalsh wrote:
| I'm bull Epic too, but honestly, I don't care about the quality
| differences. The main thing Epic has going for them that Unity
| does not is it's diverse marketing channels. They are becoming
| huge in the cinematic, and broadcast markets, huge markets
| Unity doesn't even have a presence in.
| silicon2401 wrote:
| Can someone explain what this means to a finance noob? Does this
| mean it will be possible to purchase stock in Unity soon?
| KerrickStaley wrote:
| Yes, it means that they are going through the paperwork
| required to do an IPO. https://en.wikipedia.org/wiki/Form_S-1
| formalsystem wrote:
| How long does this process usually take?
| silicon2401 wrote:
| Thanks
| mijoharas wrote:
| Essentially yes.
| silicon2401 wrote:
| Thanks
| PopeDotNinja wrote:
| They are disclosing information that must be disclosed before
| conducting the initial public offering (e.g. making their stock
| available for purchase to you and others in the public). You
| can assume an IPO is coming up in the not too distant future,
| but there are reasons it might not happen, such as lower than
| expected desire for the stock they'd like to offer.
| silicon2401 wrote:
| ah good summary. thanks!
| bonestamp2 wrote:
| Pretty much. If a company wants to issue securities (such as
| stock) in the US, they need to submit one of these forms first.
| It's no guarantee that stock will be issued, but it's highly
| likely.
| silicon2401 wrote:
| Thank you
| scott31 wrote:
| How can I short this?
| DudeInBasement wrote:
| Usually, there is a 'no short' window after IPO. It is better
| to buy put options as it limits your downside risk. Unless you
| are a big dog (can actually effect the market). Then shorting
| is better because you can force the price in your favor.
| scott31 wrote:
| put options are fine too, do you know where I can buy them?
| hmate9 wrote:
| You can only get them after they eventually IPO.
| TomGullen wrote:
| I believe there is a wait time before options are
| available on new listings also
| qwert-e wrote:
| > do you know where I can buy them
|
| Good luck
| ffggvv wrote:
| as a counterpoint to all the complaints, i still think unity is
| by far the easiest game engine to pickup even for people who've
| never coded before. and there's so many resources out there to
| pick it up that there isn't really a strong competitor imo
| despite any potential misteps
| jshaqaw wrote:
| What's their plan to someday turn a profit?
| madrox wrote:
| Unity's done great things in its space. I worry about its long
| term prospects against the likes of Epic, who are going to be
| able to vertically integrate Unreal Engine with the epic games
| store and thus compete in ways Unity can't. I think a better
| business strategy would've been acquisition that could've given
| them that synergy, but I can also understand that, for the
| owners, the biggest cash out may not be what they're going for.
| ptrmthv1 wrote:
| Web developers are learning it's all pointer math on arrays.
|
| Which game engines happen to be heavily optimized for.
|
| SRE tools could be VR based. Omg lookit me pretending to manage a
| real server. Meanwhile its just sending something that conforms
| to an API spec.
|
| There's your singularity
| serverholic wrote:
| 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"???
| jayd16 wrote:
| 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.
| zlsa wrote:
| URP doesn't support casting dynamic shadows from point
| lights[0], something which many games use and should really
| be a feature in a production-ready game engine.
|
| [0]: https://forum.unity.com/threads/urp-point-light-
| shadows.8819...
| ordinaryradical wrote:
| Having followed this space for some time, Unity made huge strides
| at the beginning but has become notorious for punishing shiny
| features while leaving things broken or half-supported, which
| makes the developer's life hard if you happen to run into one of
| those bugs. Closed source means you're stuck writing ugly
| workarounds.
|
| My impression was that you can bootstrap some incredible stuff in
| Unity, but demanding kinds of games will push you into its uglier
| corners and leave you at the mercy of its updating schedule.
|
| This is very different from Unreal, or even Godot, which have
| their own trade offs. But it seems to me like there is enough of
| a "mid market" for all of them to coexist.
| oblio wrote:
| Hearthstone is built with Unity. I don't know if it's on
| Blizzard or on Unity (though, comparing things to other
| Blizzard games, I'd suspect Unity), but Hearthstone uses an
| awful lot of resources and is quite laggy on mobile, despite it
| presenting a pretty bare-bones 3D scene with barely any special
| effects.
| jayd16 wrote:
| Card games use a lot of high res art. They take a surprising
| amount of textures.
| oblio wrote:
| Have you played Hearthstone? It was released in 2013 and I
| wouldn't call their graphics "high end" by any stretch of
| the imagination. If racing games or FIFA run fluently on a
| Galaxy Tab S4, so should Hearthstone...
|
| Even their PC version is laggy, check out streamers
| restarting the game (!) before important and action packed
| battlegrounds turns.
| jayd16 wrote:
| Racing games and FIFA can reuse a lot of texture data.
| Same rock. Same uniform. Repeating crowd. That said, HS
| just runs on mobile. It's not optimized for it. It's
| obvious when you can only look at a chunk of your
| collection at a time instead of smoothly scrolling that
| the cards take up a lot of ram.
|
| Users also have a lot more control over what is shown on
| screen. For a FIFA game everything is loaded beforehand.
| In a card game that has to hide information, it has to
| load as the game progresses.
| hobofan wrote:
| That's really not an excuse. Doing some back of the
| envelope math shows that even the full collection of all
| Hearthstone cards would easily fit into RAM:
|
| ~0.25MB (size of a sample original artwork from[0]) *
| 3410 (number of playable cards in the game[1]) = ~850MB
|
| > For a FIFA game everything is loaded beforehand. In a
| card game that has to hide information, it has to load as
| the game progresses.
|
| During every single match of Hearthstone all the cards
| are also known beforehand (to the device), and they are a
| fraction of the full card collection.
|
| [0]: https://hearthstonejson.com/docs/images.html
|
| [1]: https://hearthstone.gamepedia.com/Card
| jayd16 wrote:
| Some things you might not be aware of:
|
| Hearthstone cards have several texture maps per card for
| the foil card effects. When textures are stored in ram
| they are not compressed (not as png or jpeg anyway). Its
| closer to a full 4 bytes per pixel. Textures also use
| mipmaps which take up an extra 33%. Not to mention the
| animations, effects and and the texture memory they
| bring. Its much more RAM than you think. Just look at the
| (fully compressed) install size of over 3GB. The menu
| textures do not take over 2GB.
|
| The game came out in 2014 when the latest iPhone had 1GB
| of RAM (less than 512MB usable for the whole app,
| essentially.) Its tuned to be under that cap, which
| forces a lot of disk reads instead of keeping things in
| RAM.
|
| >During every single match of Hearthstone all the cards
| are also known beforehand (to the device), and they are a
| fraction of the full card collection.
|
| This is actually false as some cards can spawn a random
| card from the full collection.
| hexaz wrote:
| The restarting is independent from the games performance.
| Battle times actually eat into the time you have after
| the battle to update your team, and at some point
| restarting the game is faster than watching the battle
| unfold.
| oblio wrote:
| Animations are choppy and slow.
| taken_username wrote:
| > Our common stock is currently not listed on any securities
| exchange. We have applied to have our common stock listed on the
| NYSE under the symbol "U".
|
| U like Unity, not Uber or Unreal.
| whywhywhywhy wrote:
| In 5 years Unity will completely dominate the creative space,
| even outside of games you're going to be finding this tech
| everywhere and there is no double in my mind you'll be seeing the
| unity logo at the end of summer blockbuster credit sequences.
| delfinom wrote:
| Unreal Engine is already very far ahead into the cinema space
| and already being used in numerous works being produced. Epic
| has been investing money into supporting toolchains and devices
| built to support Unreal Engine in cinema to boot. I simply
| don't see Unity catching up.
| synaesthesisx wrote:
| I'm bullish on Unity (especially with how it's positioned to take
| advantage of the AR/VR boom). I know Facebook tried to buy them
| at some point, and am glad that didn't pan out after watching
| what they've done with Oculus.
|
| As someone who has invested heavily in SaaS stocks, I know the
| current market is likely going to want to send this thing to
| space. There has arguably never been a better time to IPO.
| DonHopkins wrote:
| Oh great, with all that money maybe they can get symlinks to work
| in Windows.
| MrLeap wrote:
| I use Unity every day at work. This is a mixed bag for me. Unity
| gives google a run for their money when it comes to abandoning
| old features / letting them rot.
|
| The editor is kind of crashy, launch times get unwieldy fast.
| Sometimes there's subtle differences between build version and
| running in the editor, and solving the disparity is a death
| march.
|
| All that said, it's still one of my favorite environments to work
| in. I wonder if I have Stockholm syndrome.
|
| Hopefully all this public money will get them to make a saner
| serialization format for their scene files. Unity's relationship
| with version control is... tense.
| Pfhreak wrote:
| I use it a lot for hobby projects, and have used it and
| Lumberyard in a serious capacity.
|
| Whew boy does Unity absolutely put Lumberyard to shame. Unity,
| for me, is absolutely busted but also extremely approachable
| and generally good to use.
| speps wrote:
| > Hopefully all this public money will get them to make a saner
| serialization format for their scene files. Unity's
| relationship with version control is... tense.
|
| They had money before, it's not like they were running at a
| loss. The source control situation affects other engines (e.g
| UE4) just as much.
| nv-vn wrote:
| > it's not like they were running at a loss
|
| Well looking at their income statement, they were actually
| running at a loss haha
| brundolf wrote:
| I'm curious what issues it still has with version-control? I
| know that for a while the default asset format was binary
| instead of text, but I believe they made text the default a
| little while ago (I've used Unity in a hobby capacity over the
| years but never professionally)
| MrLeap wrote:
| Scene files are the biggest thing. They're merge conflict
| magnets. You breath aggressively and they'll "change". Our
| workflow tends to be based around prefabs, and a main scene
| we _rarely_ change. Despite never touching it, everyone on
| the team has to revert Main.scene before committing, pretty
| much every time.
|
| VFX Graphs are also pretty nuts. Cut one line and it changes
| 3000 lines of code. This isn't the biggest deal in the world,
| but it makes for weird diffs.
|
| There was a memory leak bug with the videoplayer component,
| and the only fix I found was to update to a newer-than-LTS
| version. That version likes to strip public rendertexture
| fields from the inspector every time you pull a scene down
| from git. Hopefully they fix that before they call it an LTS
| :)
| andybak wrote:
| Yeah. They managed to come up with an interesting innovation.
| Non-human readable YAML...
| franknine wrote:
| You also need to make sure .meta files are set to visible and
| get committed along with the assets, or the asset references
| will be completely messed up. Unity also makes visible .meta
| default now, and some would create a git hook to do a pre-
| commit check.
| brett-k wrote:
| Plastic SCM is pretty great at handling Unity projects of all
| shapes and sizes.
| andybak wrote:
| And they just bought the developer.
|
| I worry about all the good synergy I was getting from Unity
| stuff using Github as a default is going to dry up if there's
| a non-open, non-public VCS as the default. I love trawling
| Github for interesting Unity projects.
| xex70 wrote:
| 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've seen frustration with that firsthand.
|
| Perforce and systems like it are the competition here (pay
| attention to how many games announce changelists in their
| logs), and AAA studios are quite comfortable with what they
| have.
|
| If your problem with Unity is how it does source control it
| speaks more to your unfamiliarity with industry practice
| than it does a deficiency in Unity. They added Git ability
| because enough people complained about it, but as this
| thread points out, it took gymnastics to implement because
| it's simply not how that market operates -- web folks
| operate on a pile of text files and games don't look
| anything like that. I'm not just talking about graphics,
| either. The AAA I'm working on has about 75 KB of code and
| 46 GB of binaries and a few hundred actively committing, so
| Git is very comfortably a nonstarter.
| andybak wrote:
| > so you're fighting a losing battle
|
| That's an odd way of putting it when I was stating "I've
| always found tons of great Unity stuff on Github - and
| I'm worried that might change".
|
| The rest of your answer makes sense in itself - it just
| seemed to be responding to somebody else.
|
| I basically learnt by downloading Unity stuff off Github
| and playing with it and I follow a lot of great accounts
| which I check regularly.
| xex70 wrote:
| You hinted you're worried about the perceived and
| hypothetical lack of synergy of GitHub and Unity
| reflecting on your perception of the latter, and you
| spoke about licensing concerns to reinforce that point.
| You also expanded your position in nearby comments. I'm
| advising you that the entire concern and approach you're
| taking to source management, and your interpretation of
| the same as well as your beliefs about free software,
| reflects where you come from more than where you're
| going, and you should loosely hold whatever conviction
| brought you there if you're serious about pursuing the
| industry.
|
| I was responding to you. The game industry is
| fundamentally different from other industries, and
| approaching it with questions like "why not Git?" or "why
| no type safety?" or "what about GPL?" marks you as not
| really understanding the industry, its product, or its
| motivations. I realize there's a huge clutch of cash and
| free time that lets the average Web dev schedule meetings
| about and argue type safety and microservices and so on
| among their peers, but game development is an industry
| driven by a whip and is closer to Hollywood than San
| Jose. We look to indie to innovate and put in our 80
| wishing we had the time.
| andybak wrote:
| I'm simply interested in continuing to find useful and
| inspring stuff on Github or some similar open, shared
| resource. I can see how it might be less than ideal for
| large projects and the purchase of Plastic SCM might be a
| great benefit to studio workflows - but I hope all the
| strange, quirky, experimental stuff on Github that's a
| real boon to learning doesn't disappear in it's wake
| andybak wrote:
| > approaching it with questions like "why not Git?" or
| "why no type safety?" or "what about GPL?" marks you as
| not really understanding the industry,
|
| Sorry - I'm trying to remember the contexts that I've
| said stuff like that in. You must have delved quite far
| back in my post history. Posting them as if they are
| direct quotes without context is a little unfair.
|
| (Plus - I've got no interest in joining the mainstream
| games industry)
| defen wrote:
| > 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]
| setzer22 wrote:
| Genuinely curious. You insist a VCS is not how the
| industry operates. But then how _do_ those AAA devs
| manage synchronizing changes across a team of several
| hundreds of people? I imagine there must be some
| equivalent to VCS that better fits the gamedev indurstry.
| Or are people just throwing flash drives around the
| office?
| maccard wrote:
| Perforce. You have an always online server, and binary
| files can only be checked out by one person at a time
| (enforced by the server). Its big, it's clunky, the UI
| (p4v) sucks more than you could possibly imagine, but it
| scales.
| weaksauce wrote:
| yeah the version control aspect of unity made me cool off on it
| because version control is so very important.
| hesdeadjim wrote:
| Stockholm Syndrome is on my mind frequently with this engine.
| I'm hoping their promise of 2021 being a stability and
| productivity focus will come true.
|
| It's hugely frustrating to see how poorly planned their roadmap
| is. I have access to core support and their private slack, and
| you'd be surprised how short notice some of their decisions
| have been.
| reitzensteinm wrote:
| I would not be surprised.
| formalsystem wrote:
| I started using Unity actively about 2 years ago so haven't
| experienced the abandoning old features part, which features
| are you thinking of here?
|
| 100% agree on the launch times, it gets nuts even for smaller
| games - I'm not sure if they're working on this.
|
| Have you tried Unity Collaborate or Git LFS for version
| control? What other improvements would you like to see?
|
| The Stockholm syndrome comment made me lol, It's just very
| satisfying to make games with Unity that I'm willing to
| tolerate/ignore the issues with it.
| zemo wrote:
| try using networking in Unity sometime. UNet has been
| deprecated for years and the replacement is still officially
| experimental. The networking situation is pretty bad in Unity
| at the moment.
| MrLeap wrote:
| Their post processing stack has changed like 5 times in the
| last 2 years, breaking old methods of post processing.
| Hopefully now that SRP is getting more mature that particular
| thing will slow down.
|
| The videoplayer component broke for a few months. Builtins
| got pealed out into the package manager and it trivially
| broke some code. I don't know how long shuriken is for this
| world (good riddance imo, vfx graph is so much better.)
|
| Shadergraph adds and loses nodes every version.
|
| If you start a project in the same version you finish it in,
| it's not too bad. If you upgrade because you want to use a
| new-shiny, the surgery becomes more apparent.
| Tossrock wrote:
| Not to mention IMGUI => UGUI => UIElements/UIToolkit,
| InputManager => Actions, Animation => Timeline,
| GameObject/Component => ECS/DOTS, ParticleSystem =>
| VFXGraph, Legacy renderer => Scriptable Render pipeline,
| etc etc
|
| edit: whoops didn't see you'd already mentioned VFX graph
| chaostheory wrote:
| How does it compare to Unreal in terms of ease of use and
| getting the job done? (I'm thinking Unreal is better
| performance wise; not very interested in that.)
| risyachka wrote:
| In these terms it outperforms Unreal. Ease of use and speed
| of development is main points why I have been using Unity for
| years.
| boogies wrote:
| What about Godot? The anecdotal evidence I've heard has
| seemed to say that Godot is the best for rapid prototyping
| because of GDScript, and maybe easier animation.
| risyachka wrote:
| Unity indeed abandons lots of its features, another part is
| bad.
|
| Fortunately there are 3rd party solutions for many of them and
| you can easily create your own for features you need that will
| serve you for years to come.
|
| Also I have been using Unity with self hosted Gitlab and never
| had any problems, though you need to get used to it for sure.
| mlacks wrote:
| > Industries Beyond Gaming: In industries beyond gaming, we
| estimate the market opportunity for our Create Solutions and
| Operate Solutions to be approximately $17 billion today, based on
| the number of software developers, architects and designers our
| solutions could potentially serve.
|
| There is a graphic I stumbled upon years ago - I haven't been
| able to find it recently - that described Facebook's gameplan -
| 10-20 years out. It basically described how the focus of the
| platform would evolve with how effectively users would be able to
| share their lives with their network, in progression with
| technology, or - more specifically - the price of bandwidth. Let
| me explain:
|
| FB early years was very text-centric. I recall not "getting it"
| because it was effectively a tricked-out twitter. Kinda like
| Asana vs Clickup today - more features doesn't directly translate
| to "better". I of course didn't factor in the "network effect". I
| digress. Early years was text-centric.
|
| When internet speeds picked up (without much of an increase in
| price to the end user), photos became more of a focus. The
| Instagram acquisition happened around this timeframe
|
| At the time I found this graphic, The same price/data speed
| phenomenon was in effect and FB was transitioning to video as its
| core sharing focus. Facebook acquires Occulus, which leads into
| the last part of the graphic -
|
| VR. I remember MZ's Mark Zuckerberg's virtual Puerto Rico jaunt.
| New tech is often akward, but knowing Facebook a player in an
| industry typically "beyond gaming" is in line to blur that line,
| is one good example of the viability of Unity as a real revenue
| producing entity.
|
| This is getting a little long winded, but I think this next part
| drives the point home.
|
| I'm a real estate agent, and I used to work at a brokerage called
| Exp (NASDAQ: EXPI). Their pitch (to agents) is that they are a
| "cloud-based brokerage". While not required - there is a Club
| Penguin-esque "world" you log into, make an avatar, walk around
| and an attend meetings in auditoriums. Its very cheesy, but as
| mentioned above, all new tech is cheesy. Check out Exp stock
| performance this year. Unity is in a prime position to work with
| companies in "non-gaming industries" looking to keep current and
| move with the pace of tech
| formalsystem wrote:
| 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 boggling in other environments I've worked in like Python or
| Javascript.
|
| You can learn so much going over basic Unity tutorials on Youtube
| and disassembling Unity games on Steam.
|
| The asset store has many people aggressively experimenting with
| better user experiences for doing certain tasks whether its
| character skinning or node based programming, many of the best
| assets end up added to Unity by default.
|
| Unity is not mostly used for mobile games, some insanely complex
| games are made in Unity. You can check out this list on Steam
| https://store.steampowered.com/curator/31285130-Unity-Engine...
|
| Unity ML agents is the single most exciting ML project out today
| which helps you create the most complex Reinforcement Learning
| environments you can dream of.
|
| Unity ate the indie game market but I think they will also eat
| Robotic simulations, Animation, interior design, VR, Web apps and
| Desktop apps.
|
| Can't wait to buy shares.
| akersten wrote:
| > 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
| unappealing, and certainly lacking in accessibility. Without
| researching more, I would feel pretty confident placing a bet
| that if I pointed JAWS at a Unity Window, it would say "Game
| Window" and that's about it. Windows accessibility hooks and
| tab navigation certainly didn't work out of the box, and I
| would say that is bare minimum for a UI toolkit.
|
| So while it's valid that Unity is a beast and game engines will
| eat the world for games, I have a really hard time taking them
| seriously for UI-driven application development.
| sgustard wrote:
| Unity's homepage lists four industries they target and Games
| is only one of them. Seems clear they also want to sell into
| Manufacturing, Construction, Film, etc.
| 1f60c wrote:
| I think GP meant that a lot of _patterns_ that are common in
| game dev could also be applied to other kinds of software.
| akersten wrote:
| It doesn't read that way to me, since it ends with "can't
| wait to buy shares" and is sandwiched between other
| examples of how Unity brings them joy - implying Unity is
| the platform on which all of these things will be built. I
| guess OP can clarify if they desire, and my comment still
| stands regarding Unity's UI toolkit.
| specialist wrote:
| _"...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.
| Gibbon1 wrote:
| Potential advantage to Unity is it was developed from the
| ground up to do all that. Unlike the browser.
| amirhirsch wrote:
| For quickly making a cross-platform mobile apps, it is
| definitely going to emerge as the new first choice. I've been
| burned so much by cross-platform issues trying to do anything
| complicated or graphical with
| phonegap/cordova/electron/react...
| Tossrock wrote:
| I've made a node-editor based UI heavy application for real-
| time texture synthesis in Unity[0], for which it is quite
| good. Although I agree that it doesn't integrate platform
| native UI patterns well.
|
| [0]: https://www.youtube.com/watch?v=9xU4Dtp7cV8
| formalsystem wrote:
| This is an example of someone who has built a robotic
| simulator in Unity
| https://www.youtube.com/watch?v=AvZgbB71yb8&feature=youtu.be
| risyachka wrote:
| For MVP you can't beat speed of development with Unity. You
| can create a complex UI with full logic in a matter of days.
| trynewideas wrote:
| > 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 made from Unity,
| though, is Digital Monarch Media's filmmaking toolsuite,
| which is built on Unity.[1] But it fills some unusual
| hardware and interface needs that Unity is built, or has
| plugins, to provide (touchscreen interfaces, motion tracking,
| color grading).
|
| That said, I see non-game apps in the vein of content
| creation or productivity pop up more frequently now in Godot
| development than Unity. There are some proof-of-concepts,
| like the Godello[2] Trello clone that was posted here a while
| back, but more useful examples are Pixelorama[3], an open-
| source pixel-art editor built with Godot, and Heavypaint[4],
| a painting/sketching app.
|
| [1] https://www.vfxvoice.com/instant-feedback-expozure-
| expands-i...
|
| [2] https://github.com/alfredbaudisch/Godello
|
| [3] https://orama-interactive.itch.io/pixelorama
|
| [4] http://www.heavypoly.com/heavypaint
| formalsystem wrote:
| Just wanted to say thank you for the excellent resources
| panopticon wrote:
| According to Bloomberg[0], non-gaming clients make up 10% of
| Unity's business.
|
| > _[Unity] helps Volkswagen AG train employees, was used by
| filmmakers to shoot the recent "Lion King" movie and by the
| Hong Kong International Airport to simulate changes in
| passenger volume._
|
| I don't know enough about these domains to say whether it's a
| good (or bad) idea, but I've also heard of Unity being used
| for other kinds of modeling and simulations too (climatology,
| traffic, etc).
|
| [0]:
| https://www.bloomberg.com/news/articles/2020-05-07/unity-
| tec...
| boarnoah wrote:
| > Lion king
|
| I'm fairly sure this is incorrect.
|
| Unsure about Lion King specifically but all of the other
| recent Jon Favreau titles (The Mandalorian, The Jungle
| Book) have done virtual production with Unreal Engine.
| panopticon wrote:
| From Engadget[0]:
|
| > _The workflow of The Lion King was vastly different to
| The Jungle Book. MPC worked on 'master scenes' in London
| with industry-standard tools such as Maya. It then
| developed an "asset management system" that could
| translate the scene into something that was compatible
| with Unity, a popular game engine._
|
| Also, this YouTube video[1] goes over the process in more
| detail.
|
| [0]: https://www.engadget.com/2019-07-29-lion-king-
| remake-vfx-mpc...
|
| [1]: https://www.youtube.com/watch?v=KCnayCnM6Zk
| boogies wrote:
| > Are people really writing DAWs and big desktop app
| interfaces in Unity?
|
| I'd love to know if Unity is made in Unity. The Godot game
| engine's development environment is made in Godot (which is
| why it was able to be run in web browsers using WebAssembly
| https://news.ycombinator.com/item?id=23354286).
| Tossrock wrote:
| Unity is not really made in Unity - the core engine is in
| C++ that is separate from the userland C# scripts. However,
| it uses the same UI library that's available to users
| (IMGUI, and being upgraded to UIToolkit), which makes it
| easy to extend.
| altharaz wrote:
| Unity has also a lot of potential in the Cybersecurity
| industry, for people that wants to train themselves on
| Industrial Systems.
|
| The only thing that makes industrial Cybersecurity really hard
| for students is the industrial systems laboratory requirements.
|
| With Unity, some people are trying to build completely virtual
| pentest labs on industrial systems, such as GRFICS
| (https://github.com/Fortiphyd/GRFICSv2).
| alexbanks wrote:
| 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)
| jayd16 wrote:
| 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.
| debacle wrote:
| My only real complaint with Unity is that they are kind of
| mired in GameObject and ECS/DOTS are not quite first class yet,
| despite being universally better (with only slightly more
| code).
| foobarian wrote:
| Press one button and presto: you have a game running on all the
| environments one could possibly want today. This alone is worth
| putting up with a lot of deficiencies in the UI, or the API, or
| whatever.
|
| I remember this boat in early 2000s, when engines were less
| capable, and I was younger and more arrogant. The thought of
| using some crappy engine with last gen graphics would make me
| laugh. Of course I was going to make my own thing in C hand-
| optimized to squeeze every last triangle from the hardware.
| Good luck if you didn't have that exact hardware configuration
| :)
| jfim wrote:
| To be fair, back then, engines were far more limited and
| there were much fewer platforms to support (only supporting
| D3D back then was viable).
|
| Plus it's a lot of fun to write your own engine. Sure,
| texture loading or managing sound buffers won't make your
| game better than others, but it's definitely fun to write
| that code.
| jayd16 wrote:
| The pain comes after you finish 80% of the game and start to
| work on the 2nd 80%.
| linuxftw wrote:
| This was the type of information I was looking for in the
| comments. I don't know if what you're saying is accurate, but
| it speaks to the entire reason for a company to go public:
| Raise capital to expand the business.
|
| Looking into the S1 highlights a Volvo customer info graphic.
| Unity seems to be proficiently expanding into other segments.
| They can really solidify their position in these other markets
| by having a vast breadth of talent available that knows their
| tooling across various industries. Unity experience will be
| valued as a skill set, not just game experience. That will
| drive further adoption of the platform.
|
| This seems to comport with what you're saying. I think there's
| real opportunity here.
| gentleman11 wrote:
| 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?
| movedx wrote:
| > I was a fan of unity until they retroactively changed their
| asset store license.
|
| Pretty certain you can't do that.
| vmception wrote:
| reading most of these comments, its clear and odd that people
| view "going public" or filing an S-1 as a coveted position,
| something that someone "deserves" or "doesn't deserve"
|
| and to me that is a very odd side effect of companies not going
| public often
| nv-vn wrote:
| I think it has to do with the fact that HN has many users who
| are employed at startups. When you get paid in what is
| essentially monopoly money, you're going to be envious of
| startups which are able to turn that into cash. It seems to me
| like it's just the side effect of people having 90% of their
| net worth tied into a private company's equity and wanting the
| golden ticket to actually redeem it.
| vmception wrote:
| Tragic, but not really, either way I would like to see more
| nuanced discussions just about its under or overpricing, or
| something more overt like its "pumpability".
|
| Or maybe a discussion about how to get price discovery at
| lower valuations instead of just dumping on everyone's 401ks
| at high valuations.
| BoysenberryPi wrote:
| Unity filing for an IPO is very interesting. I use both Unity and
| Tableau and they have always seemed very similar to me in terms
| of marketing. They have massive communities and excel at getting
| people up to speed and making you feel powerful. However, once
| you get passed the "beginner-intermediate" phase you realize this
| isn't really all its cracked up to be but at that point you
| invested time into learning them and they technically get the job
| done so you stick with it.
| minimaxir wrote:
| Interesting given the current issues with their primary
| competitor Unreal Engine/Epic, although the timing of this IPO is
| 100% coincidental.
| adamnemecek wrote:
| I wish them the best, they have transformed the landscape of
| indie game development really drastically and forced others
| (Unreal) to follow suit.
| jkinudsjknds wrote:
| I'm surprised by this perspective. I see Unreal as leading the
| charge for indies and Unity struggling to follow suit.
|
| * Vastly better free content to throw in your games
|
| * Source available engine
|
| * No fees on the first million dollars of gross revenue
|
| * Clear communication on roadmap for engine development and
| what's going to stay vs. change
| DizzyDoo wrote:
| Like some others who are commenting, I use Unity for my job every
| day, and it's not been a great experience these last few years,
| each 'part' (graphics pipelines, documentation, Editor and
| tooling, and so on) has been steadily deteriorating over the
| versions. This article from Garry (from Garry's Mod, Rust and so
| on) from earlier in the year is still all accurate:
| https://garry.tv/unity-2020
|
| Sadly, I wonder how much the last few years of very obviously
| aiming at Going Public has led the company and Unity as a
| software to this state. When the forums are full of "what is
| going on with Unity" threads and the company blog is full of
| "we've bought this cloud company" and "we're investing in AR for
| automative engineering", something isn't matching up.
| brundolf wrote:
| 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 scorched-
| earth deprecation is generally well-received (and in some
| cases, a long time coming).
|
| Does that line up with your experience?
| DizzyDoo wrote:
| 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 'production ready' in
| February 2019, but you still can't have a point-light cast
| real-time shadows. Currently that (let's face it, really
| basic) feature is planned for Unity 2020.2, which is still in
| alpha, but even if you download the alpha you can't access
| that feature yet, _and_ they 've announced they're not going
| to backport it, so bad luck if you're using 2019 or even
| 2020.1 for your game.
|
| It's actually making me a bit sad to go into detail on what
| watching the URP fiasco, so I'll spare any other examples
| involving post-processing stacks, or 'camera stacking', or
| Ambient Occlusion, or...
| brundolf wrote:
| That's pretty bad, but I'd still file that under "too-
| hastily deprecating things before the new version is at
| parity". Not that it isn't a huge issue, but could it be a
| temporary issue? Is the newer one, in theory, on a good
| track for the long-term?
| DizzyDoo wrote:
| I mean, I've been watching this unfold over multiple
| years, and I fully expect this to continue over the next
| two at the very least, and it applies across every slice
| of the engine that I'm aware of, and some that I'm not
| intimately familiar with (I hear second-hand that
| networking is somehow in a worse state?)
|
| I guess everyone has different tolerances for what may
| technically be a 'temporary issue.' Yes, I have no doubt
| that all this engineering will lead to a better, more
| stable Unity, but for _right now_ I actually have to
| somehow write real software and ship something to paying
| customers.
| squeaky-clean wrote:
| The newer one (URP) is already in its second rewrite
| after ditching the initial version (LWRP). They also
| completely split the post-processing stack into two
| incompatible stacks depending on whether you're using URP
| or HDRP, then backtracked and are attempting to merge
| them into a single stack again.
|
| So while maybe they'll get it all fixed soon, based on
| their track record I'm pretty cynical and bet it's more
| likely in 2021 or 2022 they'll announce yet another
| overhaul of the rendering stack(s), probably unifying
| them back into one stack or something.
| DizzyDoo wrote:
| Absolutely. One more additional thing: the latest back-
| track has been the URP-is-not-a-standalone-package
| anymore, URP package versions going forward are going to
| be tied to a specific Editor version. I imagine this is
| going to make the ability to backport features and bug
| fixes incredibly difficult because the dependencies are
| going to be so tightly enmeshed.
| Vermeulen wrote:
| It's not - they didn't deprecate the 'built in' render
| pipeline, and said they don't plan to until the new one
| has feature parity. They have odd marketing for their new
| features - where they want developers to use them so they
| call them production ready - but they do that so they can
| get feedback and continue to fix them
| yokto wrote:
| 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.
| kaesar14 wrote:
| "We have experienced rapid growth. Our revenue grew from $380.8
| million to $541.8 million for the years ended December 31, 2018
| and 2019, respectively, representing year-over-year growth of
| 42%, and from $252.8 million to $351.3 million for the six months
| ended June 30, 2019 and 2020, respectively, representing period-
| over-period growth of 39%. We generated net losses for the years
| ended December 31, 2018 and 2019, and six months ended June 30,
| 2019 and 2020, of $131.6 million, $163.2 million, $67.1 million
| and $54.1 million, respectively, which included $20.9 million,
| $44.5 million, $14.8 million and $21.7 million, respectively, of
| stock-based compensation expense. We reduced our net cash used in
| operating activities from $81.1 million to $67.9 million for the
| years ended December 31, 2018 and 2019, respectively, and from
| $19.8 million to $15.4 million for the six months ended June 30,
| 2019 and 2020, respectively."
|
| Promising financials!
| nabla9 wrote:
| Rapid growth software company with most of the sales coming
| product should have price/sales to be abowe 10-20 at least.
|
| Should we expect $5 -10 billion market cap?
| tempsy wrote:
| But growth is already slowing from 2018-2019 vs 2019-2020
| period.
|
| 40% YoY growth for SaaS is par for the course, and the revenue
| figure is a bit light.
|
| Not necessarily a home run in the public markets though if
| there's a time to do a tech IPO it's now given the frothiness
| of the market.
| jkinudsjknds wrote:
| Sounds kind of mixed to me. What's going to enable them to turn
| an annual loss of ~$150M into a profit?
| nabla9 wrote:
| Unity turns into profit in the instant they stop seeking
| growth. Their annual losses are growing in line of their
| annual sales and marketing. Unity has year-over-year growth
| of 42%.
___________________________________________________________________
(page generated 2020-08-24 23:01 UTC)