Hacker News new | comments | show | ask | jobs | submit login

Lots of impressive headline features. DirectX 11, detailed animation system, Linux support.

The trouble is, these come at the expense of the basics. Not so impressive is that the only supported method for sharing code between projects is copy and paste.

The engine is six years old. I'm not kidding.

Unfortunately, frustrations like that are common. I adopted Unity expecting to be there for the next few years at least; however my experience has been lukewarm.

It's a shame, because it could be a fantastic engine if they'd concentrate on polishing what they've got. But I don't get the impression that's the roadmap.


On the other hand, Unity has implemented some basics, which are a real time sink in other engines, outstandingly well.

Lets compare the coding workflow in Unreal Engine 3 and Unity 3:

In UE3 you play the game, find something you want to change. So you shutdown the Game/Editor and go to the code. You code in some immature language called UnrealScript (I think there is a complicated way to use C++ too). Then you compile. Then you startup the Game/Editor again (this is slow).

In Unity you find something you want to change. Alt-Tab to your Code Editor. Change C#/Javascript code. Alt-Tab back to the game, recompiling the code and loading it into the currently running game is automatic and takes about 1-2 seconds.

Also the engine APIs are one of the best software designs I've seen in a long time.

On the other, other hand, if you don't use their serialization system (I prefer to stick with json), automatic reloading of the code causes a hard crash as your objects have been incorrectly reloaded.

And, naturally, there's no way to turn it off. Strictly speaking there is but it requires restart of Unity, not just the game, to reload code. Which is basically the UE3 workflow you describe.

You're right though; there are quite a lot of good parts of Unity - which is why I'm sticking around for now.

But I stand by my assertion that their focus on headline features is troubling.

Unreal Engine 4 will fix the workflow, though.


And by JavaScript you mean UnityScript

Our teams share code by not coding in Unity projects. All the assemblies are added as plugins with a build script. The games have very little code actually accessible from within Unity. You lose the nice edit and continue, but for a big project with a lot of assets the Unity IDE explodes under pressure anyway.

Interesting. Is this process - plugin based game development in Unity - documented anywhere? I assume you lose browser support, are there other major drawbacks?

You don't lose browser support, since what you're dropping into the project is still .NET assemblies (they just happen to have DLL extension). So they aren't any different than what would Unity compile your C#/JS/Boo scripts into.

The main reason I think it's really dumb for Unity to put more focus on high end features instead of polishing and improving what they have is because developers who want those high end features are probably using Unreal or UDK.

The way I see it, Unity's primary market are hobbyist developers or professional developers who are making casual / indie / 2d games, and usually those games are on Mobile. Those types of people want less headaches and they want to be able to do common stuff really really easily. They don't really care about the high end features.

Unfortunately, Unity has terrible built in support for 2d art. Unity also zero built in wrappers for common Mobile tasks like In App Purchases.

Jumping through hoops to get your source control setup properly is a huge knock against it as well. This type of thing should just work out of the box.

You can't cut and paste components between game objects. When importing sounds you have to change the import settings on each sound individually because they don't support multi-object editing.

I use Unity professionally as a casual / indie game dev and while it is the best game engine for me, I can't help but think it could be so much better.

Version control on Unity isn't as bad as you describe. Go to Edit > Project Settings > Editor, then set Version Control to Metafiles. If you have a Pro license, also set Asset Serialization Mode to Force Text. The downside is that this litters your project with .meta files, but that lets you work with external version control pretty easily.

Edit: You should also exclude the Library folder from your VCS, because with metafiles enabled the Library is just a local cache.

You're responding to an argument I didn't make. Version control works fine.

The problem is that there is no method to build libraries and share them between multiple projects, since all the code needs to be under the Assets folder of each project. There is no support for classpaths.

If you update the code in one project, you have to copy the file to the other. Or have some equivalent method of doing so outside of Unity.

Prior to Unity 4, people were using symlinks to accomplish this, but Unity 4 disabled them on Windows to match the OS X behavior (this is described in the post I linked).

Sorry about that, I thought by different projects you meant the same project on different machines. Sharing libraries between projects, now that's an interesting problem. I think I'll go have my morning coffee now.

Can you just checkout a subrepo into your assets?

Yes, this is the only way the handle it. Git subrepos make this a hassle though, in our experience. It's the one thing that SVN would do much better.

Have you tried git subtrees? They are so much nicer than git submodules in many ways.


Thanks for the pointer. I've read a few articles thanks you to. It still seems awfully complex and demands very proficient git usage to do even simple operations. I don't think that's suitable.. but I'm curious are you using it with Unity?

Not with Unity. One big advantage is that git subtree has is that not everybody has to be proficient with it, you can designate someone to set it up and to periodically push the subtrees, and everybody else can ignore it.

That's not quite true; they should split their commit so they don't span trees. But it's not a requirement, it just makes things a lot nicer.

This essentially seems like you're ticked off at one feature and everything else is beside the point. If you follow one of the links in this thread:


You'll find that the Unity folk disabled symlinks to avoid thorny edge-cases and are trying to figure out a way to give you what you want, including simply allowing sym links but generating a warning message (and Windows devs are suggesting using a junction link -- no clue what that is).

It seems to me that the best option would be for Unity to expressly support the inclusion of folders outside the project tree in projects.

The engine being "six years old" is somewhat beside the point. Major changes and improvements have been made to the engine have taken place, and in some cases these have been as dramatic as "from scratch" rewrites.

What I'm saying is that after six years, there is still no support for something as basic as classpaths, which I'd consider part of the MVP to be using something like this full time.

It seems you disagree, but many people have popped up in this thread with the same complaint, and workarounds they should not have to be making.

I have no problem with the 3D rendering part of Unity, it's fully featured and works well. Especially for the price tag.

Agreed that age being bad is a nonsense metric. I was saying the opposite - it should indicate polished workflow.

Ticked off at one feature is not an accurate assessment at all. If lack of classpaths were my only problem, I'd be in love with the product.

I don't think it's a bad engine either. I was just expressing my concern for where they're choosing to spend their effort.

If you complain about the lack of polish on existing features on the official forums you just get told to shutup by other users. It's sad.

The workflow I use is to have my library code in a folder outside of the unity project, and add a build target in visual studio that copies the produced dll into various unity asset folders. Definitely not ideal, but it works reasonably well.

And why is 'engine age' a problem again? Unless there are major architecture problems, one should not need to rewrite everything every 4 years.

It actually is normal practice in major game engines to do major rewrites every few years. id Tech 1, 2, 3, 4 etc. for example.

I'm not saying the engine is dated. The renderer is fantastic.

I'm saying that given the age of Unity3D, the basics should be 100% nailed.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact