Unity Game Development Essentials - Book Review

The publishers of Unity Game Development Essentials, Packt, were kind enough to send me a review copy of the book at the end of last year, but I have been so stupidly busy I didn't have much time to read the book let alone post my review. I had originally planned to only read the book while sat in front of Unity so that I could work along with the tutorials, but again time got me so I ended up just reading it on the train. As it turned out this didn't actually cause any problems, and I managed to turn an unproductive commute into some very productive learning time.

The book is basically one long tutorial that shows you how to make a tropical island, set up a first-person camera to walk around it, and create some interaction with the environment, such as collecting objects, opening doors and (don't ask me why) throwing coconuts. Between this book, Unity3d.com's tropical paradise demo and Offroad Velociraptor Safari, you will be forgiven for thinking Unity can only make games set on tropical islands. I assure you this is not true.

Going through these kinds of tutorials is not how I normally learn a technology. My normal approach is to just fire up the editor and start hacking code until something moves on the screen - as I did with Unity last year. However, I have to say that for Unity, which is a very unique, graphical interface driven technology, the approach of going through tutorials is actually better. I learned many techniques from the book (e.g. using the terrain editor, setting up the skybox) that aren't immediately obvious from just poking around the IDE.

The book is meant for a wide audience, including designers, and the code is quite basic, and not necessarily the most "correct" way of working if you're coming from the world of design patterns, MVC frameworks etc. However, I don't see this as an issue, as if you know a better way of doing things it will be trivial for you to refactor the code to meet your needs. The caveat, however, is that the code is all JavaScript, and many Flash guys will be more inclined to take the C# route, despite the obvious similarities between AS3 and Unity's implementation of JavaScript.

The book's main drawback is that at the end of it you haven't really made a "game" in the sense that I understand it. You've made a kind of interactive environment with some coconut throwing. The book's main benefit, however, is that it gives you a nice introduction to all the facets of Unity, from terrain, cameras, physics and prefabs to adding a user interface and menu. Many parts of the book are written just for people coming from Flash, and if that's you, you will definitely be able to go off and make your first game after reading it. Overall, if you're just getting into Unity I think this is a great place to start.

Unity3D hands-on first impressions

Today I got together with my buddy Adrian who is a big-shot special effects guy, with the aim of trying to punch through the Unity3D learning curve and get some kind of game going. (Adrian is using the Mac in the photo, and for fairness I should point out that he was pulling that face as a joke). Adrian does Maya so he was able to grok the Unity IDE much quicker than me, as there are a lot of keyboard shortcuts you need to know (e.g. press "F" to focus the IDE on a selected object). I, on the other hand, had installed Visual Studio C# Express, so I had intellisense for coding :)



Here is my effort - MatrixPong. I had intended to post the actual game, but it crashes Firefox (see below), so I thought I'd give it a miss. All in all it was a very worthwhile session, and here's what I learned:

• You really do need to learn the Unity IDE shortcuts, e.g. Q, W, E & R to switch between tools, F to focus on the selected object, ALT-DRAG to rotate camera around object, drag with right button to point camera.
• We could find no way to look through our camera in the scene view which was annoying.
• If you edit the scene while you have the game running or paused, as soon as you stop it reverts all the changes you made. This is a massive gotcha and you can lose a few minutes work every time you forget your game is running.
• Errors in you game can easily crash the Unity IDE and the browser plug-in. In fact they don't even have to be code errors. For example, in MatrixPong, when the ball goes off the edge of the playing surface, it will fall with gravity for about 10 seconds, then when its position reaches a big number (e.g. y = -1000000000) everything suddenly crashes. For a Flash guy this is a real WTF. Imagine if setting your movieclip too far off the stage crashed the browser!
• You get loads of stuff "for free" in Unity, most importantly collision detection and physics - this is a big advantage over the other 3D game development framework I have played with, Microsoft XNA.
• The documentation for scripting isn't that great and it's all JavaScript not C#, although all the method names are the same so it's pretty easy to convert in your head, you just can't copy paste. C# is a great language, but if you don't already know it, it might confuse you. For example you can't type "x = 1.173" if x is a float. It has to be "x = 1.173f". I have never understood this, but there you go.
• Thanks to Lucas Meijer I was able to set up Unity3D code completion in Visual Studio. Very cool.
• Everything in Unity3D C# extends MonoBehaviour and relies on overriding a bunch of event functions, e.g. Update and OnCollisionEnter. You don't actually use an override keyword though which makes it hard to know from example code whether functions are built-in or not. I couldn't find a good way to get a list of these functions while typing code though, I had to look them up from the website.
• MonoBehaviour has tons of stuff in it and I only scratched the surface of what it can do.
• There's also a big global god object called GameObject where you can find things from your scene. There are lots of global, not very OOP things in Unity. Get over it!
• Pointless observation: MonoBehaviour has a British spelling for behaviour, the first British spelling I have ever seen in a language API.
• I created 3 scripts - PongBall.cs, PongPaddle.cs and PongAI.cs. Each script was only about 5-10 lines of code, but that was enough to get the ball bouncing back and forth, the AI paddle following it and the player paddle controlled via keyboard. You drag these behaviours onto your game objects rather than having game objects that extend them. Objects have scripts rather than are scripts like they would be in Flash. Basically it's like Director, but in a good way.
  
• To devote the necessary time to get really into Unity I would need a paying gig, so could someone please hire me to make something with it? Thanks!

Unity3D for PC - I, for one, welcome our new 3D overlords!

I'd heard this from an "insider" a while back, but now it's official (thanks Ryan) - Unity3D development is coming to PC. 900% more developers should mean 900% more games, which will lead to client and user acceptance of the technology. For some of the work I do, at least, it will mean an end to worrying about poly-counts and clipping bugs, and more time to make cool games! Sweet.