Has Unity Ever Truly Been Refactored?

This kind of things happens all the time in Unity. With the introduction of the new PhysX version, they reimplemented the integration in Unity. Just recently they made a huge refactoring for OpenGL. In the past they had lots of code duplication and were now able to merge it into one area only. Structural changes take place on a regular basis.

 

I like this phrase a lot. I would like to have some protection from myself-from-the-past.

 

@scobi

Terrific post, blog-worthy even.

Thanks for that, and the extra reading

 

Good to hear, we do tend to shy away from talking about the competition. But Unity can obviously learn from it, UE3 in short was a bit of a mess, it was more of a "game framework" as opposed to a generic engine and it was very large for the amount of platforms.

UE4's modularised setup and removal of many interdependencies really has improved the speed of development. Hopefully at some point you can open source (well give access) to more "modules" so if quick fixes are required we can deal with these our selves and hopefully merge the branches back into the core if approved.

Secondly, hopefully it will increase your iteration time for feature sets. UE3 didn't tend to move that rapidly, but with the new re-structured code base Epic implements features faster than most can learn them. Not to say the rate of iteration doesn't have some "side effects".

In the end, please don't take this the wrong way. As a customer / end user I'm not bothered how you do it (just like game dev end users), I'm only interested in stability / feature sets and performance improvements. The iteration times to achieve this in a closed engine is more important than something with direct access to source. So the onus is really on you guys to sort it out and pick up the pace...

 

Sure, some do. But overarching problems won't be dealt with using this ideology.

 

Like?

 

Here are some issues I have with unity:

Awful implementation of Terrain, shaky integration of Global Illumination, so called "AI" features that have sit on the back burner for ages, dead stupid Input system, awful scene management, plain broken prefabs, Mecanim is dead stupid for anything except characters and the other one is now legacy and unsupported, awful file serialization, an inspector from 1999 that hardly supports any data types, the only way to actually debug a script is to use third party tools, no chance in hell of merging a scene, no chance in hell of merging anything except a script, bad iteration/development time on anything On the engine from UT, tons of low hanging fruit that has been mentioned for years and nothing done(please add an option to save the project and the scene in one motion as been request before I was born), absolutely no documentation of anything about extending the editor(none worthwhile or covers anything besides the extreme basics), can we compile the code on a seperate thread instead of locking up the editor for 30 seconds every iteration?, how about the hundreds of crashes in the last six months, awful designer workflow(everything needs code to happen), custom shaders are painful to write and the standard shader usually doesn't cut it for anything complex, plain absurd coding standards ALL over(what the heck is up with the Input class????, using reflection to call methods?? No interfaces?? Namespaces??), and finally dead awful online official support. Please note that these are just the ones off my head.

The frustration is boiling up instead the team with Unity, the designers hate it, we had to train our sound engineers in coding just to get something going(which took weeks from the code team), the artists begged us to choose Unreal and quite frankly I'm beginning to think we should've. Too late now, we're locked in. But we will be seriously considering other options for our next project.

 

If you're doing something serious for PC and Console, I'd dump Unity in a instant. No such thing as locked in, with all the materials and tools you get, you'll find yourself clawing back time VERY quickly. Literally you'd have to be about to release the game not to consider it...

Not that I don't think Unity is great for certain things, it is awesome for 2D and mobile / quick prototypes.

 

Most of the mentioned things are on the roadmap, so Unity is well aware of those issues, but I don't see how a refactoring as you mention it could solve that in a shorter amount of time.

Sorry, but what you are writing sound more like the workflows and pipelines were not properly prepared and tested for the project. This certainly leads to frustration, but I frankly don't see how Unity could be blamed for that.

 

"Most of the mentioned things are on the roadmap, so Unity is well aware of those issues, but I don't see how a refactoring as you mention it could solve that in a shorter amount of time."

That's exactly what I was thinking. A refactoring the way you keep describing it basically would mean that Unity would be "frozen" in it's current state until the refactor is done. If the stars, moons and coding Gods all line up properly, about 6 months to a year later, we'll get to download the newly refactored Unity RF... and it will have the EXACT SAME FEATURE SET as today, but the executable will only take half the space it used too and everyone's project will run 10fps faster. That's not really what you're after at all apparently.

