Finally, an interactive tutorial series that WILL teach you C# for Unity3D

Please continue with these, an RPG tutorial would be amazing. It would be greatly appreciated

 

guys these are copy of walkerboys tutorials... why you should make copy of these tutorials let people learn from walkerboys better...

 

Don't those use javascript? The one I watched of walkerboys did... These use C#, some poeple(myself included) like C# better.

I'm grateful he makes these, I'm only on #6 but he does better than most anyone else I've seen at unity using C# tutorials. I sincerely hope he keeps making them too, I enjoy them and learn from them.

 

Hello,

Thank you all for enjoying the videos. It's been a little while since I have updated my youtube. With school coming to and end, I'll be available 100% to make new tutorials. My apologies for not finishing up the space shooter. I think when I return, I will focus my videos on more general aspects and maybe do a demonstration on how to implement them on specific games.

Thanks for watching!

 

I've just finished the last tutorial. You're awesome! I really wish you get back to this as soon as you can, by the way, when will that be?

 

Just come across your videos, there brilliant, when you do plan on making them again, will you still explain how (almost) every line of code works, until it gets further into the series of videos where the basics are second nature, if you know what i mean

 

men your videos are great, i hope you get well in school so you can continue the space shooter tutorial!

 

Great work on these, will definitley help me get forward in making my game

 

Hello, fans supporters!

I think it's time for a new video. My only problem right now is I no longer have the files for the space shooter. If anyone has the current progress that the video is at, if you can ZIP it and link me to a download, that would be awesome.

I want to spend the whole day finishing the series, so the faster someone can help me obtain a copy of the current progress, the better!

I want to apologize for taking so long. I have been working with other things and for a while moved away from the .NET framework to pursue a project in C++. I'll be using Unity3D again for an upcoming project and am looking forward to continuing a new tutorial series with hopefully daily-bi-daily uploads.

Again, thank you so much for enjoying the videos. My girlfriend thinks the compliments are going to my head, but let's be real here...I make some pretty damn good videos.

I look forward to making more videos!

Again, thank you so much for the support!

p.s: Someone please send me a download link to the project files of the space shooter if you have them. Otherwise the videos will take 1 week to come out as I don't have enough time to redo the contents of the space shooter.

Best,

SubZeroGaming

 

http://www.4shared.com/rar/1_UoFmZq/New_Unity_Project.html

i am new in uploading i hope this will be all you need

and your girlfriend is wrong you really do very good videos!

 

Thank you very much for the files.

I'll be releasing a video this evening.

Best,

SubZeroGaming

 

Is there anyone else who can upload? To maybe like uppit or another file share? That file share company is making me sign up for something. Not interested.

Thanks.

 

https://mega.co.nz/#!jIhXDDKZ!RGZYRGyV_aHJp9G6kcxZD2g5aCUX6hBV7HrR154NR4Q

here is the link man.

 

You all have been asking for months!

Enjoy, Video 10!

http://www.youtube.com/watch?v=rldjLcOTmzY&feature=youtu.be

I'm sorry if it's a bit rough. I have not made a video in a few months. I'm working on the points system now. Then the saving, and then the art.

Enjoy!

Subscribe, rate, comment, or not

Best,

SubZeroGaming

http://www.youtube.com/watch?v=rldjLcOTmzY&feature=youtu.be

 

Tutorial series for the SPACE SHOOTER is now complete. I'm currently editing the final video. Upload will be live witin the hour! Everyone, thank you so much for supporting my videos. I plan to start on another project, and finish the project before actually uploading so people don't have to get screwed when I don't have time to make them.

The next project is a fully functional platformer that includes Animations, actual art work, and best of all, PHYSICS!

Thanks again, I look forward to more feed back! Enjoy!

 

http://www.youtube.com/watch?v=fSDlY7mx7bs&feature=youtu.be

Final video! ^ Space Shooter Complete!

Again, thank you everyone for watching!

Best of luck, and stay tunes for the next upcoming series!

SubZeroGaming

 

Way to prove her wrong. /sarcasm

Your videos are good, but I wouldn't say they're "damn" good yet.

Remember that an arrogant programmer is often a messy programmer, so don't pat yourself on the back too much. You should be proud of the work you've done, while looking for ways to constantly improve it.

I wrote this as I watched it, so I might've missed something or be wrong about something, but here are some things that could've been clearer.

