Has Unity Ever Truly Been Refactored?

One thing I've noticed over the years of using Unity is the excuse of "such a large and complex code base". It's used to compensate for the slow, delayed, and usually extremely buggy first releases of additions. It is also used to state why changes can't be made quickly. I think what this really means is: "our code base is a gigantic heap of spaghetti".

One of the things that Unreal has done so well is maintain an excellent code base. Unreal Engine 4 was a complete refactor of the engine, and it's what has allowed them to be so agile and responsive. Additions and changes are made quickly, efficiently, and free of major bugs.

So when was the last time the structure of the entire code base has really been worked on, and serious action taken? I've worked on massive code bases also, and piling more features onto a shaky base is the wrong way to go. At my work, we do complete code reviews and any nessarry refactoring bi-annually. Sure, it sets us back quite some time in the short run, but we save so much time in bug fixing and are agile and responsive in adding features and making changes.

In my opinion Unity 5 should've been this refactor. Major releases are the time to make major changes. Major releases are the time to break backwards compatibility. Major releases are the time to make changes that will force users to work to update their project. Instead, they seems to be large point releases, and you just heavy around all the dead and crippled weight.

 

Yes please! Unity has become a jack of all trades over the years. Refactoring could solve many of its stability issues and increase efficiency in the long term.

Aras has blogged about this very topic. Tho it only concerns one area (rendering), I presume the same applies for the entire engine...

http://aras-p.info/blog/2015/04/01/optimizing-unity-renderer-1-intro/

Somewhat disappointed to read that the UT team hadn't considered this a greater priority in the past?!? Yikes.

 

There was a chunk of major refactoring going into 5.0. The entire engine was broken into discrete modules.

Sure the job might not be complete yet. But a game engine that's complete is a game engine that's about to die.

 

This isn't really the refactoring I'm talking about. This is more like putting putty on the cracks and painting over it.

A complete overview and refactoring of the entire code base and structure of the engine. Which would include redoing some of the core structure and even fundamentals.

This was the blog that really got to me to make this thread. It showed in my eyes, how some of the core areas of Unity had long gone unmanaged and neglected under What seems to be along the lines of the "if it works, don't fix it" policy.

 

What do you consider major bugs?

 

@landon91235, could you explain what you mean with refactoring? From my point of view you are mixing lots of aspects into this.

 

A modern engine doesn't ever receive a full refactor (suspect you mean rewrite mixed in as well). Consider the evolution of the COD engine? It began as Quake3 and there is still code from it in there.

Consider UE4? There is still tonnes of UE3.

Unity 5? how about networking, physics, audio, threading jobs system, enlighten.... to get started.



There is no such thing as a complete rewrite at these scales. The engine is divided up so complete rewrites do not make sense. Half the time you are going to write exactly the same code again.

Unity's been completely refactored in different places. Whole systems have been ripped out and replaced, and this is ongoing. It just doesn't happen at the flick of a switch, it's a gradual progression.... so that you can use it now instead of in 2020.

 

Unity could have used a lot more refactoring then. Reading on Aras blog, he found some almost decade old rendering code in the core. Hmm, lovely? Lots of refactoring been done in Unity.

Of course the entire engine isn't going to be redone. That's not a refactor. Start a new project file, and in a sane and modern day manner, begin adding the modules back in. Then evaluate the modules each on their own, since they all should now be decoupled. Fix any decade old crap in the modules. Perhaps, gasp.... decouple the code and follow modern standards. Have.....gasp...a layer of abstraction. Gasp...... Fix all of the weird things in the structure of Unity that have been noticed and complained about.

Showstoppers. The reason why Unreal gets the pass on this is because they actually fix them quick enough not to hold your project back.

Fixing structural oddities, issues, optimizing, fixing plain weird S***.

 

While I can't argue much about the depth or degree of refactoring with such statements I always wonder: what about all the other areas of the engine? Just because one stands out that has old code doesn't mean that every aspect remains with such old codebase. Or in other words: you take one aspect and project it as a negative on the whole engine.
I'm asking genuinely as I don't know much about it - is this how it works or can large parts have been refactored while some should recieve refactoring in the near future? Or has it be done for the complete code at once in order to fully work?

 

