Unity Software Inc S-1
sec.gov
sec.gov
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.
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.
> [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...
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.
> 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...
Thanks for the correction.
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).
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
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.
But in the end, Electron or Unity doesn't matter, both are equally bloated.
Unity's co-founder David Helgason is an investor in Labster:
https://techcrunch.com/2017/09/06/virtual-science-lab-startu...
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.
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 :)
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.
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).
Pretty certain you can't do that.
Perhaps I could have optimized better, but I struggled to find ways to do it. Admittedly, their computers were laughably old and terrible. Building $250k robots and working on under-powered laptops from 2010 or so - I never understood it.
One of the main obstacles that could have helped a lot was reducing mesh complexity. We were working with models directly from Fusion 360 and the meshes were incredibly dense. No one was comfortable deviating from the original models, so interpolating meshes or even manually reducing polygon counts wasn't an option. There was concern that we'd end up losing important data and create inaccurate simulations.
Anyway, it was an incredibly fun project and Unity made it effortless to prototype. It was ultimately built from the ground up using another tool which allowed for much better performance, but Unity allowed us to finish prototyping way, way ahead of schedule.
I for one am not eager to download a 3D rendering engine when accessing a website. For a good number of reasons.
Well, that escalated quickly.
Whenever I had to work with it in the past, we ran into bugs inside the closed-source C++ part of the engine which then delayed release or required expensive workarounds. Their sales department is ghosting us because we're a mid-sized company and their support is closing tickets for "LTS = long term support" releases as "please resubmit with current beta".
Then there's the overall st-show with Unity deprecating things as soon as they have a beta draft for its replacement, which basically forced everyone to use external networking libraries. Plus HDRP is still buggy, but they already removed the old built-in RP.
And if that wasn't bad enough already, their own built services will randomly fail if you use advanced features, because they run their OS X builts in QEMU on linux or something.
Last time I checked, they now also deprecated the ability to write custom shaders. I agree with their reasoning that I should not need them. But with all the buggy mess in their engine, I surely DO need them just for workarounds.
For fairness of comparison, we've run into equally bad bugs with UE4. But at least for Unreal, I have full C++ source code so I can fix things and move on. With Unity, you're constantly waiting for their support team to (ignore you / close your ticket / make fun of you) help you.
As for the Unity ML agents, I find that rather scary. There have been many papers about AIs exploiting bugs in the training environment. Given how buggy Unity is, I would expect AIs trained in Unity ML to wreck havoc in the real world because they're used to the physics glitching or something like that.
Unity is great to get started as a hobbyist. But as soon as you actually want to release something on a consumer quality level, it becomes walk through complexity hell.
There's a very good reason why every bigger Unity studio purchases source code access and has dedicated Unity-bug-fixing employees on staff.
I never thought I'd say a tool brings me joy, but Lens Studio brings me joy.
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.
Whew boy does Unity absolutely put Lumberyard to shame. Unity, for me, is absolutely busted but also extremely approachable and generally good to use.
I'd love a game engine platform that would come along and promise API/library stability for 5 years. Any game you built on that engine will be able to run 5 years later if you need to update it.
There isn't a ton that changes with game development surface level, the subsystems change quite a bit, that is fine. That is what the engine is for, to simplify the subsystems and create a stable platform on top to speed up development, not have a bunch of leaky abstractions and new unstable platforms on top of that.
I wish that game engines had more standards that were industry respected and you could bounce between engines more easily as well, like other frameworks do with standards.
We are in a "move fast and break things" age and I can't wait until it gets back to "let's move fast but not break things if we can help it unless it makes massive improvements that make it worth the cost/time and most importantly, maintenance tax on updates that aren't needed or break things for no reason. And when we do break things we will do it in a way that is parallel and if possible just swaps out the subsystem not requiring massive surface level changes that just get you back to baseline functionality".
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.
Well looking at their income statement, they were actually running at a loss haha
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 :)
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.
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.
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.
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.
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)
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?
I would be willing to consider Perforce, but it seems very expensive.
What is the industry standard means of open sourcing a Perforce repository?
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.
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.
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.
edit: whoops didn't see you'd already mentioned VFX graph
I had a year long dance with Unity around a number of unrelated issues. At the beginning of the year, vLatest couldn't render with anti aliasing on the Oculus Go, no matter the level of scene complexity. That eventually got fixed, bit then stereo rendering broke. That eventually got fixed, but then JSON deserialization broke. That had a work around that doubled the size of my APK and increasef the time per game by 20%, so performance took a nose dive, but at least that was something within the realm of manageable.
Unity might be great if you are a raw beginner and you literally know nothing about suffrage development. But it is not a tool that can effectively be used to create quality, stable software that works well on a variety of user systems. If you're already know how to program and you're interested in making great products, you'll be better off leaving Unity behind and making apps without a game engine.
I'm done with it. 5 years was enough. I'm going back to WebGL for the little stuff. I'm using Veldrid in .NET Core for bigger stuff. Everything else outside of graphics is ludicrously easy in comparison.
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.
The problem is definitely churn and shaky foundations.
Unity has a "version 2" problem, the "second-system effect" is a major tenant of Unity engineering which sucks [1]. I really wish they locked down features like they did back when the team was very small. Maybe that is the problem, too many cooks.
The "move fast and break things" has also made very unstable systems and updating a chore. I like moving fast, but only break things if what is gained is more than before, not back to the same footing.
I have been using Unity since 2008, shipped many, many titles on it but due to their churn and every changing APIs/libs/features, updating games is a major pain even mere months out.
Networking is a major problem, always in flux and Photon is still the best probably. There are other third party solutions to it but I don't know I'll ever trust a Unity networking library again.
UI is a major problem, again always in flux, from GUI, to UnityUI, and now to UIComponents. Unity loves to push off all problems with a shiny new future thing that never really solves much but adds more problems.
Everyone knows about IL2CPP, the animation changes, particle system changes, rendering pipeline flux and more so I'll spare you [2].
It seems much of what Unity changes is driven by announcements, marketing/finance over what engineers want. If Unity went back to just making it code based, THEN add on the editor tools to that lib/api then we'd be in a better spot. They seem to drive things through the editor first then allow code/api access. Libraries like particle systems, animation, ui and more all had editor access before code access and that is frustrating. Let developers make tools needed and start with a clean, solid, well designed API that isn't going to change every version, change the guts of that system abstracted to a clean, simple, atomic wrapper.
Unity is still the best multi-platform engine for mobile and other areas, but it is nice that competition is here with UE4, Godot and others. UE4 and Godot are focused on simplicity, UE4 is arguably more simple than UE3 and largely that is because you can take the C++ route, Blueprint route (which rides on their apis) or a mix. Unity's big selling point is their editor, but it clouded their engineering focus as editor first over code first.
Unity really needs to make games on their platform that they must keep up to date with every build like Unreal, that way the pain points hit them more as well, and they will smooth out that process of shipping, updating, actually making games on their engine.
Unity is pushing to be Unreal, Unreal is simplifying to be more like Unity, Godot is almost a better indie/small/medium engine at this point because they are limited by how much change they can make. Progression doesn't have to slow down, we just need cleaner, more well thought out APIs and wrappers for subsystems that can change. People use Unity, Unreal, Godot, others for an engine team to think about these things. I wish more of it was standard in game development so it was a littler harder to change surface level functionality, not to slow things down, but to make a more stable platform/abstraction/atomic surface where shipping games and updating games is easier.
I think overall software today is stuck in the second system effect too much. No one values clean APIs that the surface, signatures, and actions are in a clean wrapped, abstracted, atomic system that the inner workings can change more easily. There are too many leaky abstractions today or no attempt to create atomic/standard interfaces that allow "move fast and break thing" underneath, rather than on the surface.
I liked it when you could read the docs, use the tool, and code libraries, and much of it made sense, simple, good naming, discoverable. Now they rely on training, youtubers and so many other things, probably to create more marketing, that there is less incentive to make it simple again. Engineering is taking complex and making it simple, not taking something simple and making it complex, then another complex system on top of that, then a few to decide from all that are EOL'd in a year or two.
My hope is Unity slows down a bit, works on stability, and really makes locks down some of these libraries. Though I thought that Unity would do that when they went subscription over having to promote new features every year to get you to upgrade. Subscription should have made them focus on stability, it didn't. I am hoping going public will do so, but it could also spawn more of the same.
With that said I love Unity, dig Unreal and others. But I do see people going to custom engines again that are more standard just so that breaking changes are at the whim of the developer, not the engine team that you pay for which force these breaking changes on you at sometimes inopportune times.
As for the 'going public' side, I am not sure it will improve the actuals problems of the product : in my experience, going public is only here to : 1) Cash out the actual investors (in french we say 'des cigares vont changer de bouches')
2) Give many of Unity main developers a lotery winning ticket. This is NOT going to stabilize the team, for sure. Even less the product.
> It seems much of what Unity changes is driven by announcements, marketing/finance over what engineers want.
That's my exact feeling about Unity, it reminds me of Windows, 3DSMax, and many other software where the mentality is basically : let's pile up every shiny features on top of each other to attract more companies & people.
Unity is a big mess. There is no coherence, no planning, no step back on what they are doing.
Sure on the short term users don't care. You can get the latest shiny features that will make your game look cool.
Unity is great when you have a deadline and you want to quickly get something working by throwing a few asset store components together and then adding nice looking effects on top of it. It's messy but it looks good and your boss is happy.
But building whole games on top of this Tower of Pisa gives a very unsatisfactory feeling of not doing clean code.
I think Godot vs. Unity is going to be the same story as with Blender. Short Term, marketing and shiny features win but on the long term doing your own coherent way without caring about the competition wins.
Uni / Work is forcing me to use Unity, but I'm going Godot whenever I am allowed to choose the engine
I used to do .net for a living and it was like every single interface or library I wanted to use was off-limits because it was claimed by the engine. Want to serialize your objects? All you get is an undocumented, doesn't-even-work .to_json function cause we somehow broke all the other .net serializers. Have fun!
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.
Does that line up with your experience?
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...
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.
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.
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=%...
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
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.
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.
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...
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.
AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html. They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated. 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!
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)
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.
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.
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
Perhaps you should explain how I've misunderstood GetComponent.
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.
I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
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.
Components do have an enabled flag.
https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
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!
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.
The Unity editor also has lots of features that IDE’s have already, including a profiler, ability to inspect the world hierarchy, inspectors for components on that hierarchy, and ability to pause and restart execution.
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.
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.
> 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.
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.
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.
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.
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!)
I'm not a game developer, but I like to keep an eye on how its done specifically because it is fundamentally different from how I typically do things in SAAS / mobile app land. Its a good way to get a broader view on development, and I learn new things _constantly_ by looking at game development.
It all depends what you are looking for in a game engine. If you want to be fast at having something nice looking on your screen , then yes Unity + asset store is great.
If you care about clean code, maintainability, elegence of concepts, abstractions, architecture, long term, etc. then Unity is very bad for that.
> video game engines move and change all the time, that is the nature of the video game industry.
No, a fast moving field is not an excuse for having a messy architecture, half abandoned features , a unintuitive UI, no planing, and puting all your budget in shiny features and marketing instead of long term robustness and coherence.
Look at Blender, they maintained coherence in fundamental concepts, architecture and UI over time yet they are in the top most amazing 3D softwares (and now 2D with grease pencil)
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/
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.
Your comparison was nonsensical in the first place, your entire take is painfully uneducated, but the comment you replied to is playing along. Then you're complaining they did?
Unity has created projects on a scale that would have failed if they were using a product that justifies hundred developer engineering departments to build crud apps with dynamic content...
> Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering department.
No one who has used Unity for any extended period of time would ever say this, and really this is where most people who use Unity would stop reading.
It hard to directly refute because Unity marketing was almost non-existent for years of their early success. It wasn't until they shifted to cloud based value-adds their marketing even had any teeth, and that was almost a decade after 2.0, which was where Unity really picked up it's stride
-
And that blog post, so much ignorance about the technology you're trying to bash!
You could find the answers to half your complaints by hopping on Stack Exchange or Unity Answers (yes, Stack Exchange, Unity Answers exists because there has an immense amount of knowledge that is Unity specific, and it predates Game Dev SO by years..
And half your complaints just read like someone who's used to a web framework that takes 1GB of ram if you leave it's creator's website running for too long.
Null behavior is due to the link between managed and unmanaged code, the two have separate lifecycles, so that's why it works that way. It's a reflection of the fact that a lot of what you use from Unity is written in unmanaged C++ so that you can actually do useful things with it...
GetComponent should be cached in Awake not because it's slow, but because that's common sense, you don't want to do more than you have to while the game is running. You want to be rendering at least every 16.7ms, why would you waste cycles peppering GetComponent calls everywhere?And as a bonus your complaint about missing editor references in code that's not called often becomes non-existant since your component fetch will fail immediately instead of at access
Also how old is this blog post, it's been half a decade since GetComponent didn't cache internally, and even before that it wasn't the reason for problems unless you were doing something really dumb, it was a best practice to cache, not a requirement for a performant game.
Really, for a title like "Unity is fundamentally broken" this list is almost comical. What's broken is your understanding of what it takes to make a game engine as widely useful as Unity, as confirmed by your first comment:
> why is it so hard to make a good game engine?
If you don't know why, you're in no position to be calling anything "fundamentally broken"
Look at MongoDB's performance since IPO in 2017 for perspective.
The MongoDB example is fascinating to me. I'd love to know why they're doing so well.
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.
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.
E.g. one of my past clients is using Viz4D for interactive architectural visualizations on their website for marketing purposes. For them that existing tool is already so integrated into their processes, and the feature set so well tailored to their industry, that I doubt Unity will be able to offer something competitive to what they have _today_ in the next ~3 years with their slow pace of development.
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.
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.
What made the engine rise to prominence in 2010-2015, in your view?
Jump to 2019, their networking solution, UNet is abandoned. Multiplayer is a perhaps a top feature developers/players want. A great open source library called Mirror picks up the slack, but Mirror wasn't made by Unity.
As other commenters have mentioned, easily compiling to iOS made it a clear winning choice for game app development.
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.
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...
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.
I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence checks / branching" is starting to feel out of fashion as of late, and the ECS approach is something folks have come around to.
I've been playing around with such an engine for a side project. Here's a quick video -- https://imgur.com/a/BcnWJha -- you can see what the in-game editor looks like + some of the physics of the game (the game and editor run both in web and natively). I think with the ECS-queries approach the code comes out to be quite ergonomic. For example, I've highlighted the logic that makes the player be obscured by objects in front of them here: https://gist.github.com/nikki93/8cc5d99e45ad74e7f1053dbef287... The game-specific code for the whole game is in that 'main.cc' file and comes out to about 500 lines. The game also includes custom inspector UIs for the 'Sprite' and 'Feet' components that are defined right in that file on line 288-314 and you can see them in the video.
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.
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.
https://bevyengine.org/news/introducing-bevy/
A lot of people with experience in React are influencing the UI design.
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").
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
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.
Even their PC version is laggy, check out streamers restarting the game (!) before important and action packed battlegrounds turns.
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.
~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.
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.
Maybe more clearly, whenever you enter a game there's a loading spinner that freezes for several seconds even on the very highest end desktops; you'd think for a game whose main graphics concern is exactly "image asset streaming from disk", they have wouldn't need to hard-freeze the menu UI to do the loading.
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
I couldn't imagine solo dev on an Unreal Project .
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.
Ultimately, well resourced team may choose to develop their own engine for the flexibility.
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.
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 .
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)
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.
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
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.
> 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?
If Unity is the only buyable stock in the sector, then they'll feel the impact.
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...
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.
Promising financials!
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.
Should we expect $5 -10 billion market cap?
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.
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.
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
- 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"???
[0]: https://forum.unity.com/threads/urp-point-light-shadows.8819...
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.
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)
and to me that is a very odd side effect of companies not going public often
Or maybe a discussion about how to get price discovery at lower valuations instead of just dumping on everyone's 401ks at high valuations.
* 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
I also see they acquired 'Bolt' and made that part of the free toolset. I think 'visual programming' tools like that could be a great help in adoption by young developers. I also like that visual aides like that can help the understanding of underlying code.
This S-1 is a surprise, yet not. If you know what I mean.
Out of the various IPOs I've seen crop up recently, this is the one I'd go for, due to the changes in the way people are to going to have to learn and work, since the pandemic.
Right technology. Right time.
U like Unity, not Uber or Unreal.
Now they make peanuts from people who make millions using unity.
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
Good luck