* Vector3.down has been deprecated. Always negate Vector3.up. Also, the "minus sign" in this context is the unary negative; a unary operator being an operator that takes one operand. Just to better distinguish it from subtraction.

* Just because an object has a rigidbody does not mean it automatically "stops going through stuff"; for instance, a kinematic rigidbody will pass right through static colliders and others of its kind. The form of movement matters also; if you're translating stuff, the rigidbody isn't going to very useful in collision detection and correction.

* You already mentioned this, but Kinematic rigidbodies behave opposite of what you described; they ignore forces, and by extension, gravity.

* The player CAN go through the enemy. Both are kinematic triggers. Not only do kinematic rigidbodies not detect collisions between one another, if either, or both, parties have isTrigger set to true, they will not collide in the normal sense. Only one party can be kinematic and neither can be triggers if you want collision that can be described as "can't go through each other."

* No collision events can be sent to any of your objects as trigger events will be sent, instead. So, it's actually incorrect to say anything is colliding with anything else. Straight from the documentation: "A trigger doesn't collide with rigid bodies." I'm being a little nit-picky, but the distinction matters since you haven't shown the viewer how to handle collisions. When they want something to collide, or want to use physics, they'll just end up with inert kinematic triggers.

* isTrigger is a boolean. It's not a "command." It's a value that is either true or false, and the collider determines when it intersects whether or not to collide or just send an OnTriggerEnter() message to the other party based on the flag.

* This next one is a programming 101 mistake. You should never name a method parameter with the same name as one of your fields. By naming the parameter to OnTriggerEnter "collider", you hide your own collider. Everywhere outside of this method, collider means your collider, but in this method, collider means some other object's collider. This is very confusing and one of the easiest to make, and hardest to debug, mistakes a beginner can make.

* This one's not really a problem, but "lazer" is a misspelling of "laser." Light Amplification by Stimulated Emission of Radiation. Might as well go all out and use lazor.

* "collider" is not a "function." You are not "calling" it. It's a parameter (normally it's a field, but you hid the field as noted above) and is an instance of the Collider class.

* You aren't comparing the objects or types of objects. You're just giving them tags and seeing if the tags match. It's just like tagging files so you know what category they fall under. You also aren't "searching" for anything. Every time anything enters the space occupied by the enemy, you are handed that object as an argument to OnTriggerEnter(). If that object is tagged with whatever tag you gave all of the lasers, it's a laser, so you do something. In this case, you destroy the enemy.

* The name in the asset hierarchy has nothing to do with the tag. It could be named "Lazer" in the hierarchy and you could have tagged all your lasers "lolsorandom" and then you'd be screwed. You could've also tagged different lasers with different tags. You click on the prefab and look for the "tag" field at the top of the inspector to get and set the tag. I have a prefab this instant named "Dirt Block" in my assets folder tagged "Des" for destructible. If I used "Dirt Block" when comparing tags in an if statement, it'd throw an exception and log "Tag: (name) is not defined!"

* The true "layout" for the player script at the end of the video is a direct copy and paste of the OnTriggerEnter() method of the enemy. Literally. All you do is change the tag to whatever you tagged your enemy with. I wouldn't even call that writing new code; you type in five characters in two places and you're done. Why waste three minutes re-abstracting what you've already just written a concrete implementation for?

* Now methods are run times? :razz:

* I've never heard someone explain declaring method parameters as "caching" something. Technically, since something is being passed by value to you, you're caching it. You could call anything caching, then, though. Setting an int called x to 5? Also caching. Why not explain what a parameter is and what a method signature contains more concisely? :neutral:

* This one is nitpicking, but the name of a parameter does matter. If you give it the same name as something else in scope, the one with the tightest scope wins. Plus, there's keywords. You also can't start the name with a number. You should also lowercase the first letter. You get the idea. You made the first error mentioned; you hid gameObject.collider with a parameter named collider.

* Again, drilling in something about the tag being the same as the hierarchy. First it had to match the name of the prefab, this time it has to match the name of the individual instance of the prefab, neither time does it have to match the actual tag in the tag and layer manager. I know it's a common mistake, but it'll get confusing for the viewer as soon as their tags don't match the name of the specific prefab they apply them to and they start throwing exceptions.

