Overwhelmed by the API, need some assistance in understanding

TLDR - I'm having a hard time understanding the API. Experimentation usually results in little to no real understanding of what's going on sometimes.

Hello, I'm aware of the typical answers to my question: Just do the tutorials.

My problem is:

I love coding. I love playing with what I can do in coding. I just get into a problem when I can't really understand what everything in the API means.

I want to understand the API. Some of the API doesn't have any example attached to it to explain how to implement the code at all. Or what it should look like when you use it successfully.

I'm not bashing the developers of Unity, I hope that's not how that this post sounds. I'm honestly bashing myself for not being able to understand this API.​

To be honest, not being able to understand this stuff has been a problem for me for about a year now. And it's humiliating and causes me a great deal of anxiety. I'm in school to be a Game Designer and I'm one of the few good coders in the school. But it's only because I learned using things like Code Academy. I learned C# and Javascript alone. And the Unity classes at my college are basic tutorials without an explanation why anything works at all.

I might be being too hard on myself.

 

Yes, you're probably being too hard on yourself. Keep making stuff. Understanding will come through using the APIs in various ways over time — either slowly, or perhaps in occasional "a-ha!" moments.

 

Give me an example of what is hard to understand and explain what you don't get. There might be a key thing you are missing in your examination of the API or that you haven't learned something to piece it all together.

 

I really appreciate any and all feedback!

when I started working on mobile development I thought I'd dig through the API. I dug around for touch inputs and they were essentially distractions because they didn't cover how to make touch controls work. So I went to the unity manual and touchscreen controls aren't covered in the Android part at all. And a few weeks into my frustration I found the tools in the unity asset store and they didn't look like anything I'd ever seen before.

I figured there was either a huge gap in my understanding of Unity or a gap in my understanding of how to code.

BTW, you can see what I saw by going to the TOUCH part of the classes within UnityEngine in the unity script reference. And the Android section in the user manual, that sections location is made plain in the contents section.

 

I think I see part of your problem. I think it's how you think APIs work. APIs don't give you essentially "features" like touch controls. It gives you the bare bones to make a touch control system, like sensitivity and where they touched the screen. You then have to take those inputs that the API provide to you and make the touch control. If they touch the screen here, do this. If this amount of pressure is applied, do this. They provide the input more or less and you code the output. You can think of it as the hardware portion of the software almost. It provides interactions for you to use and access that let you add the custom features that you want.

I've never looked at the Touch class or done any mobile development but instantly I read the description and functionality it provides which I assume you did. I saw that it was all variables so then I realized that Touch was a class that holds data. it doesn't provide functionality. It defines a touch on the screen. I then noticed that the text mentioned, Input.GetTouch (https://docs.unity3d.com/ScriptReference/Input.GetTouch.html) which happens to return the Touch class. That method provides an example of how to use it You can then dig further and further and figure out how to get that data and how to use it and when.
I assume to implement touchscreen controls it would extend off of some Input class and override it's methods to handle the input.

Did you come to the same conclusions and get stuck at this point or before?


PS. A lot part of coding is spent googling. If you likely ask anyone, they will say the same thing. If you don't know something - google it and try to get the basic understanding that will let you expand your knowledge and let you have the freedom to use that understanding as you see fit.

 

The API can be challenging to get into without a frame of reference.

Here are the key bits you really need.

• GameObject. A GameObject is a container for other components. Pretty much every in game entity is a GameObject. The API for GameObject is about getting components. Its also where you create and destroy things.
• Transform. Every GameObject has exactly one Transform. Transform deals with position, rotation, scale and parenting of an object. Anything to do with the arrangement in 3D space belongs on Transform
• Component/MonoBehaviour. This is where most of the action happens. Components define how a GameObject behaves. MonoBehaviours are Components that allow you to access all of the Unity hooks.

Get those three down, and that's most of the API that you need on a day to day basis. Everything else you can investigate as and when you need it.

 

Yep, I think @juicyz has the right of it. The touch classes in Unity are everything you need — where the screen was touched. You say "they were essentially distractions because they didn't cover how to make touch controls work" but I don't know what that means. There are no "touch controls" in Unity — there are touch inputs, which you can use to make "controls" however you imagine them.

 

...Oh, and this, by the way, probably is the correct answer to your problem. It's typical because it works.

If, for example, you are confused about how to use the touch APIs, then go through some Unity touch tutorials and I bet you will understand much better.