I'm just not getting it... and the site isn't helping

Unity Engine
1

I’ve been attempting to learn Unity for over a year now, and every attempt ends in failure. It seems like the learning curve is just too high for me to climb over. It’s not like I don’t understand how to create games… I’ve worked on successful games in the past. I learned to code in a sort of pseudo javascript. I know some basic C++ and I have the “jist” of programming in general. I’ve also had several years experience with 3D and various modeling/rigging/animating applications.

With all that said… I just don’t get Unity.

The tutorials and references just are not helpful to me. I don’t want to look at some 500 line long example. I want to know what things do and why they do it. Dissecting examples has not worked at all for me. I just can’t grasp this whole component based thing… and I really don’t understand the built in variables for Unity and all of that… It took me 3 hours to lock the character’s direction to not look up/down in the 2d Platformer tutorial. 3 hours. That’s just not acceptable… I’ll never finish the games I have planned at that rate. It’s just not coming easy to me and I partly blame myself but I mostly blame the tutorials. There’s just not enough explanation of how things work. I feel like I’m missing some documentation that is explaining everything clearly and everyone else seems to have found it.

But it’s not just scripting… it’s importing 3d models as well. This has been nothing but a nightmare for me. I use Lightwave for basically all of my modeling and animating, and it’s just not playing very nicely with Unity. I’ve had to make posts here in the past with my importing troubles already, and it seems like every new mesh I try to import just finds a new way to break.

First it was Lightwave not exporting the bones properly, so I had to find a work around for that… But now even when I export in a character and the bones are in the right place… the weightmaps don’t work! I just don’t get it. I can’t find a single successful solution to exporting an FBX from lightwave that will work with Unity, and the tutorial on the site does not help me at all, as it’s severely outdated and I don’t use that old version of Lightwave, nor would it be beneficial for me to use outdated software.

The process of getting into Unity is just not a simple one for me. It’s been nothing but a complicated mess and I’d really just love to understand it but I can’t. This isn’t a rant of me giving up or anything… in fact, it’s the opposite. I’m desperately wanting to learn Unity but every time I try I just run into a brick wall. I post this in the hopes that someone out there can either guide me to some better tutorials or like… some sort of overall reference that actually explains what scripts or operations or classes or whatever do… I’ve looked at the Unity Script Reference and it’s nice and all, but it breaks things down so far that it’s all just disconnected to me. I can’t piece anything back together to actually make a script work. Here’s a simple example that just makes my head spin around:

transform.Translate(0, 1, 0);
// is equivalent to
GetComponent(Transform).Translate(0, 1, 0);

Note the case difference between transform and Transform. The former is a variable (lower case), the latter 
is a class or script name (upper case). This case difference lets you to differentiate variables from 
class&script names.

So which do I use? They are both the same? I don’t get it. Why call the function “GetComponent” when it’s getting a “script”? Shouldn’t it be called GetScript? It’s this sort of naming convention that just confuses me even further. Is a script a component? Does a component contain scripts? Is “Transform” a class? A script? A component? All of the above? Where is a list of all the classes built in to Unity? These sort of questions leave me spinning around in circles and I end up nowhere.

If I can’t even learn the basics of scripting and can’t even get a single mesh imported without it being broken or deformed, how can I ever expect to use Unity to build games? :expressionless:

2

Sorry to hear you’re having such a hard time.

I’m learning myself and piecing things together to change them and get what you want can be tough. I did both the 2d and 3d tuts and was blown away at how simple Unity was. If you haven’t I recommend them, I did both in a weekend.

After that I was like ‘YES!, finally an easy game engine…’ (I’ve modded for 10 years on 6 engines and untiy IS the easiest imo).

But then I tried to start from scratch and it was like, damn, what now , scripting? I never could script.

Found a basic scripting tut and it was OK, it helped uderstand some stuff. But still, I couldn’t piece the stuff together.

But then I found this tut, easy to follow and it explains it all pretty well, in very simple everyday terms
http://www.unityscript.com/

The reason I posted is you said you don’t understand what components are, early on in this tut is explains it simply.
It also explains case differences like you posted above.

I’ve just read it (yesterday) and am not to the point of just being able to write a script, but now I understand what parts of a script are, what they are called, what they do and I think it’s going to be much easier now.

As far as lightwave, I don’t know. You might have better luck with Blender, probably more people using it, so more help available.

3

Yes, use whichever you like.

It’s called GetComponent because it Gets a Component. All scripts are Components, but not all Components are scripts. See the code you quoted about GetComponent(Transform). Anything you see in the inspector attached to a GameObject is a Component.

I’m sorry you’re having problems. Just goes to show that people think in different ways…mostly it all seems natural and reasonably simple to me. I’m sure you’ve worked on stuff that would just confuse me. Some people liked this tutorial, which doesn’t have 500 line scripts.