Now, on introspecting that, my main problem with your videos is simply terminology. You tend to call things what they're not, or make things more complex than they are, without explaining exactly what they really are. Strings become comparison codes, parameters become some form of caching, etcetera. You also like to compound the effects of a method, conditional and statement block into one abstract piece of functionality, which can be confusing. For instance, saying that the tag comparison lets the enemy collide with the lasers, or that vector multiplication itself is driving something somewhere. Essentially, you summarize what hasn't necessarily been explained fully. If you used more accurate terminology, explained exactly what the terms mean and explained the code with a more literal translation as well, you're videos would jump from good to "damn" good. Your pacing is pleasant and your videos definitely present the opportunities to learn everything, but as someone who's been learning new programming skills for some years now, I feel like you could utilize those opportunities better.

Still, aside from a few mistakes, your newer videos seem clearer to me than your older ones. Keep up the good work.

 

I always enjoy reading your constructive criticism. I wish my response was as long as yours, but I do appreciate the advice. I'll take note and account of this thread when creating my next series. To anyone here who has had misunderstood thoughts regarding terminology, I apologize in advance. Feel free to post below any questions, and i'll be 100% happy to answer your questions in the best of my abilities.

@Metabble

Thank you for taking the time to review my video.

Best,

SubZeroGaming

 

Hey, new to Unity3D. I'm a beginning programmer (took a few courses at my university for C++), and this type of tutorial really hit home for me. Use of documentation, outlining methods, and giving us problems to work out is working amazingly for me. You've made this a bit less daunting for me as a beginning C# programmer.

 

Thanks. A long post doesn't always require a long response. Also, no problem.

 

Hi, I'm glad they have helped you! Thanks for watching!

I look forward to your review on my next series.

Thank you

Best,

SubZeroGaming

 

Hi Jonathan,

Well, I have watched first 5 or 6 videos and I must tell you they are rather plaint. I mean, I already know everything from your tutorials In that post (Walkerboys) I meant that about their platformer series, and that's what I need. I was looking for a good tutorials how to create platforms, player's movement (over platforms, not just left, right, up etc). So from this point of view your tutorials don't suit me.

But keep going, of course! I believe you help those who just have started learning Unity and c# as well. Good for you!

 

Thanks, I appreciate it.

 

Can't wait for the RPG tutorial! I hope it is interactive too, this method is very helpful.

 

I think, (and most people would agree with me?), that it would be better to upload one video at a time than to wait until you finish all the videos before uploading them all at the same time. When it come to tutorials of these sort, even though we care about the end result, mostly we just want to learn about the process of it. For example, your space shooting series, even if you hadn't finish it, I already learn quite a lot just by watching one or two videos of you describing stuffs and how to make use of it. It's hard to find videos like that for us who just barely step foot into the world of programming.

At least, that's my opinion on it.

 

After watching episode 2 (gui tutorial) i started thinking about "unique" buttons, by "unique", i mean each button having a way of being called, for example:

"button1.Text = "O BOLO NÃO EXISTE!";"

I've tried to find some information about this, but i couldn't find any.

 

You can do that using different overloaded versions of the GUI.Button method. It allows to make a button using your texture OR a default texture and your text. I used this way: I used my own texture and a label to add some text. Example:

Code (csharp):

1.  
2. // Play button
3. if (GUI.Button(playButtonRect, ButtonTexture, guiStyle))
4. {
5.  
6. }
7.  
8. GUI.Label(playLabelRect, "Play", guiStyle);
9.  
10. // Settings button
11. if (GUI.Button(settingsButtonRect, ButtonTexture, guiStyle))
12. {
13.  
14. }
15.  
16. GUI.Label(settingsLabelRect, "Settings", guiStyle);
17.  

 

I have just finished a Raycast tutorial.

Uploading now

Perfect for you first person shooter fans.

 

It's out! Raycasting Made Simple!

Enjoy

http://www.youtube.com/watch?v=9Gx2tmhKq2g&feature=youtu.be

 

Bump! new raycasting video!

 

I watched the latest video on raycasting. Here's some thoughts.

*When explaining RaycastHit, you call it a method. It's a struct.

*Saying "just kidding" when you make a mistake doesn't make it any less obvious.

*It's not hard to tell what a Ray is. A Raycast requires an origin, direction and a distance. You also give it a reference to the container that it can store the resulting information in, which is a RaycastHit. You can give the Raycast method the origin and direction separately, as two Vector3s, or combine the two Vector3s into one Ray.

*It's a misnomer to call a Ray an origin. It is not the origin; it is, indeed, the whole ray. A ray is an origin, plus the direction in which the ray goes. The distance is used to limit it, but it is still a ray without this information; it is a ray of infinite length. It is not for simplicity that people call it a ray. Look in the documentation.

