Unity Has Frustrated Me Again

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?

 

You should check out how @GarBenjamin works in Unity:
https://forum.unity3d.com/threads/h...ops-in-unity-me-and-my-unorthodox-way.413419/

 

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.

--Eric

 

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.

 

I agree. That is why I wondered in my first comment if I should ignore the inspector completely and just concentrate on writing code.

 

I wouldn't say ignore it completely; I use it quite a bit. Just not for everything.

--Eric

 

I'll consider that. I'll have to change all my 'scriptable object dbs' to xml, but that may be workable. Testing will be more painful.

 

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.

 

Fixed that for ya.

 

Hardcore, hardline power post that crushes dreams and creates gallows for kittens.

 

We overcome them. Here are two solutions for dictionaries in the inspector. One is paid and one is free.

https://www.assetstore.unity3d.com/en/#!/content/38241
https://forum.unity3d.com/threads/f...acted-from-system-collections-generic.335797/

 

Too much? Probably a sign I need to sign off for a while.

 

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.

 

The beauty of Unity is how easily extensible is. 99% of the time looking on google you can already find some code snippet to solve an issue and the rest of the time it's easy to write one .
The real rage starts when:
1-Things aren't documented.
2-Things aren't exposed cause Unity decide its users are too stupid to make decisions on their own.

Luckily the last two are always less common lately.

 

I didn't think it was too much. You're right, if someone is giving up on projects for want of something that is in fact easily solved then what's going to happen when they run into something that's truly challenging?

I totally understand that it's frustrating when you need workarounds for your workarounds, and I also need to step back and rethink things when that happens. That said, I think the core of the issue lies here:

To me, this sounds like there's an attitude of "one right way" behind the frustration. Unity doesn't do things in a certain way, so it's "wrong" even though it's still more than capable of getting the job done differently.

 

I like Unity because it makes almost no assumptions about how you work. I have projects made entirely in Visual Studio that have a completely blank scene and I have projects I more or less assemble inside the Editor. I really enjoyed making games in XNA, but I think I would have struggled with a lot of things if I went back to something like XNA now because the things I make in Unity now are much more complex than the things I used to make in XNA.

In general though I try to stay away from the Inspector and anything else where the things I do are not stored in code. The main reason I do this is because I feel like it's "volatile" to use the Inspector and similar Editor features. I may just be paranoid, but when things are stored in code it's like it's written in stone, it's never going to change unless I change it, but when I put things into the Inspector or use animation events or anything like that, first of all I lose track of where I keep things, but I also feel like any version upgrade, patch or hiccup with Unity could wipe all my work.

Just recently I got an error I've never seen before saying something about too many vertical layouts or something when collapsing a component (I just clicked the little arrow to hide it's properties) on a prefab. The Inspector went completely blank and that error was spammed into the console every frame. I had to delete the entire prefab and remake it again to fix it and I still don't know what caused it. This could never happen with code.

And regarding animation events, I'm currently doing some work where they would be a perfect fit because I need things to happen at specific times in animations, but I didn't like the interface for adding/editing them at all. There was no way for me to see where I had an animation event without clicking on every single animation in my project (unless I'm completely mistaken). With code I have everything available to me at any time through just searching the code. So in the end I ended up writing code that queries the animator to see what clip is playing and how far into a particular clip it is to accomplish the same thing. Even though it's the completely opposite approach to how I feel this should have been done, I still prefer it, because it's much easier to keep track of and it feels more "solid", even though it probably isn't.

But my point is, I guess, that I like the fact that Unity makes it easy for me to do it both ways.

 

Or you can just make a multiline string in the inspector and put a json(or any string) formated db inside it.
Or maybe you can just put the db in a text file and read it from the code, I usually go this way...

This I agree

 

Was what I wrote grammatically incorrect, or are you hinting at the fact that he's trying to stay "out of" the Unity Editor and stick with the IDE?

 

I deal with it by not knowing any of those things you mentioned exist. It works out great!

 

When I see complaints like this, I tend to feel they're a side-effect of the "look how easy Unity is" marketing spin in the beginner and intermediate tutorials. Which isn't to say that spin is a bad thing, but the tutorials give the beginner the impression that the Editor and Inspector are the "correct" way to build your game and it seems to take beginners quite awhile to realize how much flexibility is really open to them. (I suppose this is sort of re-stating comments already made by @aer0ace and @Eric5h5.)

I've only been using Unity actively, regularly for 13 months. My original efforts were tiny scripts with lots of junk in the editor. These days there is almost nothing in the hierarchy.

I would also like to thank the OP for reminding me that the miserable creation that is RPG exists. I had blissfully blocked it from my thoughts for decades prior to this thread. Maybe the first Unity tutorial should add the intro, "If you have been programming for 20 years or more, start by reading the API documentation instead."

 

Even if beginners look for a more code-centric way to develop, there are just too few learning resources to work with. This was my first ever thread on this forum (didn't get any replies at all):

I've since given up on doing the code only thing, and more or less use the more common approach with prefabs and lots of manually wiring things together.

 

I think it makes sense for certain types of games, but I agree it's a little surprising Unity doesn't provide any pure-code guidance or examples at all. But as an example, I wouldn't want to try to design levels like this (cribbed from this Unite video) in a non-GUI way. I suppose I've never tried this type of game, though, so maybe I'm confusing artistic complexity with structural complexity when I look at this.

 

I want to voice something about the way we handle things here on the Unity General boards.

Many times when a person comes here to complain about Unity, some harsh things get said to them. I understand completely with where @BoredMormon is coming from though I think it was a bit harsh. If the OP in these situations (not this one) appears to be trolling then have at em' I say but other than that I think those having trouble with Unity ought to get some slack.

But as some have said if you've been at it for 30 years, how are these small workarounds such a problem? In your career you have probably written tens of thousands of lines of code. How are ten-ish lines a problem?

I mean if you're so impassioned about a project then how can you let small workarounds stop you? I've been at this for two years. I've programmed on and off since high school but there were times when I was just learning programming and working with an IDE, I spent like a week just getting just one thing working. It was very frustrating and time consuming but I did not let that stop me.

 

Yeah - from reading his detailed thread he pretty much sets everything up so he can stay out of the editor as much as possible.

 

it sounds like you want a reason for quitting the project and these little things are just an excuse you need to justify it.

 

I won't respond after this post, since it is just a bash me for not being as smart as you thread. However, the ten lines of code wouldn't be problem if it didn't create additional headaches and work arounds. In my long life as a programmer I've had to make many concessions to fit a framework but none have frustrated as much as Unity. Maybe it is because I like Unity quite a lot and just want to move forward and make progress. Instead, I have to search for many hours trying to find solutions for things that should be trivial. Currently? PropertyDrawer property parm doesn't represent the object being drawn, but instead represents the root object (in its serializedObject.targetObject value). Solutions exist, but I haven't found one that works consistently. If I attribute my drawer to a specific type it would make since for the property to represent that type.

One final comment, if the community accepts the kind of responses to questions that I see then the reputation will become that noobs trying to learn unity had best not ask for help unless they want to be insulted. I've seen this before, mainly in earlier linux forums. Ok...please continue insults.

 

Generally we are a friendly bunch, although have our moments.. Whilst it might not of come across the right way they are right, you only have a limited set of options. Use one of the three major engines (Unity, Unreal, CryEngine) or build your own framework and then it can be whatever you want it to be..

There's pro's / con's to all of it, there's not a perfect solution out there by far.. But end of the day it doesn't stop people making decent games. You just gotta roll up your sleeve's and / or find alternatives, like in UE you say BP's are awkward? Whilst from that statement there's not enough info to know why, there are other alternatives like SKOOKUM (scripting language) and C++ is relatively simple for game logic. But whilst it's far more logical and fully featured than Unity, it is also massively more difficult with it's own slurry of issues which you'll spend a lot of time delving into source code.

Cliche as it is, when you're given lemon's make lemonade (or just eat the lemons).. I believe one of the biggest issues I see (especially with experienced developers) is they know it should be done X way, so instead of rolling along they fight against it..

 

Note to self: Never piss off an angry person with lemons..

 

a.k.a. "When life gives you lemons, throw lemons."

 

I smell a game called Citrus Wars coming out of this thread.. Well looks like we really did save the day... Awesome.

 

Yeah, I guess that would make a good tagline.

<Black Screen>
When Life Gives You Lemons
<Gameplay footage with the caption "Actual Gameplay Footage">
Throw Lemons
<Title Drop>
Citrus Wars
Rate E for Everyone
PC, Mac, Linux, XBox One, PS4, WiiU, iOS, Android

 

Note that making your own engine is not "perfect" in any way. C++ is not a perfect language. DX/OpenGL/Vulkan are not perfect APIs. All of them have their own quirks which you have to get used to. You will be simply working with a different set of limitations and you will have to do a MOUNTAIN of work to make a decent engine which is remotely competitive with Unity.

 

I just think the response was reactionary and perhaps an assumption that he's not trying hard enough. Of course I'm assuming your reacting and he's trying, but then again, i'm responding and reacting.. wait, wtf am i'm doing responding.

 

It kinda seems you want to do things a specific way (perhaps what you're used to in your career as a Java developer?) which might not be the best way in Unity, and so you're fighting the tool most of the time. I know someone who's also a professional Java developer and a damn good one, but got pretty frustrated with game programming. It's just a different beast than business software and things like that and approaching it exactly the same way usually doesn't go that well.

I don't have any specific advice, except maybe try rethinking your approach so you'd be working with the tool instead of against it and therefore won't need to find workarounds upon workarounds for everything.

 

I said some things in solidarity (specifically an appeal to other users to be bit less harsh). But I think things are headed south when someone begins a comment with something like "I won't respond after this post", because that tells me they want to take a snipe at someone while acting as if any return shots won't be heard. Its quite an immature thing to do. Words can be harsh, especially when taken out of spoken context, but nothing short of complete ignorance is going to soften the blow of the truth.

The truth is these workarounds are viable, they may be inconvenient but your job as a software dev is to solve problems. Not the easy ones either. You should understand this being in the biz for 30 years. If you can't handle the truth at this point I don't know what to tell you. Pretty much everything the OP has listed as his reasons are excuses. "I don't want to try workarounds because they're inconvenient". Imagine if I told my boss at my old job "I don't want to scrub the floor today its too hard!". That would most certainly not fly.

TBPH OP I said nothing about "new users" in my post. I said some people get a harsh response. I'm beginning to wonder if anything I said was warranted.

If I had a dollar for every time someone wasn't nice to me on the internet. Jeez. I'd be so rich!

Claims of this community being snobbish or whatever are unfounded, and unlikely to happen in the future. Most of us are pretty nice, a cool crowd. Just act like a mature person and things will be a-ok.

 

Pretty much the only time I see people here being harsh and maybe somewhat offensive is when there's a thread complaining about something but it looks like the OP hasn't really put in the work themselves.

 

not sure where this one come from or where did you get this idea.

Unity does require a change in thinking. If you're experienced you might be tempted to start making class hierarchies, etc. Unity works better when you break things into small completely isolated tasks and design the whole system as if you were making an army of swarm bots. It takes a bit of time for "Component architecture" to click. And there's nothing wrong with that.

I think you're confusing this forum with stackoverflow.

 

Do you know what else they didn't do? They didn't come here and ask for assistance. Their account is almost three years old and in that span of time the only thread they created was this complaint thread. From the contents of their last post I have the feeling they're completely unwilling to accept assistance with anything and firmly believe only themselves to be correct.

 

Look as easy as it is to work around, Unity inspector COULD be a lot better. Come on people it's a legitimate grievance.

 

There are legitimate ways to approach giving feedback to the Unity developers but a complaint thread is simply not one of them in my opinion. The complaints by themselves though are not the main reason he is getting this degree of flak from the community. He's getting it because his solution was to simply give up and blame Unity.

 

Not going anywhere productive.