koobas.hobune.stream
I'm already an experienced programmer, is there anywhere great to go to get familiar with the libraries available in unity?
Everything I have looked at so far only seems to be for people who don't know how to program at all. I'm a third year computer science student just looking for a summer project to build a better portfolio and I can't seem to find anything that completely lays out the different objects and methods available for unity. Is there anyone who can point me in the right direction?
The online Unity docs are quite complete and include both explainatory and library docs.
HOWEVER I have to caution you against hubris. Just because you have written code, even C# code, doesn't mean you understand the logic and object life cycle of Unity. It is very different then, say, a .net/mono program.
I had 30 years of programming in everything from assembly to C# when I came to Unity and I still found going through Will Goldstone's book extremely helpful. (http://unitybook.net/)
Anyway the online docs are here:
http://docs.unity3d.com/Manual/
Good luck
Thank you, at the moment I am going through a book on unity 2d development by dave calabrese. Once I go through that and have had a look at the online docs I will definitely give goldstone's a look, my only issue is I would rather focus on 2d as I have no experience generating 3d assets. As a cs major i have mostly focused on database program$$anonymous$$g so I will admit that you are 100% right that wrapping my head around some of this is a bit harder than I thought it would be. Thanks again!
Specifically, look at the Scripting Reference. It was clearly written by and for programmers. After wading through various Unity docs, thinking "I am not their target audience, here," I felt like I found the grown-ups: http://docs.unity3d.com/ScriptReference/Transform.html
Some things it took me a while to figure out:
o The "real" structure is really a GameObject with a list of components. All of the component fields are really getters using a loop. A.rigidbody just loops through your component list until it finds the first rigidbody.
o Since every GameObject has to have one Transform, you can safely think of gameObjects as Transforms. Of course, T.gameObject is just a pointer to the transform component's parent gameObject, while T.renderer is a loop.
o Unity runs all of C#. Many of the examples do things in a "let's not confuse the interns" sort of way. You don't have to write your code like that.
o It seems natural to use Resourses.Get(?) to load and build everything. But using Unity's Prefabs, and making hooks using Inspector public variables is totally worth it.
"Unity runs all of C#. "
Not quite. beware of recent language additions. The dynamic keyword, for instance, will make it blow up in compile. Some more complex uses of generics confuse it.
I would also say its cleaner and better to think of GameObject as an empty container for components and Transform as just another component, even though it is true that every GameObject has one. Also, be aware that the scene graph is a tree of Transforms, not a tree of GameObjects. It just happens that a Transform must be contained in a GameObject.
Be VERY aware of the lifecycle of both GameObjects and components.
The lifecycle of a Component is Awake(), Followed by Start(), Followed by repeated calls to Update and other event callbacks. Underneath, Unity is running a classic game Update/Render loop so some system things you do in your Update() call don't really take effect until all updating is done.
Game objects can be created with new, but components cannot. The right way to create a component from code is to call GameObject.AddComponent. Be aware that the components constructor will not get invoked. Thats what Awake() and Start() are for.
GameObjects and components both have to be deallocated using Unity's GameObject.Destroy() method. Until you do so they will remain in the scene and will not be collected.
To temporarily remove objects or components from execution, disable them, don't destroy them.
That's my point about transform vs. gameObject. It makes no sense how even the system uses them almost interchangably, until you realize each GO has a unique transform, which has a backpointer.
I think many C# programmers know there's background magic -- ASP, for example. So sure, read the set-up for Unity, but that won't take long. But then know anything not covered is regular C#. If you write you own classes that don't inherit from $$anonymous$$Behav, of course Unity runs the constructor. convert.toint32 isn't in any docs or UA questions, but of course you can use it.
When you come to the Physics or $$anonymous$$athf libraries, it's standard C# documentation, with no magic. If you understand out parameters and overloading, you can skip 95% of the Q's here on how to use Raycast.