There is nothing confusing about it. You create a ray from a starting point and direction it goes. Your way is actually the simplification. Well, more bluntly, your description is completely and utterly incorrect.

*If you were going to simplify it, you should've used the overload that takes the origin and direction of the ray as separate Vector3 arguments. Then, at the end, you could reveal the fact that you can combine the two into a single Ray and pass the whole thing off that way.

*out is very simple. Normally, when you give a structure like a RaycastHit to a method, it gets a copy instead of the original. Anything it does to this copy has no effect on your copy. If you put out in front of the argument when you pass it, you're saying that you want the method to obtain a reference to your structure, instead of handing it its own copy. This way, it can assign data to it that it wants you to obtain.

There's also ref, which also passes a reference. The differences between ref and out are more clear from the method's standpoint.

If you make a method that takes a ref parameter, you don't need to assign anything to it. You just want a reference to something, and you can do whatever you want with it.

If you make a method that takes an out parameter, you are obligated to assign something to it before you return. You are explicitly stating that you want a reference that you can store some data in, as a way of returning multiple pieces of data at the same time.

out is usually used because you can only return one piece of data from a method at a time.

*You couldn't debug draw the ray because you tried to draw a line, which requires a beginning and end point. You can't use a ray as a Vector3 origin because it makes no sense, and, once again, was a confusing misnomer on your part. It isn't an origin, it's a ray. It HAS an origin; there's a huge difference between is-a and has-a relationships that you seem to find confusing.

*You tried to fix the mistake by giving it a direction as a start point. Maybe, when it asks for a start point, you should give it the ORIGIN of the ray instead of the DIRECTION? Just a thought.

*The debug drawing WASN'T working. You passed it the wrong information. The only reason you still got, more or less, the expected behavior is because a Vector3 direction is within a point on all axes of zero and that's where the camera was more or less placed. The fact that you didn't catch this is very, very bad. The origin should always be the origin of the ray, but if you rewatch that segment you'll see the origin is changing between a unit to the origin's right and left since you gave it the wrong info. The mistake is easier to see towards the end, when you're hitting stuff and adding forces.

*The conditional is not "if you're casting a ray," since then it'd always be true. It's "if we cast a ray and it HITS something."

*The force mode tells the physics engine HOW to apply the force. From the documentation:

"Force: Add a continuous force to the rigidbody, using its mass.
Acceleration: Add a continuous acceleration to the rigidbody, ignoring its mass.
Impulse: Add an instant force impulse to the rigidbody, using its mass.
VelocityChange: Add an instant velocity change to the rigidbody, ignoring its mass."

*You've already stated a power. Since direction is a normalized vector, the force would've been 1.0F. So, you're just scaling this up.

* I don't know why this

Code (csharp):

1. hitInfo.transform.gameObject.renderer.material.color = Color.green;

requires a paragraph of pseudo code talking about "calling" structures. Also I'm not comfortable with the term "call" when it comes to accessing fields, considering that "obtain" lowers the ambiguity between calling a method and obtaining a variable. Also, please use the term "assign" instead of "equals."

Code (csharp):

1. //subzero's pseudo code
2. /*
3. call the hit information
4. call the rigid body
5. gameobject
6. renderer
7. material
8. color
9. = Color.green
10. */
11. //desired result
12. hitInfo.transorm.gameObject.render.material.color = Color.green
13.  

Your current explanation can literally be turned into the desired code just by removing the words "call the" and the spaces, then inserting a period at the end of every word. Since, apparently, figuring out how to access a field is the big challenge at the end of this video, this is about all you could say, given the whole point that it's pseudo code and should remain somewhat abstract.

Code (csharp):

1. //obtain the material of the object we hit and change its color

Yeah. What we've just learned is that this does not require any pseudo code since it is so simple and that if the viewer can't do it after five hours of video tutorials in five seconds, they should've probably spent those five hours reading a book or something.

*A one line assignment should not be homework after a dozen videos and several hours. In fact, I would barely say that's acceptable homework for someone who's only been learning for an hour. Suggesting that the viewers might encounter errors doing a one line assignment and should fix them proves that they still may not understand much about programming. Also, I wouldn't suggest telling them to use a shortcut to obtain a color when they still probably don't know how to use the new keyword to create their own.

*Just for laughs, exclaiming "Oh! That's totally wrong!" and rewriting a comment to fix a typo, not catching the glaring error in the actual code.

*Now writing a single line assignment is creating a new method. This just keeps on getting worse.

*Congratulations. You called a method a menu. You use method-related terms to refer to types and menu-related terms to refer to methods. o_o

I don't think I have the energy to go through these any more. To be blunt, there's simply too many mistakes and I think you use the wrong term, or an ambiguous term, about 70% of the time. That's fine if the viewer wants to achieve the end presented in the tutorials, but not if they want the means to the end to teach them how to change their ideas into tangible code. When it takes 40 minutes to explain how to use a single method, you have a problem on your hands. It takes one paragraph to describe the Raycast method.

Now, maybe the viewer won't understand all that, so you might have to clarify some terms they might not know. I don't think it requires a forty minute tutorial. If they can't understand what the raycast method does from the text above, they haven't been taught how to actually program. Teach a man to fish and all that. You claim that your goal is to not show everyone how to do everything, yet I don't see how anyone's going to learn how to do anything competently with C# like this. In the same time it takes to watch your series, I had learned how to use most features of the C# language from MSDN and C# in a Nutshell. Sure, I knew C first, but that's why learning the actual programming concepts is so important.

I'm sorry if I seem condescending. Your videos are good, and better than when you first started. Just some thoughts on why I don't see them as being a really efficient way to learn C# yet. I think I've said all I can, so I don't see the need to review any more of your videos for awhile.

 

Raycast is a method that determines whether or not a collision occurs along a line, or "ray." -> No it isn't. A collision is not required, a collision implies two colliders colliding, this method determines if there is a collider between the origin of the ray and some point along the ray*. Secondly a line differs from a ray because a ray has direction (a ray is also by Unity's definition infinite).

The simplest way to use it is to pass it the origin of the ray, the direction it goes and the maximum distance along this line that should be tested for collision. -> I'm not quite sure what makes one way more simple than another, but I'd guess that not specifying a distance is likely to be considered simpler.

You also need to declare a variable of type RaycastHit and pass it to the method with the "out" keyword, where it will store the results. -> You don't need to this, the out parameter is optional and it is quite common not to use it.

* Of course this definition wont stand up either, you need to start listing the options (restricting distance, out variable, etc) and caveats (e.g. casting from inside a collider wont trigger a collision and is one reason why the term line could be misleading).

- - -

Not that I don't agree with the general thrust of your post (and I'm sure you understand the difference between a line and a ray, or that the out parameter is optional), but maybe a little less condescension is in order

 

Hey there SubZeroGaming,
I was wondering when your next tutorial will be??? I have been practicing all that you have taught me and I think that I'm ready to move on.

 

Hey Mayday,

Thanks for watching. Seeing as Mettable has ripped me a new one, i'm gonna be holding off on the videos for a little. Personally, I could give two S***s on terminology when it comes to programming. The way I see it, is if I understand it, that's better than being "politically" correct.

I'm trying to work on my videos so they are more "Politically" correct, but in the mean time, i'll be hanging low.

Thanks for watching

 

In this case, by collision, I meant an intersection. Thank you for the clarification. It is quite ironic that I pointed out the same incorrect usage of the term in a previous tutorial.

As for the distance, yes. That's true. However, I considered that the user would probably want to know how to specify a distance. I'd say it's the least complex way that gets all of the basic functionality. For the hit information, I again included that because I felt it was a necessary piece of functionality. In his tutorial, he uses the hit information, for example. I suppose "necessary" should've been "necessary depending what you want to determine with the raycast." Your last point is definitely right. I should've added a line about how raycasts ignore colliders they are cast outwards from. I didn't really think of that, as it seems like a very intuitive behaviour.

Finally, I'm terribly sorry if I came off as condescending or arrogant. TC has done a good job with this series so far. I'll admit, the whole terminology flipping around all over the place in the tutorials got a little on my nerves after a while, so my post gradually slipped from "constructive" to "destructive" when, to be honest, my experience is not so much greater. I just tend to get very nit picky and tight about learning resources, as I know how easy it is to get confused when learning new things.

Thanks for taking the time to post.