Why should they touch code that is working? A refactoring takes place when a weakness is found that requires it or if the functionality is modified or extended and in order to do it properly, the code needs to be adjusted more than just a straight integration.
Unity, as hopefully every software company, is constantly refactoring their code.

Indeed with this approach, there tend to be fewer bugs, because the running parts are preserved and are not just reimplemented or refactored for the sake of it. If you have showstopper bugs, it is better in my opinion to talk directly about those and maybe get help from the community about potential workarounds.

 

I never seen any performance issue with Unity neither 4.0+ version or 5.0+. Allot depends on your code structure as well, and your asset. I seen rendering issue with UE3 where texture looks very ugly even with high quality texture.

If you study the process of your game compiled with Unity, you see it doesn't take allot your memory or CPU resources. I cant say the same with UE3 compiled games.

 

I would be curious to know exactly what Showstopper bugs currently exist in Unity. Have you bug-reported them?

 

Sometimes the community can't answer.

I was asking in another thread what changed in occlusion culling algorithm in Unity > 5.0.2 as it became totally inefficient. No one ever replied... The community members can't answer to this as they don't know what's behind the scene.

 

In my case the show stopper was the terrain, which had several authoring and execution flaws. A showstopper can work for other people but simply not be good enough for your own project's demands. In this case we switched to using meshes, which has extended development time by around 6 months, and cost a lot more than several Unity licenses combined in manpower.

This happens frequently with Unity. I roll with it because the other parts of the engine enable quicker development. I'm not sure this will ever be a thing that goes away, as I think game development generally becomes more showstoppery the more unique and/or ambitious you become.

 

http://issuetracker.unity3d.com/issues/sceneview-ui-no-longer-renders-in-the-scene-view

http://issuetracker.unity3d.com/iss...ble-when-sharedassets-file-is-larger-than-2gb

http://issuetracker.unity3d.com/issues/unity-editor-freezes-when-changing-scripts-while-in-play-mode

http://feedback.unity3d.com/suggestions/fbximporter-correct-orientation

http://feedback.unity3d.com/suggestions/serialization-of-polymorphic-dat

http://feedback.unity3d.com/suggestions/change-font-size-in-unity-editor (Using high resolutions here)

http://feedback.unity3d.com/suggestions/support-retina-resolutions-in-th

http://feedback.unity3d.com/forums/unity/suggestions?category=terrain


http://feedback.unity3d.com/suggestions/recalculatetangents

I fixed it for you.

 

If you find a bug, you certainly have to submit a bug report. If that was done, there are sometimes workarounds that others know about. However, when not bug report is submitted, it is unlikely that it will be improved.

 

