Hello,
I wrote this 3 months ago and just read-proof it today.
So I share it now, maybe some people will find it interesting to see all the issues I fought with while building my game with Unity… 
The Fall of the Dungeon Guardians | Technical Post Mortem : Building a game with Unity3D Engine
A tough Boss !
Ok, I’m still not ready to write a full post-mortem, but after seeing this thread “Unity is broken” – What are people referring to? , it made me want to write a list of all the technical issues I got creating Dungeon Guardians, most of them being tightly tied to using Unity3D (real name = Unity Engine ; Domain name = Unity3D.com 
).
Before to go further, I think I need to make this very clear : Unity is a great engine and without it Dungeon Guardians would either not exist at all, or look way less good than it does ; and having used it made me save a lot more time than it made me lose.
Thus said, I have built my game engine using the minimal stuff possible from Unity, and every part I used had a least one really annoying issue, if not several.
Let’s start with a painful task that almost no one can do without : debugging
Conditional Break in the MonoDevelop Debugger never worked. It makes debugging much tedious as I had to add some lines of code and recompile everything every time I need to check a special case. Later on I switched to Visual Studio and its debugger which was technically working, but often terribly slowly, so not much more usable actually. Though this last point is likely the wrong of C#, not Unity.
To stay with the debugger, pressing the “Play” button while the Debugger is attached makes Unity stall for 20-30 seconds instead of starting in less than 2 seconds. After that, it executes normally.
Moreover, Live recompiling (ie: changing the C# scripts with the game running) isn’t practical and thus I never got it working. This is the thing I miss the most from developing in C++.
Let’s continue with some isolated issues
Physics engine handles really badly small fast moving objects ; I had to use & tune this to fix the issue : http://wiki.unity3d.com/index.php?title=DontGoThroughThings .
The FPS counter in the stats doesn’t actually count the FPS ; it estimates them in the most idiotic possible way and thus is completely useless and misleading.
There’s no built-in decal shader, nor shadow-receiving transparent shader ; so for putting spider webs on my wall, I had to grab an user-made shader .
GL rendering stops to work in OnGUI after an alt-tab (ie: switching to another application), but it works again after a couple of alt-enter (ie: alternating between fullscreen & windowed mode). There’s no fix nor bypass for that. This is one of the rare bugs left in the game.
There’s no documentation on how to handle a lot of sound sources. The sound parameters would let you think it’s automatically handled, but it isn’t. Fortunately, I have been able to just cull the sound sources with my custom-made occlusion system for the rendering.
And now for the big part : animation & importation
Legacy Animation system was duplicating the animation clips assigned at realtime, instead of referencing them, which leads to a gargantuan amount of wasted memory (more than 1GB!). I had to swap to the new Mecanim animation system which was severely feature limited. Fortunately, the possibility to change the speed of the animation per layer came with Unity 5.1. Unfortunately, this version made the legacy immediate mode GUI way too bright in editor more (but luckily not for the built game). 5.2 fixed that issue but destroyed the animation system, making everything jerking around when using multi-layers. 5.2.1 fixed that but not completely, and 5.2.2 didn’t change anything, thus final version of Dungeon Guardians is built with 5.1.3p3 and I kept on burning my eyes every time I launched the game in editor mode (which was all the time till recently).
Disabling & re-enabling the Mecanim component of an object removes the current playing animation clip instead of only pausing it ; ie: it completely empties and then resets the internal state of the animation. It brought me a lot of issues and it has been very hard to figure out a solution. But the hardest past has been to understand that behavior, because it is not documented. I have requested more than 1 year ago to be added to the documentation, and as of today, it’s still not there .
Still in the animation department, it is not possible to select multiple animation clips and change their import options all at once. You have to do it for each clip, which can have near of 10 parameters, 1 by 1 ! There are hundred of animations in Dungeon Guardians, I lost hours if not days doing a stupid grunt work that should have taken less than a hour…!
To go with the resource management, the texture re-sizing on importation is done with a very simple algorithm which has the double-perk of being both too aliased and losing contrast. The 1st one happens when resizing to a much smaller size and the 2nd one when dividing the size by only 2 or 4. Using “Bucibic Sharper” with Photoshop gives a much better result. It means I had to do an awful lot of grunt work to get the best of all the HD textures I had, instead of relying on the built-in scaler.
And now, the true Unity specialty : Half-cooked Features
It’s really the plague of Unity. They’re in a race to always add more & more features, while regularly never really finishing the existing ones and letting them with blatant missing possibilities.
The most patent example is the “new” animation system Mecamin (it was released with Unity 4 in July 2013), as explained above, which needed nearly 2 years to get a layer & clip based speed setting. It’s something that a lot of games need. Think for example at an adaptable run speed animation for the legs and a defined speed for a fire animation for the torso.
In the same vein, the Unity Input doesn’t allow to be set in-game. It’s even not possible to know what key is assigned to an input ! Which means any developer wanting to offer in-game configurable input (instead of the default Unity launcher setup) has to redo the Input from the ground up, as I did for DG !
In bonus, the text input field doesn’t work on Linux. It may or may have not be fixed in latest version of Unity, but as I couldn’t use it (see above), it meant I had to re-write my own (which doesn’t support Ctrl+V & stuff like that) : you’d be surprised at how much people actually want to enter the name of their choice for their character in an RPG, even if they use Linux…!
The “new” particle system, Shuriken, released in February 2012 can’t use a skinned mesh (ie: an enemy) as source for its particles ! It has been fixed in Unity 5.3, released at end of December, nearly 4 years later. For DG, I had to use an external add-on (and yup, I had to paid for it).
Conclusion
I skipped a good bunch of issues which were also annoying but have been fixed before releasing the game, and that didn’t require extra work on my part before that. I also skipped a dozen of little issues which were more or less trivial to fix once found.
I also had several undocumented changes of behaviors, some really strange.
All in all, I feel lucky I had a version that let me built the full game without any major bugs nor important missing features, but I’d have liked to make it without the GL render & Text Input on Linux issues. Maybe someday I’ll try to update to Unity 5.3 and check if it doesn’t break anymore my animations, without breaking some other new stuff.
For now, I think I’ll be still using Unity for my future games, although for the very next one, I’ll still use my old custom framework so I’ll be able to use my old game engine without porting it to C# right away.
And to end on a positive note on Unity, it has been really fast & pleasant to be able to build all versions (Windows / Mac / Linux all for Steam and for Mana Games, and the Mac AppStore one), while it was really cumbersome with my old homemade framework.
).
… as the progress on improving or complementing those features with other needed features since they’ve been out has been slow, though I’ve not really bothered with unet much as I was waiting to see phase2 and still waiting.