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 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.
> 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.
> 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.
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).
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.
Ah interesting, I guess it makes sense considering its a different workflow from the two titles I mentioned which were compositing people into CG backdrops.
> 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).
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.
"...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.
Problem with the browser is it's optimized around countering network latency and security issues. All those optimizations are essentially worthless when running a native application.
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...
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.
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.
Agree. Unity has rather verbose graphs to describe GUIs, so it is more like XAML, which I guess works, but isn't exactly elegant. And no, Unity doesn't have any accessibility by default. Plus it tends to have a few ms of mouse cursor lag, which can be pretty infuriating to power users.
Yes, I guess. I was installing an app called Rekordbox (its a library manager and a performance app for digital DJ hardware on the Pioneer DJ platform) and, sure enough, spotted a bunch of Unity DLLs being copied in the setup program.
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.
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 :)
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.
Reading your comment makes me incredibly jealous, as I can only wish and hope to one day have a pleasant experience with Unity like you.
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.
Just curious, what do you think of UE's Blueprint? I wish they retain Unrealscript which could be a much more pleasant experince than linking graphs. Blueprint is the biggest blocker on my side, but again I'm not a professional so I could be totally wrong.
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?
I used Unity for robotics simulations, and while it was incredible in most ways, it was really heavy. A lot of the scientists involved were working with old computers and the simulator was a little too slow for them.
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.
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)
A very cheap way of getting all the netstandard2 dependencies together in one place for the sake of Unity's bullshit is to create a vestigial .NET Framework 4.7 library that imports all of the .NET Standard 2.0 libraries you care about, and then set its output directory to somewhere within your Unity project's Assets/Plugins directory.
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.
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).
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).
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.
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.
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.
Lumberyard is essentially the CryEngine Engine that Amazon bought. It is more complex but it also shipped excellent games on it. I think game engines should always be built around games shipped. Unreal is quite nice in that aspect. Yes the engine becomes more tuned to the game types that you ship, but many of the pain points are smoothed.
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".
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.
Unfortunately, you can't really count on sticking to a single version of Unity. There are so many bugs in the system that you will run into blocking issues at some point, with the only option to be either wait for Unity to release an update that finally fixes the issue, or end-run around them and write a replacement for whatever bugged subsystem you're dealing with.
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.
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.
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!
> 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.
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.
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.
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've only ever used Git with Unity and as long as we're disciplined in our process, it's not a problem. It's free, scales to any size team for free, and lets us open source our projects easily.
I would be willing to consider Perforce, but it seems very expensive.
What is the industry standard means of open sourcing a Perforce repository?
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?
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.
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.
> 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)
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
Unity is great and really took the mantle from Flash/Director back in the day. Unity is also a big part of why mobile games have taken off, that combined with the ability of anyone to publish to mobile stores and more.
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.
> 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
Very instructing résumé for Unity platform. Thank you.
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.
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.)
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.
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.
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)
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 :)
I've found additive scenes a little nicer for avoiding scene merge conflicts. Additive scenes come with a lot of baggage of their own, but it's worth it to learn to get that initial start up time down way more.
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.
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.
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).
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...
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.
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?
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.
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.
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.
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
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].
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.
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.
>GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists
I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
You should usually only call GetComponent<> in your Awake function, then cache the result in a strongly typed instance variable. This is widely known standard operating procedure with Unity.
IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method.
>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.
Totally and completely agree with everything you've said, but the fact that Rider - a 3rd party IDE - has to ensure all these things rather than them being baked into Unity is part of the problem.
But Unity isn't an IDE, it's a game engine. Totally different things. Better for Unity to spend their time and energy on the game engine and editor, not making yet another half-assed IDE. Developing an entire IDE simply isn't in their wheelhouse. While it's a lot easier for somebody like Rider who already has a full blown C# IDE to support Unity.
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...
The Unity editor gives you compiler errors and warnings in its console window. Why shouldn’t it give you these warnings as well?
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 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.
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.
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.
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.
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!
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.
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!
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)
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.
> 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.
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.
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
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.
The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense
I understand that GetComponent is a runtime lookup, and what I'm arguing is that Unity made the wrong choice. Runtime lookups lead to more bugs. They lead to slower code.
The best practices that have sprouted up around GetComponent say "Use GetComponent<> only in Awake(), and don't use AddComponent or RemoveComponent at all." But once you start following all these best practices, you've lost all the benefits of having GetComponent be dynamic in the first place. So just enforce it at a code level, and give me the benefits of static typechecking and compile time errors when I screw things up.
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.
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!)
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.
Sure theres similarities, but game programming is usually at the bleeding edge of computing compared to most other areas. Its like saying engineering a space craft isn't/shouldn't be different than engineering a car. Sure, there's overlap, but the fundamental requirements differ so much that a lot of it is _not_ applicable.
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.
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.
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.
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.
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.
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.
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.
> 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.
It may be your opinion, but after having used Godot I think Unity is horrible to develop with.
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)
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.
It was easier to learn than the alternatives (UDK, any of the Java engines) and consistently added clearly useful features.
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.
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.
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.
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"
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.
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.
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.
That point (keeping interactive rates) is basically one of the most important factors driving the architecture of game engines. I found this talk to be quite a good one regarding architecture for game engines (it's about the ECS in Overwatch): https://www.youtube.com/watch?v=W3aieHjyNvw
I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence checks / branching" is starting to feel out of fashion as of late, and the ECS approach is something folks have come around to.
I've been playing around with such an engine for a side project. Here's a quick video -- https://imgur.com/a/BcnWJha -- you can see what the in-game editor looks like + some of the physics of the game (the game and editor run both in web and natively). I think with the ECS-queries approach the code comes out to be quite ergonomic. For example, I've highlighted the logic that makes the player be obscured by objects in front of them here: https://gist.github.com/nikki93/8cc5d99e45ad74e7f1053dbef287... The game-specific code for the whole game is in that 'main.cc' file and comes out to about 500 lines. The game also includes custom inspector UIs for the 'Sprite' and 'Feet' components that are defined right in that file on line 288-314 and you can see them in the video.
> 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.
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
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.
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.)
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.
> 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.
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.
Not the _other leaders_ in the industry, but the leaders in the _other industries_ they are pushing into, like architectural/automotive/simulation visualization. In each of those they have to face very different competitors with very different feature sets.
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.
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.
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
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").
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.
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
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.
sorry mate, most of these complaints come from a bunch of misunderstandings, mostly "this is not how I'd do things." Worse is saying you come from web then explaining why this engine running a completely different domain is "bad." Think you don't understand why web is the way it is and how many levels of complexity you're missing.
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.
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.
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.
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...
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.
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.
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.
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.
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.
I don't think that's actually a fair explanation for why the game is so janky. Very simple animations that aren't loading new resources like Ysera Unleashed visibly badly lag even on the top end machines used for tournaments.
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.
Its not an explanation for why the game is janky. Its a rebuttal to the comment that HS(card games in general, really) is bare bones or should be trivial to run well. Almost certainly they could fix the issue with background thread loading and some UI tweaks if they wanted to. That said, the issue is most likely that they're simply loading texture data from disk on the main thread. This is the default Unity behavior with asset loads and it's not really possible to hit their RAM quotas if they load every card. A subset of cards reveals information.
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.
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.
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.
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'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.
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.
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)
> 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.
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
You can instantiate, position and script objects in code too. It is helpful to have an asset pipeline to import your models, textures, etc. but then, once you have your prefabs, you can reference them from code and instantiate as you see fit. There is a performance penalty to instantiate at runtime so best practice is to initialize your objects from code at load time, or the start of a scene. Object pooling is also very helpful.
Have you done any game programming before? A heavy reliance on an interactive GUI is very common because there are many things for which you want visual interactivity, such as placing 3D objects in relation to each other. That kind of task is either difficult or impossible to do effectively purely in code.
I have. Placing objects in an editor is obviously essential, I agree. I just expect to find code at the bottom driving it, loading the map etc, and it doesn't seem like any example projects or learning documentation for Unity is geared that way.
Basically I expect to follow code at the bottom until it loads some asset, which may create a bunch of objects, and register some scripts. Then I return to the code which can then get those objects if it wants.
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.
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.
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
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 .
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.
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.
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.
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
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.
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.
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.
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.
"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."
I've heard this term used a few times now - a "frothy market," or a "frothy startup," but I'm not familiar with it. What does frothiness mean in terms of markets?
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%.
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.
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.
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.
>
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
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"???
I really like making games and apps in Unity, and I don't like Unreal's workflow, but this is the hard truth. Unity's strategy is adding as many features as possible to cover as many cases, a tool to make anything, an asset market to find anything, but you know one more half-baked feature will replace another broken feature soon, or you'll need to buy an asset to make it right. Being messy is their strategy, unless they make a new engine with a unified plan and solid features, Unity won't be the best engine.
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.
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.
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 :-)
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.
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).
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.
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.
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
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.
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.
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.
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.
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.
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.
Having only just installed Unity over the weekend and starting to go through tutorials and starting to understand how I can build AR/VR/XR 'things', I've started to see the light and wished I'd started on this a while ago.
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.
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.
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.
I was confused and mixed up a story about Apple blocking Unreal Engine, thinking that Epic owned Unity. I figured they had been playing the long game, preparing a Unity IPO to launch in case Apple tried to block it.
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.
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.
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
> 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”.
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.
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.