Time to add one of my own to this list:
I've found using DLL's to be a big pain
It has been said already, but vaguely. The specific issue I had was the Visual studio can use the DLL's, Mono can use the DLL's, but unity runs into errors with them some times. Normally, when unity finds a script/code error, its easy to go to the source of it. I.e. double clicking it takes you to the line of code in Mono for instance. But if it is a DLL, it doesn't express this very well, and double clicking it does nothing. It would be nice if it actually expanded the references, or highlighted the DLL in your assets folder.
Another issue is that Unity doesn't support any cross domain issues out of the box. For instance, I'm using a JSON database with Cloudant.com to manage user accounts (not for live interactive data, but stored data only). The problem is that I connect through HTTPS/SSL. SSL always fails no matter who what website you try. it has no trusted validators for the SSL. I had to write my own security handler for accepting it. Not too tough, but I really don't like the security implications of taking SSL into my own hands. It now leaves my game open to proxy redirects. Not to big of a deal, but I'll want to fix it prior to release.
- Unity has no 2D support is entirely false, from a programmers perspective. It makes sense that in a 3D editor that 2D aspects are not included. I don't expect any 2D object/images/buttons to be persistent (similar to a prior rendering of a 3D model) - I've never really enjoyed WYSIWYG editors for game design, and proffer procedurally constructed environments. I will definitely concede that from a Designer's point of view, that Unity has no 2D support, but if your building a game, and have more skills that what it takes to use game maker, I think you'll be fine with GUI.Draw, and managing you own 2D engine.
- After a discussion with Kylotan, he brought up some significant deficiencies I hadn't thought of. It worked for a game concept I was thinking about at the time, but not much more.
The component-based system doesn't suit everybody. It's hard to use well, because hardly anybody really gets how to make the best use of components yet.
I'll agree that the component based system doesn't suit everyone. Then I realized its just a basic Decorator Pattern
, which I use all the time in my 2D games for fast development and simple management. Once I saw that, I typically start everything from the component and head away from it where I need to. I found it nice, but I've used it before. I would imagine that having it forced on you as a standard for the tool without training could very well be a pain.
Kylotan, on 24 Jan 2013 - 17:00, said:
(Oh, and one more tiny thing that annoys me is that you can't just change one part of a GameObject's position, because you can't modify a Vector3, only replace it. This is only rarely an irritation, but it's an irritation nonetheless. More of a language thing than a Unity thing, but I wish they'd made that a bit cleaner.)
Yeah, that is kind of annoying at times.
I have to disagree here. I'm not seeing an issue with this. Though I'm used to using a transform instead of position when dealing with 3D. I view the position in use of circular/spherical collision detection. (I rely on C# instead of Java, came from an XNA world, then VB.BitBlitting, then QB.pixel/line direct, and of course text, I have java, but not as comfortably)
The issue with the input system isn't the system itself, which in general works fine. It is the fact that you don't have access to the set configuration at run-time. You can make the player use an external "pre-run" dialog that allows them to set the keys/inputs(and also the screen rez and detail settings), but you can't do this at run-time. This also makes in game tutorials difficult because you don't have access to the keys the player has chosen. But even more important than that is that you can't make your own GUI system/options menus to change the control configuration. There exists a thing in the Unity Asset Store that costs $20 I think, that replaces Unity's input system with similar function calls, but allows you to either use a default GUI to set keys, or use your own, all at run-time, and you also get access to which key the player has chosen, which is good for tutorials.
I don't see an issue with this either. I find their current named system for buttons to have been refreshing to see, but it really is just a named collection. Named collections are ok, but it adds a list search every time a button is pressed to see if it is in the named button calls, and a list search for the name/key reference every time the name is used. I tend to expect to lock in keys, or set a static variable somewhere for each key. It can change by config, but that is still faster than the the named list by a factor of [2+ (0.5*Named Command List Count)]
I suppose a lot of the complications everyone has mentioned also stem from backgrounds, particularly Coder vs Designer. With any thing I found not to have an issue with (yet) it seems it is usually a designer/coder/perspective issue. Overall, these have been very helpful for me.
Edited by hpdvs2, 07 February 2013 - 01:39 PM.