Unity 3D Book ?

I got this PDF File: Learning C# Programming With Unity 3D By Alex Okita[AKD]

do you think It helps to Master Unity 3D ?

Thanks for Helping

 

I'd say - if you want to make a good Unity programmer, then you need to make a good programmer first. And then just learn Unity. So... first learn C# as a platform, then learn Unity as a platform.

It's like lifting - you can't just pump your biceps, you have to do base first - bench-press, squats, deadlift.

 

I think it never hurts to get all sorts of sources for your learning. Books are one of them. Good luck to you!

 

Books are great. But the trouble with books is they are not updated. By there very nature a book once printed cannot be changed. The engine on the other hand changes quite frequently.

So books are good for general principles. But the specifics are often out of date.

 

This. Learn programming. Then learn game development. It is a specialization, not a subset!

Edit: You can learn one while doing the other. Just keep in mind that they're separate pursuits even if they're related, and should be treated as such. Make sure you learn the fundamentals of programming in their own right. Then learn how to apply that to making games.

 

I would say "buyer beware".

I paid a good deal of money for a Unity book once and the projects in it were straight up broken. Make sure to read up on the book's reviews.

 

I'm curious to know the answer as well. Would you need anything more than the unity 5 tutorials/ training sessions to get a solid grasp/foundation after you gain some proficiency with C#?

 

I have introduction to game design, prototyping and development by Jeremy Gibson. It's a great book on game design as well as development in Unity.

 

What do you mean "get a solid grasp"? That's the wrong question you ask. Just learn C# and keep learning Unity - you never can say "okay, now I know everything I need. I can relax and just make games."

The thing is - you will never know enough. Okay? Never. That's the beauty of scientific hobbies - you learn until you dead. The one who's learned more till his death - wins

 

I meant something more along the lines of a progression from C#, then a step-by-step of the basics in Unity without missing some aspect of it. I get what you're saying, and I agree with the "always learning" aspect of it, but even .Net books/tutorials were progressive in nature. Same with the Unity 5 part. Getting up to functional speed can take the form of tutorials on the website, books, video tutorials, etc. before you can "keep learning", you have to learn the basics to begin with.

That beginning was what I meant.

 

Yes.

Practice.

Lots and lots of practice.

I'd also recommend reading up on game engine fundamentals. Programming is telling a computer what to do. There are huge benefits to understanding what it's doing under the hood in order to follow your instructions. I'd also learn about data structures and algorithms.

Perhaps a good book to get started would be Game Engine Architecture by Jason Gregory.

I'd also recommend at some point learning about software design and architecture. I see many game programmers make life far harder for themselves than it has to be by not taking advantage of tools, standards or practices that the rest of the software development world a) takes for granted or b) has researched and refined for decades.

 

I agree learn C# or just about any other programming language first. Programming principals especially OOP will go a long way to help you figure out how to get through Unity.

The component system is like it's own OOP layer that sometimes doesn't jive with C# OOP. I don't even really know how to describe it, but I imagine if this is not only your first time learning C#, but your first foray into programming in general it will get incredibly overwhelming. Which puts your success rate down the toilet.

The languages themselves are relatively simple to learn. It's the underlying theory and ability to solve the problem at hand that takes practice. There are all sorts of projects you could work on outside of game programming to get your feet wet that I think would be an easier step. Though keep in mind this is life long practice. It's not like you need to program for years first then go to Unity. Just get familiar with the IDE. Work on some tutorials, then think of your own project you want to make. Email program, IRC client, WoW bot, mp3 sorter, whatever. Once you learn how to ask google the right questions to complete an intermediate difficultly C# application you'll have a leg up on learning Unity.

This of course is not a rule that applies necessarily to everyone. Some people are exceptional learners and even better at keeping their head up though difficult tasks.

If I was starting fresh though I'd for sure want to make it as easy as possible on myself.

 

People keep saying this... I don't understand it.

Is it that people think "object oriented" means "uses inheritance"?

Inheritance is just one of many tools commonly used in OOP. Aggregation and composition are just as important, just as valid, and no less "object oriented".

 

I was going to say the same thing. Composition is a big part of any OOP design.

There are plenty of things that Unity doesn't gel well with. But OOP is not one of them. (Except for interfaces not being serialisable. That's a pain).

 

Actually, that's quite a valid interpretation of "sometimes doesn't jive with C# OOP". I just see a lot of people saying similar things clearly not referring to that kind of thing (e.g.; "Unity isn't OO, it's CO") and jumped to the same conclusion here.

 

Eh that's not really what i'm talking about. obviously Unity is very OO. It's just different than the way you'd do it in a traditional C# application.

For someone who is trying to learn the language in my opinion this could pose problems right out of the gates.

Mostly having to do with MonoBehaviors. Just the basic stuff like start methods instead of constructors.

Class declarations end up being MyClass obj = somegameobject.AddComponent<MyClass>();
instead of MyClass obj = new Myclass();

Of course not everything has to be done as a Mono Behavior, but if you are just starting out that's the way you'll be taught.

I still have trouble wrapping my head around certain things in Unity that are simple if I was just writing straight C# like passing references to a specific component from one thing to another as opposed to passing the game object and getting the component via GetComponent

You just have to think differently.. Who knows though maybe if Unity is the whole reason you care to learn C# in the first place it's not a bad place to start seeing as traditional teaching wont get in the way heh.

 

No, I think it's worth learning properly for exactly the reasons you've mentioned. I don't think they have much to do with whether or not Unity is OO, but they're all highly valid nonetheless. Having said that...

You can absolutely pass references to components between components. Components are still classes/objects just like normal C# classes/objects, it just happens that they're doing a bunch of stuff you don't see directly (which, yes, makes them at best an awkward starting point for learning the language and how to program).

A GameObject is just a type of container, and a MonoBehaviour is just a class which has some built-in functionality which essentially provides hooks into a part of a scene.

 

You certainly can become proficient in C# within Unity without ever going outside the environment. I've done it.

But I have no illusions I'm competent with C# and .NET as a whole. It would be a steep climb to learn to write an app in pure C#. Or some other language.

While in one sense, it is just C#. In another the framework you are working within is very different.

 

Yeah I just found out the hard way that references can be bad if the game objects get destroyed. Had one of those "duh" moments.

So then I was thinking as soon as I get the reference I'll copy it into an internal object. Except the problem is that it had an Awake() function that needed to be called.

So once I got my head around that I just copied the component from the game object that could be destroyed into the other game object that wanted that information as a component, and it works fine this way.

Seems simple when I write it out, but for some reason I had trouble getting my head around it.

That leads to my overall point. I can't even properly word what I have trouble with in programming for Unity. If I had zero prior programming knowledge this would be a complete disaster haha.

 

It sounds like you might have been getting tripped up by stuff that's happening in the engine, outside of the scripting environment, where the rules are different.