Unity book for programmers

Questions & Answers
1

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/

3

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

Design Patterns - Wikipedia .

2

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.

4

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

5

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” :slight_smile:

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? :slight_smile:

#where do you start your singleton classes?

.

well that would be “when the program launches” (ie, in this space-time universe: “the first scene” :slight_smile: … 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 :slight_smile:

where do you start your singleton classes?

look back to “where is the entry point?” – same answer :slight_smile:

{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.

6

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.)

7

So far, I use three kind of developpement styles with Unity.

  • Pure POO (MVC) with MonoBehaviour scripts calling my engine: this kind of Game development does not fit in Unity totally. I write my engine following a MVC design pattern most of the time, then I connect my variables with Unity’s GameObjects and I make it work so i just have to manipulate algorithms and stuff. The animation/rendering part is done in Unity directly, so is some of the physics, but the positions of Objects etc are done in my Engine. I use this especially for IA-implementation.
  • Pure scripting, with almost everything in the same script whatsoever, but I find this very disgusting…
  • A mix of the above: I implement my engine in a way. This is the “squeletton” of the game. Then I add a script, in which I implement the scenario (you have to do X before doing this etc). I use a class of constants to keep track of the situation number. These constants are updated mainly in the engine/scenario scripts. At the end, I may add some options using completely independant scripts (but they still need the engine/scenario to access information and do their stuff). I use the constants to determine whether I can do something or not (eg. adding a visibility update all monsters, which are invisible in the engine but not yet on the screen… I create one script that every monster will have…)

I expect some opinions about my way to code using Unity…
Thanks :slight_smile: