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.
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.