I have to admit I have not filed a bug report... But could it be called a bug ? Maybe they just changed the algorithm... (And I'm unable to use the new one correctly).
Anyway, submitting my whole project for a bug report could be a pain as my project folder is > 14GB. For now I stick to 5.0.2 and test every new release with the best hopes.

 

There does seem to be a problem. My son has an i7 Asus tablet and had been running Unity happily for the past 6 month at least, since he purchased the computer. Unity 5.1.1 suddenly stopped working, project window refusing to open and crashing, and even opening scenes from the file stopped working. We uninstalled, wiped the computer, did everything we could do, but it didn't work. When new updates came out, we again, uninstalled and in one case wiped again, still crashes. We tried to attach the file to send to file a bug report but Unity crashed and now can't get to the file to try again.

So..he is stuck...can't work on his projects (or my project) and his summer is almost over. I am not telling you this for support or help with the problem (we have posted over and over again in support) but because it seems like something is wrong that simply can't be fixed, even with new releases. We have discussed this with Unity folks, sent them crash and dmp files, and they don't know why it is happening and keep telling us they can't replicate it....yet there are at least a dozen (maybe more) people with the same problem on the forums.

I have used Unity for a while now on Windows 7, no problems, very few crashes. I find it to be very stable and 5 even more so. But if his i7 with a good graphics card can't work with Unity, then there is a problem. More and more people use laptops and more and more people use Windows 8.1. There was even a report of a similar crash using Windows 10, which deflated our hopes of his computer ever working again.

So...do we need to pay another $1000 for a new computer or install Windows 7? lol I agree with you guys, I think Unity needs a nice refresh or something.

 

See my above thread. And how do you bug report without being able to send the report without Unity crashing? I would appreciate any suggestions since it seems our thread on the support forum has slipped down on the list. If it doesn't belong here, you can answer on the support forum. Plenty of people have the same issue.

 

Can't say anything about it, because I don't have that issue.

In Unity 5, everyone can use asset bundles as a workaround.

There are editor scripts to automatically leave play mode when the compilation is started. This might be an easy temporary workaround.

Annoying, but definitely not a showstopper.

That would indeed be nice to have. But a workaround is to use the custom serialization. Also not a show stopper in my opinion.

Very annoying indeed.

The terrain is a tremendous weakness in Unity.

Doesn't take too much math to get this.

 

This has nothing to do with refactoring. Resolving an issue that can't be reproduced is almost impossible. The only thing they can hope for that they get as much information from the people experiencing that in order to find a pattern, that maybe a driver or something else might be the cause for the issue. It is certainly frustrating, but I don't see how this could be related to refactoring.

 

If it worked for you in one version and in the next one you have problems with it, it is at least a regression.

 

Thanks, Dantus. I will keep my mouth shut about stuff I don't understand in the future. Appreciate the heads up.

It is not a driver problem, btw. We are not that ignorant. lol

 

You're most probably right. I'll try to submit a regression report with a small sample scene in the next days.

 

I don't want you to keep your mouth closed and I don't believe you are ignorant at all. I simply don't see how it is related to this thread from a technical point of view. Sorry if it came across as being inappropriate.

 

Actually it can still be a driver problem, and often is with Unity, Teila. It's not your fault, but a fault with a specific driver and the Unity engine. This is still a driver problem and it happens a lot on mobiles/tablets. All Unity can do is have bug reports. If your son is able to send a small scene to Unity that does always crash a specific device or hardware, then they can act on that.

So by this we mean less "you aren't installing drivers properly" and more "the driver is the problem itself". A typical game you buy for example World of Warcraft will contain thousands of lines of code just to deal with difficult and frankly bad drivers which are still very common. Bad driver means the manufacturer made it bad. Not that you installed it upside down.

And they don't intend to make it bad, it's just impossible to predict what a computer manufacturer will choose to put in, what os is used and so on ad infinitum. It's not a solvable problem unless you use Apple, and even then there's problems of a different nature ie API incomplete, or good old human error.

 

The number of threads being created about quality issues and missing critical features should not be taken lightly. I think the fact that we still don't have polymorphic serialization or nested prefabs is a pretty good sign that some serious refactoring needs to be done. Maybe they're working on it now (maybe they're not, I don't know). But Unity 5 would've been a good opportunity for that.

 

Well the only thing I've always questioned is the rate of development, there's something not quite right somewhere. In some cases you have single asset store developers moving much quicker than Unity, hell in some cases I can implement features much quicker than they can.. Then again I don't have 21 platforms to care about, neither do I have 4.5 Million users either so it's not surprising when you think about it.

I did have one idea and I still can't decide if it's a bad one or not, split unity into two and clean out anything un-necessary. So a PC / MAC / Console / Linux all in one and then other teams could work on a IOS / Android / Windows phone / Blackberry etc. version?

 

It was a huge undertaking for Unity to merge all Unity variants into one some years ago. At the end, they still have to maintain all platforms and make things compatible. For users who create games for mobile and desktop, it is without doubt easier, if it is just one Unity.

 

No, years ago they had "Unity" and "Unity iPhone" apps, and it was pretty annoying. It didn't make anything better, actually the opposite.

--Eric

 

Have you tried turning the computer off and then restarting?

 

Why didn't I think of that??

Actually, it turned out to be a conflict with another program we use...something rather crucial to the well being of our family. lol So...now we are stuck without it to use Unity. One must make choices. I have a feeling our family will not be as happy though.

 

Weird. Are you able to simply disable the program while using Unity? Or does it not like the program on the drive? I suggest throwing bug reports at both companies either way.

If you don't mind my asking, what's the name of the application that conflicts with Unity?

 

I sent bug reports to both Unity and Qustodio. Qustodio is a monitoring program we use with our kids. Because they are homeschooled and do their work on the computer, we have set up separate user names for schoolwork to keep them from being distracted. We have used it for years but now suddenly it conflicts with Unity. A number of people have had the same issue with Lavasoft-AdAware and Unity. Removing them solves the problem.

Alex from Unity just posted and said it was a problem with proxies due to the Authentication process, which must have started with 1.1.0. He said it is broken but will be fixed in the future, so I am happy.

It was rather fun to work with my son to solve the problem...educational in its own way I guess. Glad Unity was able to figure it out and I hope it helps others who are having issues.

 

Graphics card? I had a problem years ago, although it was desktop pc. The graphics card (which was a 5870 from memory) would pretty much just crash Unity and often take the OS with it. I know that probably doesnt help you, but something to look into I guess..

 

See, my problem with is that it won't really happen until the next major release, because Unity is sooooooooo reluctant to make any change to anything, citing issues with the community apparently being so stupid to not be able to handle a small API update. At least that's the idea I get from Unity's blogs. And backwards compatibility is UT's bible. Screw backwards compatibility and throw all the old S*** out the trunk. The webplayer(Which has been a major reason for keeping outdated practices around for ages now) should be able to load the needed runtime for the game dynamically.

 

They do break backwards compatibility with the major updates. They did with Unity 5.0, same for Unity 4.0. They specifically take the opportunity of major updates to do that, since it rarely happens with the point updates.

--Eric

 

That was the first thing we checked. As I said above, it is a Unity issue according to Alex and will be fixed soon. It was nothing we did or nothing about our computers.

 

You are definetly confusing the difference between a shipstopper, workflow bug and a feature not implemented yet. A shipstopper is a bug that is fairly self explanatory; you really can not ship your game at all because of it. Most of what you have linked are either desires (no retina editor, better terrain system (we are working on both)) or workflow issues that either could be straightened or just require a bit of a work-around.

 

The "Make AAA Quality GTA4 mixed with Skyrim mixed with Warcraft MMO" button seems to have gone missing. :/

That is insanity. I hope that's not exactly the approach you take at work because right from the start you've blown away all version history and started fresh with a new project.

 

Oh yes, compare me not being able to use a retina MacBook without botching the entire native resolution up, with complaining about me being a lazy idiot. Thanks.

Not insanity, the whole point is to start fresh. We import the old files into the project all with the prefix "old_". We like to take our time and not release S***ty software.

 

I consider anything that makes me miss deadlines at my work to be a showstopper. Having to fix the shared assets issue being too large, took us months to split up all of our scenes and have it stream perfectly. Thanks.

Treating these bugs like little annoyances are the reason they never go away. You know what else took a while? Having to write custom editors for nearly everything, because the regular inspector serialization needs some serious work.

Oh, also. I haven't mentioned the daily, multiple, editor crashes. Nothing in the Unity log, and so frequent that I just don't report them. Before everyone jumps on that, stop. I can't report a bug without repo steps and nothing bonked in the project and no log. Because then I'll be told my bug was useless by Unity.

 

What? If you're referring to my first bit that was in response to Andy, not you.

Still not necessarily a best practice. This is what branching strategies are for. Create a branch, delete everything and start fresh there, build it out and merge it back in when you're ready. Then you still have a clean starting base but retain your original history which is very important.

And I have to pick on your old_ practice a bit. Case in point, I developed a fairly large web application for a client about 8 years ago when working for another employer. Over the years since I left that employer other developers have continued to work on that application and it's an absolute mess. There are _old folders and _dev folders. Copies of the site within the site. Now the client has gotten so frustrated that they contacted me through my blog and asked me to clean it back up.

 

We do it in a separate branch, but we rename all the files into "_old" so it's clear what has been refactored, and what hasn't. And for ease of reference. Sorry for the ambiguous description originally.

 

Man Landon, if they just had you on board they could probably get this whole thing done in a couple of days!

 

Always enjoy the sarcasm.

 

But there's a huge number of influences to that, no one thing in one piece of software.

 

Wonderful to hear, but I still think it could do wonders of after the next deadline to have everyone drop everything and just come together to work on the structure like you do for a week. A week is enough to make small changes or plans, but not enough to tackle anything that could go wrong and take up over a week. So I think developers are scared of making larger changes because if they can't get it all done in a week, it sits on a forgotten branch for a month, and is probably very hard to come back to. But overall, it's great to hear. Thanks.