First of all, exceptional tutorial. Many, many thanks.
I’ve finished building the Rocket and its smoke trail. It fires fine, and if it dies without colliding, everything is ok. But if it collides with anything I get this error:
Now that seems like a very clear error to me, but I’m so new to Unity’s method of coding that I don’t know how to fix it–can anyone tell what’s wrong just from that error?
Well, whatever the problem was, it went away when I added in the explosion in the next step.
lol, re-read your last two posts. 
I haven’t seen the tutorial, but you ran it before it was finished, the null reference was because you didn’t set up your explosion. The destroy code was trying to instantiate the explosion effect but it wasn’t there.
-Jeremy
Ah, the joys of being a newbie again.
Unity’s sort of similar to the C-Script we used with 3DGS, but it’s still plenty tough for me to figure out how it thinks. It seems like it will do more in a single line of code than about 10 lines of what I’m used to, so it’s hard to fill in all the jumps.
Can’t wait to start getting fluent.
I know what you mean–any time I want to do something and find myself writing more than 2-3 lines of code, I’ve learned to step back and ask if I’m making things needlessly difficult!
One line (albeit with a long formula and lots-o-dots) can do a LOT in Unity.
It shouldn’t take you too long. At least the syntax is quite similar. Once you get the differences it will work much better. I have used C-script in 3DGS before a little bit, but it always annoyed the heck out of me, especially the limited “skills”. But I didn’t take the time to get good at it.
On the other hand, I loved programming in Unity as soon as I started. Unity’s scripting is more intuitive to me than 3DGS’s. But that is just me and I am more a programmer than an artist.
Anyway, once it “clicks” for you I bet you will wonder how you did it with C-Script so long.
-Jeremy
Yes, I don’t mean to fault Unity’s programming language at all–I’m just not a programmer. I had to learn 3DGS’s C-Script extremely well, but I know NOTHING beyond that, so I just have to learn the basic java programming conventions (or maybe they’re Unity conventions). I don’t really think that the way I’m used to is any better, but for the benefit of anyone else who winds up coming from C-Script, here are a few things I had to learn about Unity’s programming (so far):
Variables. These aren’t your ordinary variables that just hold a numeric or string value. It seems they can also be pointers to just about any kind of object, like particles or even geometry. Also, we just barely got “local” variables in 3DGS, but they appear to be an integral part of Unity’s Java scripts.
The whole “.” thing. It looks like you can string together all kinds of different things by using this little dot. The advantage appears to be that you can do a lot with a single line of code, but you have to memorize exactly what functions are available to be called and it’s hard to find what they are if you don’t already have them memorized.
It’s a little odd to me how you assign all scripts to game objects, and then each script has various scripts within it–one that runs at launch, one that runs right after that, then one that runs every frame. In 3DGS you would attach “actions” to certain entities, but most of your functions were global and could be called by anyone.
Again, I think the way Unity’s doing it is a great way to go, it’s just new to me. And the bulk of my problem is that I’m ignorant. I never studied programming. I just learned one C-Script because I had to in order to make my game.
I’m wondering if it would be super helpful to pick up a generic book on Java programming? Or is it better to leanr C#. The programmers I talk to seem to like C# better, but Unity appears to heavily favor Java.
Not Java, but JavaScript–I would either get a book, or else there are some nice tutorials and reference resources online for JavaScript.
I’m new to JavaScript myself, but I’ve used Flash ActionScript which is similar.
For the Unity specifics, I find it very helpful to do a Find on the Classes page under Reference in the Unity HTML manual.
Variables in Unity are the same as whatever language you are using. You also have access to the types that .net adds. That is part of why “scripting” in Unity is more like programming, in function not ease of use, than normal scripting. Gives you much more freedom without killing you.
The “.” syntax is a standard with Object Oriented Programming (OOP). The “.” has to do with classes and functions of classes (basically, it is not only classes). So GameObject.Find(“player”); says that we are looking in the class “GameObject” for the function “Find”. Whenever you use a “.” like that, you are retrieving a variable/function/object of the object/class/property/etc. Confusing enough?
If you think of everything in terms of objects it gets easier to manage. Every script is a seperate object, and if you want a script that derives from monobehaviour to execute on its own, it needs to be on an active GameObject of some sort.
As for the “scripts within scripts” that get called at different times, those are not scripts. Those are funtions inside the one script. Update, LateUpdate, Start, Awake, etc are just functions that are automatically called by the engine at certain times. That’s it. So when the Unity engine starts up, and starts creating your objects, it looks in all the scripts for a function called Awake(). If there is one, it runs it. And so on and so forth.
I would recommend you get a book. Even some website that explains the basics of general programming (variables, classes, functions, etc) would get you pretty far.
For learning, Javascript is easier than C#, but Unity doesn’t favor either. You can use what you want. The difference is most of the code samples are in JavaScript.
Personally, I use C# for everything. I prefer it for many reasons, I find the syntax cleaner and easier to follow because you have to define every variable type (int, float, Vector3, etc), and so on, so you always know what is going on where. I found with Javascript it is easier to shoot yourself in the foot because it does so much stuff “automagically”. If you don’t know exactly what JavaScript is doing with your code, it can get tricky.
Also most programmers prefer C# for large projects. It makes you type a little more, but it pays off in the end.
It basically comes down to user preference, and the type of projects you are doing. If you are expecting to write a lot of code, I’d say go with C#, but if you want to get stuff running superfast and want something easier, JavaScript is the way to go.
Anyway, enough rambling, I am long winded today.
-Jeremy
Jeremy,
Very good thoughts–be long-winded as much as you want 
. We’re actually trying to decide right now whether to go with C# or JavaScript, so it’s timely advice. We’re definitely going to get lots and lots of code, so perhaps it’s best to jump to C# right now–despite the fact that all the examples are in JavaScript.
One question–what is “monobehavior” anyway?
Thanks!
At this juncture I still prefer JavaScript to C#. Of course I am a dynamic typing type person. C# tends to slow me down since you have to explicitly tell it everything. I will also use Boo with Unity since it has Duck typing. Strangely, I have more experience with C# professionally.
The “.” Dot notation is because programmers are lazy and prefer to type as little as possible. I am also strange because I perfer the Smalltalk/Obj-C style, but I can use both.
I would suggest you start with JavaScript. Since the Unity JavaScript implementation uses .Net, you will still do many things the same way as you would with C# since you are using the .Net frameworks. It is a matter of taste though.