I’ve been a developer for over 30 years, and I’ve programmed in such frustrating languages as RPG (report program generator…not the good RPG), various and ancient scripting languages (see REXX), and much more.
Over the past year or so I’v been working with Unity to just make some stuff for me. I’ve learned a lot about C#, and being a professional Java developer I can see the good and the bad in both languages much better now.
What has me frustrated, yet again, is how any technical design I come up with seems to lead to the same result: “Unity can’t do that”. Unity can’t render dictionary objects in the inspector, Unity property drawers can’t deal with generic types, Unity can’t use HasSets, and the list goes on. This all results in the same thing, I end up ditching the project in disgust until my old mind forgets the issues and then start another project and hit the same issues.
In any event, I end up spending so much time trying to manipulate the inspector to understand and display properties or writing custom editors that the experience just becomes frustrating and I never make any measurable strides in my game code.
I’ve looked at UE4, but there are some pretty heavy problems there too (such as it runs like garbage on a Mac, and blueprints are awkward).
So, my question is how does everyone deal with the limitations? Should I ignore the inspector completely?
I don’t know, most (all? I’m more of an artist, so I’m not sure) of the things you mentioned are easily worked around, so I really don’t know how you get to:
I mean. I don’t know. But if I were to rephrase what you’re saying a bit, I think you’ll agree that:
“I have this cool project I want to make that I’m really passionate about, but… sadly Unity cannot display Dictionaries in the inspector, so I have no choice but to give up”
Sounds ridiculous, no?
(okay, I’ve exaggerated a bit. But, really, if you’re a developer for that long, you know that finding workarounds for things is an integral part of the process)
That, I think, is my primary point. I HAVE to make workarounds for so much in Unity that I’m spending all my time decomposing how it should be done into how it must be done.
What happened today…dictionary not displayable, ok i guess I’ll make a fake dictionary using what unity understands. Ok, not displaying because I need to make a property drawer to help it out…no sorry you can’t make a property drawer from that class. I’m using this as an example because it is still fresh in my mind. The point is there is so much rework just to get a class to function that I feel like I’m taking tiny baby steps that are barely measurable.
Give up. Go home. If Unity doesn’t make game development easy enough for you, nothing will. Try coming back in another decade when the make an MMO button is finished.
Seriously, the work around for a serialisable dictionary is half a dozen lines of code. If writing out half a dozen lines is blocking you, you don’t have what it takes to be a developer.
Maybe your design is too inspector-heavy to begin with? It kind of sounds like you’re putting all the data in the inspector when that’s not necessarily the most efficient way of handling things, even if Unity had no inspector limitations at all. It does seem a little odd to keep giving up on projects just because of the inspector.
Thanks for your reasoned comment. As I indicated, that is just one example of the constant reworking of known programming practices to fit into the limits of the tool.
That’s the thing with using tools as flexible as Unity. You can use pretty much any workflow you desire, but once you move outside of the norm you must use that flexibility to extend the tools. I wanted to support modding in my project, but Unity doesn’t really provide much to help with that so I had to add that ability myself. As a result, I pretty much just use Unity as an asset database and renderer for this project, which ends up being relatively close to @GarBenjamin 's way.
My point is, either work within the default tool abilities, or learn how to expand it to suit your needs and be willing to do so.
Well, you can write your own inspectors that display dictionaries, you can make dictionary objects serializable using ISerialCallbackReceiver.
In general this functionality is not strictly required to make a game.
No, you shouldn’t. Inspector allows you to quickly type in a new value and experiment. Extend or use supported classes. Avoiding it is not a good idea.
Yes, this is that you should do to a large degree. I admit certain debugging tasks would be a bit easier if the inspector did certain things better, but that is not a show stopper. As a general rule, leave certain class variables exposed as public variables so you can experiment quickly through the inspector, but don’t worry about trying to expose everything through the inspector.
No, but my solution is faster. You just need a quick Google search for “Unity dictionary inspector” and $2.
Joking aside this is needed to be mentioned. The OP is blaming the tools available and while there are legitimate complaints to be made of Unity this is simply not one of them. Their inability to find a solution is the culprit in this situation.
Why is a dictionary necessary? Just how many items are you putting in it in the editor so that you need a dictionary? Or am I a weirdo who thinks that a dictionary is just for the five hundred items I generate at runtime, but not the two items I’m gonna drag in?
The grass isn’t greener anywhere else. You can look, but I guarantee you will run into the same amount of adversity with any other engine.
One of the only major reasons I use the inspector is to initialize some properties so I don’t have to do GameObject.Find in code. That, and scriptable objects. Other than that though, most of the inspecting is in the Visual Studio debugger.
