Longer ago than I would like to admit Packt Publishing contacted me and asked me if I would be willing to review one of their books (‘Unity Game Development Essentials‘), if they sent me out a copy. I agreed, but since I live in Canada they weren’t able to send me out a copy due to the additional shipping costs. Instead they offer to send me out a pdf copy.  I knew it would take me longer to read the book in pdf format (as I hate reading long things on a computer), but I didn’t think it would end up taking me this long. I ended up getting really busy and good book reviews were already being put up online (Everyday 3D and drawlogic to name a few). So finishing reading this book got put on the back burner. I didn’t feel that bad as Packt sent me a pdf, so it didn’t really cost them anything.

That all being said, it was bugging me that I said I would do something and I hadn’t. So the other day I thought it might be good to do a quick book review keeping in mind the Unity 3.0 beta I’ve been playing around with. The reason being that one thing I worry about when buying a book is where or not it will be too out-of-date.

Better late than never, so now onto the actually book review.

First off this is a good book that covers a lot of ground. If you are new to Unity you will learn a lot of from it. It doesn’t suffer from going to fast but is still able to cover everything it needs to. I found the chapter on Particle System particularly well done.

One important thing to point out is this book should not be mistaken as a book for programmers.  This book assumes you know almost nothing about coding and what code is in the book is pretty limited. The code within this book also isn’t always the best when it comes to coding practices (for simplicity). But this is alright if you are new to Unity as there are a lot of things to learn before you can write much code anyway. Just be aware that if you are a serious programmer there will be some sections you might want to skim.

All coding examples in this book are wrote in JavaScript(UnityScript), so as Bartek also pointed out in his review you might find it helpful to translate the code to C# as you go. Not only does this help you understand the code instead of suffering from “copy and paste syndrome” but I do believe that C# is the best language to be coding Unity in.

From a Unity 3.0 Beta standpoint, you should have no worries about this book being too out-of-date. Almost all new things within Unity 3.0 are additions and not changes, so this book will still help you build your Unity skill set.

My only other comment is I found it a little odd that Chapter 2 is focuses on Terrain. I feel that there is a lot of other items that probably should be covered first. That being said I do understand that the reason it is introduced so early is so there is a platform to build upon in the following chapters.

Overall if you are new to Unity and are looking for a book this is one you should definitely check out.

Link to: Unity Game Development Essentials

A few weeks back I got thinking. Would it be possible to have a terrain within Unity deform in real-time? For example if an explosion went off, could it blow a hole in the terrain? I decided this would be a good project to learn the more ‘advanced’ features of Terrains within Unity.

It ended up being more challenging than I predicted, as it was difficult to get the framerate to remain stable while performing these operation. Using a few tricks I ended up getting it to work exactly as I had hoped.

The demo works like this. A script randomly spawns ‘shells’ that fall quickly to the ground. Each shell has an onTrigger collider attached to it. If this collides with a terrain that has a TerrainDeformer component, the shell tells that component its location and the force of the explosion. The shell then instantiate an explosion (supplied by Ben Throop great Detonator framework), and removes itself.

The TerrainDeformer script then translates that position to the correct location relative to it’s terrain and modifies both the heightmap (terrain height) and the alphamap (terrain texture). A bit of math is used to find all the heightmap and alphamap position within the area of the impact circle.

The texture which is used to re-texture the impact area is chosen from the list of terrain textures based on the numerical index value passed into the script (Terrain Deformation Texture Num). In this example it is set to one, so it will re-texture with the second texture in the list.

When creating your own terrains it is necessary for the height of the terrain to be higher than 0 meters so craters can be formed. I recommend a depth of at least 3 meters. This can done by setting the terrain height to something higher than 3 meters, then clicking Terrain->Flatten Heightmap and entering 3 meters.

For performance reasons it is important to keep your terrain size small and more importantly keep your Heightmap Resolution low. In this example it is set to 33.

The current version does have limitations like lack of terrain edge detection and support for multiple terrains. This example is more of proof of concept to show that not only can it be done, but done without much of a performance hit.

Thanks to Calin for creating the dirt texture.

To check out the demo click here.

To get the source (unitypackage) click here.

Source Requirements: Unity 2.6 and the Detonator Framework.

A little annoyance I’ve come across when creating new projects was having to manually add my collection of custom editor scripts each time. Ex: TransformUtilitiesWindow

I found that every time I created a new project I would navigate to my last project and drag all the editor scripts from there into my new project.

I got thinking maybe there is a way to add these scripts to the ‘Import the following packages’ panel when creating a new project. Turns out you can do this fairly easily.

First create an empty Unity project. I called mine EditorScripts. Create a folder within this project and call it ‘Editor’ (editor scripts must be placed in this folder to work). Then drag into this folder all your custom editor scripts. Once complete click Assets->Export Package, and then click the Export button (all your scripts should be checked for them to export). You will then export this package to the ‘Standard Packages’ folder within Unity (Windows: C:\Program Files\Unity\Editor\Standard Package or OS X: /Applications/Unity/Standard Packages – reference link). Once the export is complete, save this project for later use.

Now the next time you create a new project you should see a new item in the ‘Import the following packages’ list (image above).  You can check this package and have those scripts automatically added to your new project.

As you find/create new editor scripts you can go back to the EditorScripts project, added them and re-export the package.

While I personally find this method most helpful for editor scripts, you can use the same process to create reusable and quickly addable packages containing any kind of assets.

So until Unity comes up with a way to share scripts across projects this seems like the easiest and quickest way to add editor scripts that you will need for every project.