My goal was not to "rip you a new one." You should continue producing videos as often as you like! Just keep in mind any constructive criticism you receive, should you feel it valid. Also, I don't normally care much about terminology. I couldn't care less if someone uses "method" and "function" or "ray" and "line" interchangeably. As long as I get the general Idea. Do note that I had very little difficulty understanding what you meant in your tutorials! However, I feel that terminology becomes more important in tutorials so that the viewer understands what the terms mean. It's OK to be somewhat ambiguous in your explanations, just not if it could potentially confuse or mislead the student. So, it's less of a parallel to political correctness than simply wanting to keep the terms straight in the viewers heads until they are cemented in memory.

 

Mmkay, just letting you know, and I think I speak for all of us(except for Metabble), I don't think that having it politically correct is necessary. Your videos are a great help and they have guided me through many of my problems without 'spoon-feeding' me. You can take as much time as you like though, that is perfectly fine. Good luck with the hanging low.

Your student,
Mayday556

 

I don't think you need to stop, I think the comments here make it pretty clear that you are helping people. That said its probably a good idea to pay a little more attention to the terminology you use. Why? Because using the wrong words makes it harder to learn and talk about programming.

 

Hi

@Metabble

I have also watched SubZeroGaming's latest tutorial and read your rather harsh comments which you claim is just constructive criticism, but the fact is that SubZeroGaming's tutorials are among the best ones out there - even you must agree on that.

So instead of you constantly posting in this thread whenever SubZeroGaming is making a new tutorial with your constructive criticism, then why don't you make a tutorial yourself - from reading your posts, you obviously have knowledge of programming and some of use might benefit from if you would like to share and at the same time SubZeroGaming might also get a more tangible clue to what you think he is doing wrong all the time.

Maybe it is me who is sounding a bit harsh now, but it just constructive criticism, but of cause you already know that and won't hold it against me.

 

I don't think I've watched enough tutorials to know whether or not SubZero's series is one of the best or not. I have been programming for a few years now, so I could make some tutorials, but truth be told, I simply do not have the energy. Perhaps my fatigue feeds into the tone of my criticism, but aside from terminology, I wouldn't say he's doing things wrong all the time. Also, of course I won't hold it against you. All that matters to me is whether or not I think your criticism is valid; I couldn't care less what tone you picked, as long as there are no personal insults.

Keep in mind, also, that as someone who has been programming for a while now, I will have a different perspective than new users. I think the experience of the user greatly defines the usefulness of this series. To those who already have a handle on fundamental programming and C# concepts, I think this series is excellent. It shows how to perform a variety of tasks in straightforward manner and the exercises help the viewer learn where things go and generally how to use Unity. The main reason I am being "harsh" is because of the title: " ... an interactive tutorial series that WILL teach you C# for Unity3D." I'll admit, I have not watched every one of SubZero's tutorials, as I do not have the time or energy. However, from what I have watched, I don't see any explanation of programming concepts other than generalized abstractions that lump multiple statements and conditionals together into one general function, plus the misuse of terminology. The tutorials are good at showing the user how to perform basic tasks with Unity, but I really do not feel that someone who wants to learn C#, as the title suggests, will learn it here. Not when Vector3 multiplication "doesn't make sense" and is driving stuff around.

I'm not sure if I just missed some crucial videos or am the only one that finds his descriptions to be misleading. May I ask, what is your experience with programming, and do you feel like his series gives you a better understanding of C#? I feel like his videos will teach you the Unity API he uses without teaching you how to use that which he does not due to a lack of fundamental understanding. Someone going in not understanding the differences between structs and classes, method/operator overloading, value types and reference types, generics, different keywords and generally anything except for the extreme basics, will not come out understanding it. They'll be lucky if they don't think a public field is a method that they can call that's doing something while they're naming their rays "origins" (because they're really points?) and hiding their collider by giving a method parameter the same name.

However, I will say, that I am too harsh. For the record, I am a book learner. I feel the need to know everything I can about the tools I use often, though I admit my knowledge is not perfect–no programmer's ever is. It just doesn't seem complete to know to stick things in Update() without understanding what a method is, or multiplying Vector3s with a complete lack of understanding of how vector multiplication (which is exceedingly simple and takes twenty seconds to explain tops) works. So, perhaps it is less OP's fault than the way I learn. I learn by learning the basics of the language. I feel the purpose of watching a tutorial is so that, I will longer need tutorials to teach me new things after a while. :| Sure, it takes longer to learn the basics. However, the viewer can then use anything they want just by looking at the documentation. They'll see the descriptions, the signature, the types and the keywords and intuitively get the hang of things by the simple fact that every new things works exactly the same as everything before it in fundamental ways. You learn the basics and you no longer need to learn complex, completely new abstractions to mask everything that's typed in. :-?

To conclude, while my tone is almost always uncalled for, I still stand by my original analysis. It's probably just that the way I learn is in conflict with his tutorials, so maybe my criticism is only applicable to viewers such as myself, in which case I will no longer post it. I don't have the energy to do what he does, so I'll just let him do it and spare myself the time and energy writing any sort of criticism, since if I'm willing to spend the time writing a critique that the viewers themselves don't agree with, I might as well try my hand myself, which I am obviously not willing to do. Sorry if it felt like I was harping on SubZero or devaluing his work. If you feel you are learning from it, that's good enough. It seems obvious to me that lots of people enjoy the videos just as they are.

 

Oh boy, things got heated here in the end. I understand what Metabble is talking about and perhaps the title could be rephrased but I don't think a person with zero programming experience should start with a unity scripting tutorial anyway. There are many tutorials (often console based) that teaches you the fundamentals of c# and those skills are completely transferrable to these tutorials. For those that have zero experience, perhaps recommend a link to a tutorial that teaches you the absolute basics of c# syntax. For instance, the first 20 videos of the tutorial playlist I linked are more than enough to be able to follow your tutorials. http://www.youtube.com/watch?v=SXmVym6L8dw&list=PLAC325451207E3105

Once one at least understands the basic syntax of C#, your tutorials are just excellent. I spent a month on c# and learned the basics and now I am going through your tutorials, which is a blast and I dare say that your tutorials are without equal for this purpose. Atleast from those I have seen.

I too would like to know where you stand on the RPG-tutorial so if you decide to give them a go please keep us updated in this topic. Hopefully sooner than later! I want to take on a bigger learning tutorial for c# and yours is the first I would try (unless I have managed to get past that level in experience of course, depending on when/if you release). But since I want to learn as much as possible and as fast as possible, do you have another tutorial that you can recommend? I like your teaching style and feel that if you say a tutorial is good, it probably is.

Best regards: Farzan, your newest subscriber

If I could send you a beer as thanks over the internet I would.

 

Hi Ferzan,

Thanks for the great compliment, and the beer

When it comes to the RPG tutorial, I would like todo a series on it; however it will require a lot of time. It's still in the distant future, but what I plan on doing is releasing a new tutorial on general API functions in Unity such as my OnGUI video, or my RayCast video. Those videos will go over basic and advance methods to those functions and I will discuss how you would go about adding them to a specific game type.

I got a lot of great feedback from my space shooter game. The space shooter game has all the right skill sets so that you can expand and create other games. Including a platform game if you wanted.

I do plan to do another from start to finish game project series, but for a little, i'm gonna focus on getting everyone comfortable with the Unity3D API.

I plan to go over Mathf, Lerps, Quarternions, EulerAngles, and much more! And put it in terms and examples that anyone can follow. And i'll help people understand why they use these methods, and what they can do.

Again, thanks for watching!

Best,

SubZeroGaming

 

That sounds great. I will make sure to watch them as they come, and continue learning.
I have now finished your tutorials and it was a good learning experience. Even managed to do some changes of my own with what I learned. Models and even a menu / Game Over screen withj help from your GUI-video.

Cheers mate!

 

Hey SubZeroGaming,

Thanks for making these tutorials, their amazing and have really helped my understanding of unity and c#.

I do have a problem with my code though, i made it to video 9 when you explain how to destroy the enemy when the lazer hits him. However, i've been wrecking my brain over my own code, even though it looks identical to you (at least the collision bit does) and i don't get any compile errors (is that what you call them when you use debug on the scripting screen?)

Whenever i test the game, i can shoot the lazer, but when it hits the enemy i get a runtime error saying:

UnityException: Tag: Lazer is not defined!

If it was a scripting error i could easily fix it, but i've never had a run-time error before....so im kind of confused as to whats gone wrong.