–Eric

4

Thanks for the link. “Scripting Anxiety” sums it up rather well.

As for the importing thing… I’d switch modeling applications but I’m just really knowledgeable in Lightwave and it would be super handy to be able to actually import things properly. I know it’s not entirely up to the Unity team to handle some other company’s software, but if it says that Unity can import from Lightwave, they need to better explain the process, and the limitations… Because I’ve already been reading that there are limitations to what Unity can actually use from the Imported file. I feel like it’s something I’m doing unintentionally wrong on my end because I don’t have a guide that explains it to me in the first place.

It’s definitely frustrating learning everything via trial and error. Which is mainly why I made this thread to begin with. I just grew frustrated to the point of not knowing what else to do. I try to import a simple character and it’s broken, I figure out how to fix it, then it’s broken in another way… etc etc until I’m ripping my hair out because some of this stuff could have been simply stated on the import instructions page and saved me a whole lot of time.

Another issue I have is that I am used to doing all of my 3d mesh’s look in Lightwave… such as materials and whatnot… But then I import it into Unity and I’m given a basic diffuse material to work with… Which means now I need to learn how to script shaders, in order to achieve the look I want, which at my current rate of learning, means I’ll have a shader scripted in about 6 months. :frowning:

5 
transform.Translate(0, 1, 0);
// is equivalent to
GetComponent(Transform).Translate(0, 1, 0);

I would usually prefer the one that involves less typing. There’s more than one way to skin a cat. :slight_smile:

Usually, a Script IS-A Component, in the same way a Ferrari IS-A Car. When you stop at a car rental shop, don’t you usually say “I want to rent a Car” instead of “I want to rent a 2008 Chevrolet Malibu”? These IS-A relationships are called Inheritance in the Object Oriented Programming (OOP) world.

Usually, yes, a Script IS-A Monobehavior, a MonoBehavior IS-A Behavior, and a Behavior IS-A Component. This is one reason I prefer C#. The code always makes it explicit that when you add a script you’re deriving from Monobehavior (or something else), which avoids some of the confusion you’re having now.

See http://unity3d.com/support/documentation/ScriptReference/20_class_hierarchy.html It even shows the hierarchy!

6

They have a pretty good list of shaders pre-built. You may need to import it into your project (when I create a new project that’s one box I always check).

Diffuse is standard, (it’s the most common/best performance), but if you instal the shader pack, then scroll down from diffuse you’ll find…diffuse/normal, diffuse/normal/spec… just pick the one closest to what you want (you probably need to add the maps to the correct slots)

7

See, that’s the kind of information that would be good to have presented to me when learning about components and scripts. But instead it’s all disconnected in a way that my brain just doesn’t piece together.

So you have components that attach to the objects which allow them to do things. So the Transform component lets you use the transformations of an object such as rotation and scale and position. I understand that much. I also understand that you can add your own components (which are scripts).

But I come from a scripting background where you can have more like… main scripts that interact with many different objects. Where would I put these? They wouldn’t go inside the player object, or a level object or something… I wouldn’t really want them attached to an object at all… Unless they have to be?

I think part of my problem is the fact that there are just so many ways to do the same thing… and also the fact that everything is broken up into so many pieces that my mind loses track of what’s what.

I’ve found myself using variables without declaring them first and then the script runs fine, and other times I’ll do this and it won’t recognize the variable and I have to go declare it somewhere… I sort of get lost there as well. I really feel like I could learn this really easily if I had someone tutoring me for a couple weeks. Just a way to say “why do I have to do this” and have someone tell me. It would sink in so much better.

I appreciate any and all tutorials and links that anyone has to give me. Especially any advice on wrapping my head around Unity.

8

You can attach them to an empty game object; anything that runs has to “live” in your scene somewhere. I usually put global control scripts on an object called Manager or similar.

–Eric

9

as far as I understand you need to have a script on a game object of some type for it to work in that level.

So just make a game object (which is nothing physical, just a reference) and call it level, or map components storage, whatever makes sense to you. And place any components the level requires on it. You’ll never see it in the preview/game window. You’ll have to select from hiearchy to modify/add to it.

I suppose if you called a variable, but didn’t declare one you might’ve ‘got lucky’ and used the name of a static variable from another script (static variable can be used by any object in the game no matter if script is attached or not). I think Transform is a prime example. it’s a static variable already defined in the engine, so you never have to make a variable called transform.
The oficial scripting docs would give you info on variables like that (not positive transform is a variable), I think that stuff just takes digging throught the documents, so you gotta know what part of a script you are looking for (ie: variable, function, array).

I think the unity docs are a case of being written by programmers for programmers, where as that unity basics tut I posted above is written by a n00b who figured out scripting- thus it’s easy to understand.

10

That’s because you haven’t visited the link in my post yet. :slight_smile:

It’s good practice to declare all but the most temporary variables, even in languages that don’t requite it. When you declare them, choose meaningful names, set the type, and initialize them when it makes sense.

11

Unfortunately I can’t offer much help with the model import/export issues. The projects I’ve worked on in Unity have all had fairly simple requirements as far as model support goes, but I’ve certainly run into some idiosyncrasies in that area, and I know others have too. It might partially be Unity, but I think it’s partially just that importing/exporting models is complicated and problematic in general due to the wide range of formats and conventions used. It’s clear though that people do manage to get models imported and working in Unity, so presumably there are solutions to whatever problems you’re running into.

Regarding the problems understanding Unity’s architecture, I’d encourage you not to give up, but rather to step back and maybe take another run at it. Unity obviously works for a lot of people, and personally I found it easy and intuitive right out of the box. However, you’re not the first person to express confusion about it; it does seem that in some cases Unity’s architecture just doesn’t ‘gel’ for some people (I’m not sure why that is, but everyone is different).

The example is just showing that the ‘transform’ property is essentially a shortcut for acquiring a reference to the transform component.

As for which to use, it’s more common to use the ‘transform’ property. I always assumed there was no significant cost associated with this, and that a reference to the transform component was simply cached and returned. But, based on what I’ve read on the forums at least, it appears that may not be true (some people recommend caching a local reference yourself and using that instead).

In any case, I wouldn’t concern yourself with optimizations of that sort unless you actually see a performance problem. So in short, just use the ‘transform’ property, as it’s the most direct way of accessing the transform component.

You probably already know this, but the bit about case (capitalized vs. not capitalized) is just a convention, and doesn’t have any particular technical significance.

A script is a component (which I’ll try to clarify in a bit).

Yes.

Not really.

Yes.

No.

Yes.

Two out of three :slight_smile:

Here.

I don’t know how much I can offer that you haven’t been exposed to elsewhere, but I’ll try to summarize things a bit.

As you probably know, everything that you’d consider part of a game’s ‘main loop’ happens under the hood in Unity; that’s not something you have direct access to or need to code yourself.

As far as the developer is concerned, the ‘top-level’ object of concern in Unity is the ‘game object’; these are what you see listed in the hierarchy pane in your project.

Game objects by themselves are (almost) completely generic; they’re just ‘empty containers’, so to speak.

Specifically, a game object is a container for components. That’s it, really - you can just think of a game object as a ‘bag of components’, into which you can throw whatever you want. What components you decide to throw in determine how the game object looks, behaves, functions, etc.

The only component that every game object has by default is a transform component. Although this isn’t necessarily an architectural requirement, it’s how Unity is designed, so you can just accept that there will always be a transform component associated with every game object. When you select a game object, the transform component will always show up first in the inspector (at the very top).

Game objects can be made children of other game objects, which facilitates a typical ‘scene graph’ hierarchy. How this works should be fairly familiar to anyone who’s worked with a scene graph in any other engine or in their own code.

So, now you have an (otherwise) empty game object with a transform component. From there, you can add any other components you want to define how the game object looks and behaves.

Unity itself includes a wide variety of components that handle a variety of common tasks. There are components for mesh rendering, rigid body simulation, audio playback and effects, cameras, collision detection, etc., etc. The more you use Unity the more familiar with these components you’ll become, but of course there’s always the documentation, the various tutorials that are available, and the forums if you need help with anything in particular.

Finally, you can also create custom components; this is where your own code will go, generally speaking, and is (more or less) how you make your game. Custom components derive from MonoBehaviour (implicitly in the case of UnityScript, I believe).

If you look at the docs for MonoBehaviour, you’ll see that there are many functions that Unity invokes automatically in response to certain events. The way these functions are invoked is actually via reflection; they’re not overrides (that is, they’re not polymorphic), but are rather just functions that you can include in your custom class if you so choose. The functions that you do choose to include will be invoked at the appropriate time(s).

When people use the term ‘script’, they usually mean a custom component derived from MonoBehaviour. In other words, a script is a component, but a component isn’t necessarily a script.

Beyond that, coding in Unity is basically just a matter of interacting with the API, just as you would for any other library or engine. As far as that goes, the documentation should give you the info you need (and if it doesn’t, you can always ask here).

12

As Ostagar pointed out, the Scripting reference page shows a hierarchical list of object inheritance and, if you have any doubt about a particular class, the header on any specific page explains from what object it inherits and also what interfaces it may implement. It seems as if most of your specific questions have been answered a number of times over, but if you want further reading on how this aspect of Unity operates, I’d suggest brushing up on the composite design pattern, as it’s the idea behind attaching all these components to a GameObject rather than having a free-floating “game loop,” which is what often throws people off who are coming to Unity from C++ and other application programming backgrounds.