koobas.hobune.stream
Unity book for programmers
Is there any book out there about how ot use Unity from a programmer point of view?
All books and tutorials focus on adding behaviours to game objects... which is fine. But what about game manager classes? Singletons? OOP patterns?
Thanks
Edit
It seems my question is quite confusing as I'm only getting suggestions as to how to learn OOP, and such. But that is not my question. I know plenty of OOP.
What I'd like to know, is how does the OOP thinking fit into Unity. I have seen plenty of tutorials, and everyone just add behaviours to game objects much like a decorator pattern in OOP using drag and drop. That's fine, but I'm a programmer, and I'd like to know how to do things the way programmers do things.
For example: in any regular framework (C++, Objective C, AS3, Java) there's something called an entry point where the program starts. There you start everything: your global classes, your managers, etc. Where is that in Unity?
Any experienced programmer should know what I'm talking about. I know Unity does things differently, and I'm looking for a book that explains how that stuff work for programmers, not for people without any background in coding.
Here is another programmer with the exact same confusion I'm facing, and it seems he didn't find an answer.. http://andrewcarvalho.com/projects/learning-unity-as-a-programmer/
Note: if anyone reading in the future is utterly new to program$$anonymous$$g, Emergency makes a critical point below: note that it's commonplace / the usual thing for game objects to be "blank" (ie, there's nothing you see or hear) and they just carry processes (ie scripts) on them which run every frame
the simple answer is - there is really NOT a book like this.
there's no title "Unity3D game development for already advanced programmers"
I suggest you just buy all the classic texts on game mathematics (eg, "Real Time Collision Detection" etc etc - just search on here for many mentions) and go from there
You should have no problem at all with the Unity editor if you are already a skilled programmer. Simply click to Unity's own various video and text tutorials - they are fine.
Essentially unity (like most game engines) is scene based. nothing happens until you create a scene. be sure to "include the scene in the build" (just click to build settings)
in the scene have objects (say .. a cube. a dragon. whatever. you will certainly and obviously need say a "camera" if you think about it - and lights) essentially, add scripts to the objects.
functions in these scripts can basically run every frame (you'll soon learn about "Update" and the like)
unity is of course "frame based" - the physics engine and the general engine runs "each frame"
at first, simply forget about scripts, and add a cube, with a "rigidbody", some mass, gravity on, and make a "floor" it can bounce on. unity will do everything - that's the whole idea.
the scripts are just dressing for crap like adding social media tie ins, etc ;-)
Ok, so you have a scene. How do you instantiate your god classes?
You write a script and attach it to an object in the scene. The object will carry out any and all instructions in the script.
You can even make empty objects that don't show up as anything and don't interact with anything, but have scripts attached that control everything and anything you want in your game. A good example of this would be a GUI manager object with scripts concerned only with drawing things on your screen.
For example, later on, you'll probably have things like enemy prefabs (read up on those, as they are a key part in unity) with various behavioral scripts attached to them, and every enemy object you instantiate from the prefab into your game world will execute its scripts.
This is essential and I haven't been able to find something decent. I'd like to see: preferred way to organize your project and store your state. I'd also like to see that kind of stuff not tucked away in screencasts that take too much time for the information they give you.
Getting started with Unity is a nightmare for programmers.
this question is now resolved. the simple answer is "there is no such book". Please CLOSE this question (tick any useful answer). You get "points" so that you can open new questions in the future, without moderation.
Do not hesitate to ask any new, further questions at all.
To expand on comments here,
1, write a script,
2, in the constrictor say something like "Debug Log Hello",
3, click Play
It seems everything you do is attaching behaviours to game objects...
.
well -- yes, of course. you must know that's the entire nature of a game engine???? it would be as if you said "damn it, programming for android I'm always dealing with this screen thing..."
{note that, of course obviously, you can have ordinary static classes in the very few situations that is relevant in a typical game (for example, just for math calculations, etc etc}
where is the entry point?
.
"The First Scene, Dude" :)
100% of scene-based programs of course, obviously, have a first scene which you mark as persistent, and you have all the persistent stuff (from networking to social media to payments to AI to scoring etc etc) in there. As mentioned often, ok, unity "forgot" to just click that in automatically when you open a new project (which would save you "three whole clicks") but .. so what? if a new programmer can't grasp the notion that the first scene runs first it's hard to know what to do right? :)
where do you start your singleton classes?
.
well that would be "when the program launches" (ie, in this space-time universe: "the first scene" :) .. see previous point!!)
note that you have the annoyance of "linking" singleton-or-static like concepts to coroutine concepts: ok, that's always a nuisance and can take up to three lines of code. yes, every team will have their own standard solution they always use. I like my "Grid" one because it is just idiotically simple (you just manually type in 1 line of code in the sort of register there for each new overall-singleton-like-monobehaviour you add)
note that this is purely a syntax problem. all you are saying is, what's the tidiest way in code to get to those guys. I personally like the look of Grid.networking.DoSomething() with the capitalisation like that, if you prefer another solution, whatever, it's 3 lines of code, suit yourself. To be absolutely clear you can just NOT USE such a "convenient syntax maker" and just ".Find" the item every single time {setting aside performance issues} ... my point is ALL WE ARE TALKING ABOUT HERE is a "syntax pretty-fier": it is less than nothing, it has absolutely no computer science conceptual significance.
To recap...
It seems everything you do is attaching behaviours to game objects...
answer .. "uh, yeah"
where is the entry point?
the answer to that one is so simple I won't type it out again :)
where do you start your singleton classes?
look back to "where is the entry point?" -- same answer :)
{note that, of course obviously, monobehaviours / coroutines can't be "singletons", it's meaningless: they are already things that are completely persistent over time and space; so you (trivially) want to "link to them", just as a syntax matter, so that they can be "used like" singletons or statics.}
then you just have the question convenient way to refer to those guys in code? Each team will have their own 3-line solution for that {for example: personally, I'd use a preprocessor, because I love preprocessing text files!, but there is no preprocessor in the unity milieu} ... check the "Grid" one linked below for a incredibly simple and rock-solid trivial solution.
Unfortunately, Fattie is right. There is no guidance that I could find about how to write GOOD Unity programs. There are many about how to attach scripts to objects, but no guidance about how to write 'real' programs. and how to structure them in a way that will work well with Unity. I'm going to try to treat it as any other project with proper separation of concerns, etc. and see where it goes from there.
Unity from a programmer's point of view is just plain old programming, thus any book about programming is what you're after. That being said, there are too many subjects to list here, and a good few books written about each of those.
Because you seem to know what you want to learn, I suggest going to Amazon or whaterver your favorite book store is, and browsing their wares for any programming books that discuss what you want to learn.
Since you mentioned Design patterns, here is basically the fundamental book on that topic: "Design Patterns: Elements of Reusable Object-Oriented Software" by who are known as the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Thanks, I know all the OOP stuff, I have been doing OOP for years. But my question is how do you apply that into Unity. It seems everything you do is attaching behaviours to game objects... where is the entry point? where do you start your singleton classes? I'm interested to know how those concepts apply in Unity, and if there's a book about that.
1, write a script,
2, in the constrictor say something like "Debug Log Hello",
3, click Play
I disagree that it's 'plain old program$$anonymous$$g' since unity forces you to do things in a certain way.
This answer does not address the question. The question for a programmer would be where to put which scripts and how to organize your project.
Also: where in the Design Patterns book do they talk about Prefabs?
Hi Illustr. It's just not that complicated. The whole wide world runs on frame-based game engines. And you always have to deal with the (trivial) issue of clearly deciding how singletons fit in to frame based (so, in unity monobehaviour) concepts. it's really not that big a deal...
This is a video series, not a book, but this guy shows you how to make an FPS game top-to-bottom. It is very beginner oriented, and he painstakingly explains every single line of code he writes, but the code itself is professional and he spends 80% of the tutorials writing code.
I've only ever done coding before starting to use unity, and even though it was a bit too slow at times, his videos were enough to get me started.
I'm in the path of learning both Unity and C#.. found two great books about them: Introduction to Game Design: From concept to playable game, by Jeremy Gibson... and Learning C# Program$$anonymous$$g with Unity 3D, by $$anonymous$$ Okita, among many other resources sites, including the tutorials page here in Unity Learn... but I gotta tell you, these series of video tuts you just mentioned are really really nice, the guy explains patiently everything he does and is a must see. Nice link Em3rgency.
It's going way into the deep end and uses C++ and DirectX, not Unity, but this is an excellent book about the items you asked about (game manager classes? Singletons? OOP patterns?).
Caveats: It's aimed at people creating game engines from scratch and touches only lightly on 3D, so it is most definitely not for everyone. Several of the chapters won't apply since Unity already has libraries for the items it talks about. Take a look at the index and see if it is covering things you're interested in before buying.
Game Coding Complete, Fourth Edition http://www.amazon.com/gp/product/B00B7RE4GQ/ref=oh_d__o04_details_o04__i00?ie=UTF8&psc=1
Thanks. But what I want is not to understand those concepts, I already do. What I want is to know how to apply those in Unity. In any traditional framework you have level managers, you instantiate objects, etc. But in Unity it seems to me that you only attach behaviours (like a decorator pattern) to game objects. I'm pretty sure there must be another way of doing things than just attaching classes to game objects with drag and drop... but how???
Game Engines are now the traditional framework.
The entire universe of game development (which is, by far, the biggest field of program$$anonymous$$g, and indeed by far the largest entertainment industry financially) is 99% game engine.
You can entirely and totally instantiate objects and/or add classes to those objects, in code as it were, as you wish.
You may want to start by glancing at the "Instantiate" command in the documentation :)
Really it is extremely straightforward, cheers.
It seems you don't have a clue what I'm talking about. Instantiation in unity is cloning an object, as the documentation says. http://docs.unity3d.com/Documentation/ScriptReference/Object.Instantiate.html
In real program$$anonymous$$g, instantiation is something quite different. Anyone that has done some OOP knows this. http://en.wikipedia.org/wiki/Instance_(computer_science)
Hi $$anonymous$$oix. It is utterly uninteresting and totally non-surprising that in English, (and most languages) words commonly have different meanings... the same word can mean a few different things, or, (important) variations on a thing. If you are saying "Unity should have chosen a slightly different word than 'instantiate' for that process because it's not really quite the same as how 'instantiate' is used in computer science..." then, fine. But: so what? To anyone other than the most naive inexperienced beginner programmer, it's all utterly clear and simple.
For an "entry point," many people often attach a script to an empty game object. The script needs to be "in the scene" for Unity to run the Update function, and being attached to an empty satisfies that. Unity's event loop is going to call Update for you 1nce/frame, and it's just easier to let it. A dontDestroyOnLoad can keep it on scene change (but often easier to let Unity swap in the new one.)
You can freely just add classes in a file (script) attached to nothing (just written in Assets/Project.) Unity will gladly link the ones you need, give them access to Unity classes and functions, etc... .
If you use built-in physics, the listeners HAVE to go on the object. There's no way for a master script to say "call Thunk whenever that ball over there gits hit." But you can fake it by adding/inheriting a script on ball which just says "OnCollision, call masterScript.Thunk()." You don't even have to use prefabs -- you can add scripts (attach a class to a game object) or anything else in code. So you could generate a mix&match bouncing thing with "callbacks" to the master script (the docs take pains to explain Instantiate is merely a shortcut for the "real" programmery way.)