Here's my code for enemy:

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class enemy : MonoBehaviour {
5.    
6.     public Transform myTransform;
7.  
8.    
9.     //int currentSpeed = 5;
10.        
11.     float x;
12.     float y;
13.    
14.     // Use this for initialization
15.     void Start () {
16.        
17.         myTransform = transform;
18.        
19.         // creates a randon x and y axis, the spawns the enemy based on these values
20.         x = Random.Range(-8.0f,8.0f);
21.         y = Random.Range(-3.0f,3.0f);
22.        
23.         myTransform.position = new Vector3(x,-3,50);
24.        
25.  
26.    
27.     }
28.    
29.     // Update is called once per frame
30.     void Update () {
31.        
32.         //generate a random number for an enemy ship's speed
33.         float currentSpeed = Random.Range(1.0f,10.0f);
34.        
35.         //enemy ship will move using the random speed.
36.         myTransform.Translate(Vector3.forward * currentSpeed * Time.deltaTime);
37.        
38.        
39.         //if the enemy reaches the bottom of the screen, they shift back to a random starting position (like spawn)
40.         if(myTransform.position.z < -6)
41.         {
42.             x = Random.Range (-8.0f,8.0f);
43.             y = Random.Range (-3.0f,3.0f);
44.            
45.             myTransform.position = new Vector3(x,-3,50);
46.         }
47.    
48.     }
49.    
50.     void OnTriggerEnter(Collider collider)
51.     {
52.         if(collider.CompareTag("Lazer"))
53.         {
54.     //if the Lazer hits the enemy
55.        
56.         //The enemy will be destroyed
57.         Destroy (this.gameObject);
58.         }
59.     }
60. }

Note, my game allows the player to move horizontally and vertically, and allows the enemy to spawn on a random X and Y axis (but bother are disabled temporarily to the same Y axis so i could test collision).

I can confirm that my prefab is called Lazer.

thanks again for the excellent tutorials, and for any help you can provide

 

I had the same issue. Same exakt code but no success. I managed to fix it by adding a new tag called Lazer to the prefab ProjectileFab. (if you used the same name as him.)

I think that is the main focus of the CompareTag, so you can tag several things that fall under the same category instead of typing in the name of each one.

Basically, go to your projectile prefab, and in the top part of your inspector, click on tag, then add tag.
In the new screen, click down the Tags that is at the top and add a new tag called Lazer to your projectile in the top elements. Just click to the right of the "elements" and type in your tag name. Your projectile will now be tagged as Lazer, and if you want to create other projectile prefabs, you can use the same tag without updating the enemy script.

Give it a try and see if it works. If not, SubZero will surely be able to help.

 

Edit: (Original Message Irrelevant)

Ok, so I did what you said FarzanZand and it didn't work to begin with but now, after waiting 10 minutes it does work (even though i haven't done anything lol).

Thanks for your help Farzan

I still don't understand Tags properly, and if SubZero could elaborate on them, i would really appreciate it

 

Hmm, I tried out your if(collider.CompareTag("Lazer")) method and it worked in my script as long as my projectile was tagged Lazer. Are you sure that it is tagged Lazer and not LazerTag? (seing that your error message says LazerTag).

 

Just wanted to add my thanks for an awesome series of tutorials. I hope to see more.

 

Thanks for offering the help

Thanks again, Farzan.

Veity,

I want to apologize, I did not actually go over tags in my videos. To sum it up, when we use

col.gameobject.comparetag("tagName") this is doing exactly what farzan has said.

We use tags to reference game objects. You can create I believe up to 32 tags. The reason why tags are important to use, is because say you have 50 enemies in your game. All different types. Well, you don't want to have to write separate collision detectors for each enemy for when your player hits them right? So we create 1 tag, and give it a name of Enemy. And then add that tag to all your enemies. This allows us to do 1 check for collision against all game objects with the tag enemy. And if it has that tag, then we can collide with it and do damage or whatever code is written inside the collision.

With the space shooter, we are giving the projectile a tag of Lazer. And then in the enemy script, we declare a function of OnTriggerEnter. We are telling the enemy script that if a collider with a tag of "Lazer" hits it, then destroy it.

I hope this has helped. If not, let me know and i'll have another look at your script. It looks good so far!

EDIT:

Code (csharp):

1.  
2. if(collider.CompareTag("Lazer"))
3.  

If you are having issues, try calling the "game object" of the collider.

ex:

Code (csharp):

1.  
2. if(collider.gameObject.CompareTag("Lazer"))
3.  

Thanks for watching, and best of luck!

SubZeroGaming

 

Thank you

You certainly will!

Best,

SubZeroGaming

 

Hey guys,

New tutorial is out. We go over pausing your game. We focus on Time.timeScale and how you can use it in your games!

Enjoy!

http://www.youtube.com/watch?v=0Gh0myraIFo&feature=youtu.be