If you look at "release timelines" it's obvious to me Unity DID do a big refactor at some point because 4.3 was the defacto version for a LONG time and then BAM... 4.6, BAM, 5.0 beta... BAM 5.1 and now we've got an actual roadmap to future versions.

 

What has workflow's and pipelines got to do with product inadequacies? I can say to end users, sure the character controls suck but hey you can work around it.

No, it doesn't work like that and it never will as long as people pay for a product. I'll agree I can't see how re-factoring will help at this point, it took Epic 4 years to "re-factor" as such.. It's too little too late..

 

I am not denying that the mentioned areas are weaknesses of Unity. But the proposed refactoring makes no sense in my opinion.

With the pipeline, I was referring to the frustration part in the project that was mentioned. When sound designers have to be trained in coding (and it seems they didn't consider this upfront) and if the designers want to switch, it is pretty clear for me that the pipelines were not properly tested and that mistakes were made during the preparation. Maybe the mistake was the choice of the engine or not enough preparation time.
The mentioned areas didn't become worse from one day to another in Unity.

 

Maybe because then the issues could be fixed quickly and correctly instead of piling more crap on a shaky foundation? I'm a big fan of doing stuff the right way.

 

Yes totally. All those workflow Issues are the teams fault. Yep ok. Let me just spend a few months working on Unity's workflow. You've obviously never worked with a large team.

 

I agree, as said I don't believe re-factoring will help at this point. For all the logic, in reality it's not been quite that simple.. Around a year ago, Unity was the only viable option. CryEngine certainly wasn't and UDK / UE3 required an arm and a leg in sales costs (or a ridiculously un-indie friendly up front cost).. UE4 was little out of Alpha really.

So the option was make your own or use Unity, as making your own takes at least a year and a half of development time. Unity was never a good or very logical option, it was really THE only option for indies.

So I agree it's not become worse from one day to another, it's been like this since I started using it back in 2011. Besides a 64-bit editor (which is recent) and a PhysX upgrade, it has been pretty poor across the board and most likely will remain that way.

It was a huge time consuming decision to move, but it was in retrospect a very good one.

 

This is unfortunately true. We chose(from limited options) to use Unity, and now we are so far into development that we either throw away 3 years of work or continue trudging through these issues.

 

Issues appear in teams on a daily basis. And certainly a lot of problems can not be predicted. But if you have to train a sound engineer in programming, it is not Unity's mistake. This has to be sorted out or planned upfront. There are many things one can do upfront. Based on the design document, some scripts can be prepared and then discussed with the sound engineer to get an understanding what is needed. Maybe use Playmaker if that helps, maybe preparing some custom editors to simplify the work.
I don't know why the artists want to switch the engine, but there are most likely issues in the workflow or certain things can't be achieved in Unity. It doesn't actually matter. The essential aspects of that have to be sorted out before a production with a large team begins, especially with a large team!
Unity, like any other engine or application, is a tool you have to know before the production starts. The most important aspect is to understand the limitations. If that preparation was not made, it is not Unity's fault.

 

Did you not read my post above? It explains why it is the way it is.!

 

Why should I have to? I'm seriously sick of all these workarounds. It's not my job. Fix the damn issues.

Working in Unity is now just some big workaround. It's becoming a sick joke.

 

Just to throw it out there, right now lightmapping on Android is a showstopper, because I don't want to release my game on Android without any shadows or lightmapped shadows, as it severely degrades the visual quality of the game in every sense of the word.

And while I 'could' still ship the game, I would be short-changing myself, my users and all my hard work.

Also the UI issues with Depth only/Don't clear flags on the camera are causing major problems for me when OpenGL ES 3.0 is used.

 

Why is using something like PlayMaker a workaround? ShaderForge isn't a workaround either. If it helps people to get the job done, it is not a workaround, but a solution to a problem. If you come up with a better solution during the preparation of the project, you won't need such tools anyways. But it would be naive not to consider them at all.

During the preparation of a project, it is someone's job to make sure all the production pipelines are working. That is specific to every project and solutions need to be found before the production starts. I don't know whether this was your job, but someone should have been responsible for it and should have done it upfront.

It is not my actual intention to criticize people in this forum, that's why I won't reply anymore in this thread.

 

The problem is that there is no solution that works. We've used two major audio plugins and tried Unity's native audio system. All don't work. All need tons of programming assistance. So we've resorted to having gameplay programmers implement all audio. In the preparation of the project, while I was not there, should've the team spent a month working on a wrapper for the audio system, instead of expecting the engine to make our jobs easier and not fight against us?

 

Well it's like your not trying to understand and / or ignoring if someone comes up with a decent counter point. As said at the time Unity was the only viable option, unless you had hundreds of thousands to spend or was happy to give away 25% of your profit share. This is an Indie engine after all, it's not a AAA solution.. If it was then Unity would never be a consideration in the first place.

Were not all multi-million dollar outfits that can throw money at the wall until a problem goes away. Today, right now what you say if you're starting a project it's completely correct. You have three engines "really" to try, CE is getting better, UE4 and Unity.

Decide what's best for your project / platform and job done. It wasn't always like that though..

 

Happy 10th birthday!

 

No it actually doesn't. This can be confirmed. Save Scene does not save prefabs nor some other assets.

This is clear as day when using source control, prefabs are NOT updated or written to until you select "Save Project". "Save Scene" does not do that.

Edit: Woah this is interesting.... Only happens on some versions of Unity.

 

There are certain basic things that just havent been done for example being able to create an in game rebindable control system. redonkulous There are some things that unity never bothered doing for example making a box-capsule collider character controller rather than a capsule collider.

 

This one. Since we don't have custom inspectors for anything on that object. But it was an older version of Unity. (5.1).

Anyways, I think this is the end for me for right now. I've had enough for a while. Feel free to continue discussion if it so fits.

 

This is an important point.

Understand that "shipstopper" is not as obvious as you may believe it is.

Take this bug thread for example about Unity forcing certain Android permissions: http://forum.unity3d.com/threads/un..._state-automatically-how-to-remove-it.333431/

One dev might say "I don't care, I needed those permissions anyway". Another dev might say "we can't ship a product requiring those ridiculous permissions". Ok so Unity provides a workaround and they consider that good enough. But the workaround requires a change in workflow which may not be possible for some projects (as seen in that thread). Which leaves the "Unity vs Its Customers" conflict in a deadlock with the customer believing Unity is a poorly supported product for not fixing its bugs. And I will call them bugs because from the dev/customer's perspective, it is unexpected/undesirable behaviour.

 

Considering it's not unheard of for audio to be implemented entirely in the last six months of development, I would say you're on par. If you are now building new systems to do things that outright weren't possible, that might be a Unity problem, but if your sound engineer is now writing hooks into your established codebase, that sounds substantially more like it's your fault for not planning for how audio would be implemented. To be fair, I have not touched audio, if for no other reason than I would be implementing systems as complicated as, if not more so than, GUI systems and possibly input as a whole.


I don't know if a refactor would help, but at the very least I would like to see more of the API put into proper namespaces. Just having someone digging around would find things that certainly don't conform to modern practices. There is too much on the editor side that clearly comes from before the time of generics.

 

There seems to be a misunderstanding, that's why I am just going to clarify it.
For a project, it doesn't matter what kind of engine it is. It can be AAA, indie or custom, it doesn't matter. When the project is being prepared, the difficult parts need to be figured out and solutions need to be found for those. One of the decisions that can be made is, that none of the existing engines is viable for the project and the given budget. That means the project can't be realized or changes need to be made, such that it becomes doable. It sucks, but that's the reality!

 

That's logical, but far from reality..

Whilst I firmly believe due diligence should be a pre-requisite, there is no way to discover right out the bat what challenges you will encounter six months or three years down the line.

There might be a bug or feature set that you need fixing in one version, that breaks something else in a later release or they decide to deprecate a feature which said version contains a bug fix you need. It happens, that's life.. The only way to guarantee the vendor isn't going to be an issue is to have access to the source.

So by your logic Unity isn't viable for anyone.. Companies who could afford source logically would factor their own systems to be optimised for their platforms and technology. They wouldn't reverse engineer and rip out Enlighten then fix Unity's issues etc. because it costs more.

End of the day Unity wants custom, I can't have a customer say to me I have half baked features and problems in places and I reply with sucks to be you, should of researched 99.5% of the game before purchasing. Because they'll just get a refund and make my competition richer. If you loose custom to other viable sources, there is a reason and the blame solely lays on the developers shoulders..

 

This is not what I was talking about!
I am not talking about completely unpredictable aspects. I am even giving precise examples. Based on the concept art, it is relatively easily possible to experiment with the graphical pipeline to figure out what is needed. Will we need custom shaders? Do we have someone who can handle that or do we need an external for that? Will image effects be needed? Is a custom solution required? Do we have someone for that?
Based on the prototype mechanics, you should have a rough idea of what the most extreme visuals are. Create some placeholders for that and test them using one or two reference machines. Like that you can start to define limits for the 3d art. You find out how detailed the models and textures can be.
If the terrain should be used, make sure to test it properly to find out whether it is usable in the required scale and whether it is sufficient from a graphical point of view. If it can't be used for whatever reason, the same tests need to be done again with meshes to see whether it works with meshes. Important aspects might then be: Can we still use the required amount of rocks and vegetation? Do we need to create custom tools to place those? Do we need wind in the vegetation? Can we achieve that?
But it goes further: You find out whether you will need LODs. Maybe you have to use occlusion culling. If so, does it work in the test scenes? Is it necessary to extend or adjust the test scene for this? What are the limits? Do the level designer(s) and artist(s) understand how occlusion culling works or do they need training to make good use of it? How do we make sure during the production that occlusion culling is take into account by everyone?

I could go on and on with that and depending on the answers, there might be more questions that have to be answered. Yes, this costs money, yes it takes time, but it is needed for a production that takes several years. You can't rely on anything that doesn't work right now, or you need at least a fallback solution that you know will at least work. If this kind of preparation is not done, Unity can't be blamed for it!

Just to make it clear: Yes, Unity doesn't have all features I would like to have. Yes, Unity has bugs I need to workaround. Yes, Unity has some ridiculous things that I absolutely hate. But it is my job to understand those limitations before I start a project! And if I didn't properly research upfront, I should be open for every creative workaround and definitely not blame Unity for my shortcomings!

No matter how you turn it around now, I won't reply anymore.

 

As were talking about "professional" evaluation and scope from teams of high quality:

Most of this stuff is beginner level stuff and doesn't even require factoring in, anything but lighting (GI) systems can be easily and quickly integrated as every engine is based upon GL or DX API's so none of that really matters. The limits for "3D art" is completely dependant on the game and you can always re-factor. These aren't ISSUES! They are irrelevant.

It's the unpredictable elements that require evaluation as the engine is wrapped in a binary release.

Again completely irrelevant, any experienced team worth it's salt we can create procedural placement generators in a couple of days, it doesn't really have a massive bearing on the overall project (neither does any other component listed).

What has any of this got to do with half baked core features you have no access to? Again irrelevant.

From the list you specify, these aren't the sort of things large or experienced teams concern themselves with. You can't understand all limitations until you test said limitations, which takes time.

If Unity advertises a product that works in X way, it should work in X way.. If you don't want to blame Unity for game degradation (resulting in potential loss of sale) like @Meltdown specified that's fine.

Doesn't mean you're correct, if you are having to initiate workarounds for major components. Again going by your logic I can say your evaluation to use Unity is incorrect and you should of either used a custom solution or another engine which enables correct process and work methodology. Again by your own sayings, if you can't afford to do that or lack the skillset too bad.!

But that sucks, it's detrimental to both you and Unity. Epic work with us and other Indie's to find limitations and improve upon them (both us and Epic). It's a relationship that negates this whole entire conversation, holistically it's more important than any feature or any bug..

Re-factoring isn't really the core issue, neither is the shortfalls of the engine (all of this can be circumvented). The major proponent is the relationship Unity has with it's customers..

 

@ShadowK, please don't take my answers out of context! I was specifically referring to issues mentioned by the OP in a follow up post. And all I did was to point out that most of those could have been avoided with a better preparation.

 

I don't disagree with that, probably could. But holistically I suffered development hell (as well as other people working on larger projects who have used Unity for ages), so I can understand the frustration.

When it's problem after problem, we as humans can tend to blow things out of proportion. But I will not accept for one second it's quite as "black and white" as you say it is.

I'm not being a pain for the sake of it, neither is this personal or aimed with any malcontent.

 

What was your experience in presumably transferring your project to elsewhere?

 

I wouldn't say difficult, odd would be the better description.. I'll PM you the nitty gritty. This is still the Unity forums ..

 

It was never my intention to draw a black and white picture!
Many of us went and are going through a development hell. There is one thing I will never understand. Why are people blaming their tools for issues they could easily have tested before the production started? Sure, you can do research in the production, but that clearly needs to be early on, such that you know as soon as possible that an alternative has to be found or the project needs to be stopped.
When you do your homework, you can solve many issues early on or work around them or you can find out that something is not doable. There is no reason to blame the tools when the homework wasn't done properly! No one has to worry about jobs because a proper preparation was done for the project. Enough issues will appear during the production and there will be plenty of reasons to blame the tools.

 

maybe he has done the homework and its now time to blame the tools... but you have made some good points.

sometimes it also better to let a man blow off some steam once in a while.

 

I was going to say before TechiTech joined in, blaming the tools is a matter of experience. Like Unity said, there are hundreds of thousands of tickets raised and only a small percentage of them are actual issues.

It's like this, if I research and buy a top of the range Stanley crosshead (Phillips) screwdriver. Buy a backup just in-case the first one breaks, go to a job and start un-screwing things. The first screwdriver breaks, not a problem I have a backup..

A couple of hours later the second one breaks, you're stood their thinking WTH? You did the research, you even was getting along nicely with the tools at hand and all of a sudden BANG!. You're stuck.. That's the time to BLAME the tools. Research counted for absolutely nothing...

I whole heartedly agree most of your headaches can disappear with ample due diligence. But if 15 years of experience across tons of elements in games has taught me nothing else, you can't prepare for every eventuality. No matter how big your team is, no matter how experienced your team is.

Edit:

For me the most important thing is how the vendor reacts to features / issues, if they are willing to work with you it's not really an issue and you can carry on.

 

I would never disagree with that. And I believe I mentioned in about every of my posts that not every issue can be predicted, because I, like everyone else, don't have a general recipe to prevent projects from failing or being finished in a smooth way.

I replied to a specific case with example that look suspiciously like insufficient preparation in my opinion. And that's why it feels wonky from my point of view to primarily blame Unity.

 

And no matter how many times those experienced people have encountered the same issues before.

 

@zombiegorilla

Had to laugh at that one..

That's cool and you could be correct, not a clue..

But I've been mainly referring to this:

I think this is the point really, what do you think to this?

 

I have a very strong opinion about that: It is a waste of time to discuss it.
Usually this kind of statement has its origin in tangible problems. I am usually open to discuss those, because there is something that can be discussed and the problem usually relatively easily be understood. And I was only talking about those for the whole time.

WARNING: Here you see a too long text why I believe it is pointless to discuss it:

• I have never seen Unity's source code. It is clear that they made mistakes, like everyone does. The Unity UI was a pretty unfortunate topic, but it is not clear what the actual cause of this was. As it was something new, I don't think some existing code was the cause for all the delays.
• They also didn't understand what the users exactly meant with nested prefabs, but that sounds more like a communication problem than a coding one.
• It seemed for a long time that they were unable to upgrade to a newer Mono version, but it finally turned out it was related to the license. So, again failed communication.
• GI is another interesting topic. Pretty simple, it is not done yet and was released too early, likely because Unity 5 had to be shipped.

The conclusion of all that is: I have no idea for most of those issues what the underlying cause was.

What I know is that if Unity was a "gigantic heap of spaghetti" code as stated, it would be impossible to make any change in Unity without having some weird side effects in many other unexpected places. I can say for sure that the situation can definitely not be as bad as stated. But other than that, I have no clue.
Yes, the Unity development feels slow in many places, but I have no idea what the cause of it is and I won't blindly guess just for the sake of it and come to some conclusions that can be completely wrong.

Regarding the future:
It should be relatively obvious to everyone that they made a lot of changes in the development. They have now shorter release cycles which helps them to react faster to reports and like that more testing from the users takes place, which is a step forward in my opinion.
They are constantly improving their QA. They are improving their automatic testing and they also made a step forward in the bug reporting process. They have now an issue tracker and the dusty feedback seems to become at least slightly relevant. All Unity Pro owners can now test the beta version, meaning they might get more bug reports and feedback early on. It might also help that there is no more feature delta between the free and paid version.
Most of those things were recently introduced or improved, but I think there is at least the potential slightly accelerate the overall development. I don't know whether this will be the case or not. The only thing I can say is that I can see some positive changes. That's all.

Conclusion: I have no idea.

QED: It is/was a waste of time to discuss to this topic (in my opinion)

 

Well it passes the time while baking lighting and coffee right? (Plus you are kind of discussing it )..

But I don't think it's a complete waste of time (if they listen at all and as I said top of this page), Unity need to modularise and give access to more components so we don't have to rely on them as much. It will require some "re-factoring" to do so, if they can't keep up with support as a customer that's not my issue and it's developers that get lumped with problems and no way to fix them or wonky / workaround implementations.

Secondly the iteration times have been beyond slow, we have single people on the asset store running rings around them. That's a question I've always wanted answering, what is going on? Before you say well we have to test for X platform etc. etc. Epic have just merged some instancing / batching and POM created by some users, it's been internally vetted and ready to release for distribution (as binary and source).

Questions that might be on some lips? Why do I care?

Well I don't care that much, but it's always nice to having options and competition is nothing but a good thing. If Unity can keep up it makes everyone's lives better.

Why am I always jumping on Unity?

Well I suppose I can be a little hard at times, the engine itself is pretty good. So obviously a lot of hard work sweat and tears have gone into it, although it's very much dated. It requires a boat load of new features to remain relevant and they need to close the gap and offload some of the pressure.

They are improving I agree Dantus, but until they start going through fixes (not QA) and features much more efficiently and quickly. This remains the biggest question:

Why should we (devs) spend our money on Unity as opposed to the competition? Because at the moment I can think of little reason to (dependant on project of course).

 

What kind of modularization do you have in mind? Which parts of Unity should be replaceable?

Comparing the Asset Store products and Unity's own development is rather difficult. When Unity is creating something, it needs to consider all possible cases that are often ignored by publishers in the Asset Store. E.g. a proper integration with with prefabs is not always a no-brainer depending on the asset. And in my opinion it is clear that Unity doesn't just release the first version, but they usually make a few iterations before they release it. I don't want to deny that some publishers are doing an outstanding job. But I believe they would be slowed down, if they had to consider all those use cases, make a few more iterations, and be able to deliver to all platforms and with the need to create automated test cases.
I already don't think you can compare the work of Asset Store publishers with Unity and even less Epic and Unity. From my point of view, it seems like Epic pushes to release new features as soon as possible, while Unity spends a few iterations to polish them. Though, I might be completely wrong about that. I neither know internals about Unity, nor do I know any internals about Epic. It seems they have different philosophies. So be it. One of them may turn out to be better on the long run, but I don't want to judge that, because I can't.
I am sure both companies are doing their best to improve their products and to satisfy the needs of their customers. They have established ways how they are working and they have their development goals. I am sure they have discussed almost all those "big" topics internally in depth.
To me it is comparable to game development. When a game is released, almost anyone finds things that are not good in one way or another. People start to make statements like: How could they miss that X is really horrible! Worst ever! But if you know the internals, it is usually the case that the developers are well aware of those issues. Sometimes it was the best solution they were able to develop, sometimes the time or budget didn't allow another solution. Gamers tend to assume that the developers didn't realize the weaknesses, which is usually not true.
From my point of view, you are taking the position of a gamer towards Unity. I am sure that most of those topics were discussed numerous times in Unity. They are well aware of those issues and they know what their options are. That's why I strongly believe it is still a waste of time to discuss it, because Unity is already aware of it.

With that I don't want to say that we shouldn't discuss weaknesses of Unity. But I believe those discussions are often too abstract and there is simply a lack of information about internals to have an actual discussion.
For me, it is a completely different story when it is about tangible topics. Just to give an example. Editor scripting is often praised, but if you want to integrate an extension as deeply into Unity as you Unity itself usually does it, it is going to be a pain in the ass. Unity is using a lot of internal magic and a lot of that is not exposed at all. This is a tangible topic that can be discussed in the community in my opinion.

 

Didn't Unity 5 add some features to pathfinding? Geez, we were hoping to convert to using that over A* Pathfinding Project to start to become less dependent on 3rd party code(and we also redid a considerable amount of the top end, which we were hoping Unity would just let us handle ourselves or modify)

 

Beginning to sound like a hate-unity thread. Did any positive benefit come from this thread at all?