Volume Number: 25
Issue Number: 04
Column Tag: Games

Introducing Unity: The Little Engine that can

Your first step into games development needn't start with a C++ handbook

by Will Goldstone

Most interactive developers these days still seem to take for granted that 3D game development is the reserve of the dedicated C / C++ coder, requiring years of disciplined study and collaboration to break into. In the past few years, a small Danish company has been working feverishly to bust that myth wide open, with their innovative game production package, Unity.

With close ties to the open source movement, Unity immediately comes across as a powerhouse of a package, with all the down-to-earth common sense you'd expect from community driven projects like Wordpress. Utilizing Mono, the open source .NET library, Unity started life in 2003 as a Mac-only package, developed by a 3-man team (then known as Over The Edge Entertainment). Its initial concept was born out of collaboration between developers Joachim Ante and Nicholas Francis, who met online and made their first game engine together for a project they co-authored. In developing the engine, they sought to produce what they referred to as a generic game engine, which later became Unity. With the arrival of David Helgason, the trio resolved to release Unity commercially. Fast-forward to today, and Unity is on the verge of releasing version 2.5 (OSX and WinXP/Vista) and has bases of operation in Europe and San Francisco. Major middleware contracts with Nintendo and Apple tie Unity in with the latest, most innovative technologies that are taking games to a wider audience - the Wii and the iPhone.

Starting with a simple GUI, and concepts that make sense to coders and non-coders alike, the developers of Unity have created a rarity of an application that enables new users, with neither a design nor programming specific background to get started. For students wishing to get into the games industry there often appears to be an insurmountable learning curve, one which few manage to successfully, and indeed enjoyably, scale. Unity Technologies (UT) have tackled that curve head on - creating a set of tools that do not adhere to a particular game genre or development task, choosing instead to put emphasis on ensuring that all elements of their interface make logical sense. With this approach, UT has managed to produce a package that introduces the concepts of game design, and allows the user to implement some of them, without even taking their first step into its script editor. This approach is pivotal to Unity's success, as it takes time to charm the user - inspiring them with enough developmental simplicity at the outset that each new concept learned feels more like a reward than a chore.

Bugs and logic gaps in an interface can be a massive put off, especially when faced with any new software, but with Unity, this is rarely a concern. Whilst being as stable as any competitor, bugs and issues found are more than covered by Unity's welcoming and talented surrounding community. With excellent documentation, searchable scripting guides featuring practical examples and even video tutorials, development in Unity feels more like a "Welcome to the club!", than a conscription. Any question you could have is either covered by documentation, the integrated bug reporter (with genuine dev team support via email), free example project resources or by an army of devoted staff and fans on the forums, wiki and IRC channel (#unity3d on irc.freenode.net).

While still relatively obscure when compared with Adobe or Microsoft packages, Unity Technologies' package is on the verge of greatness. In this article, we'll take a look at how Unity is currently the best bet for developers, young and old, to make the first leap into the fascinating world of 3D game development.

You simply have to look at trends in GUI focused IDEs these days to see that the market for hobbyists and beginners has never been easier to breach. From XHTML web development to music composition, there is a tool available to the everyday user to get them started on their chosen path. Apple leads this trend with products such as iWeb, which has allowed users with no experience of code to publish online content of their own making without writing - or even seeing - a single tag. Unity takes this concept forward - providing a readily integrated environment, powered by a sophisticated game engine behind the scenes. This toolset approach is not a new concept for game engines per se, but as an all-round package for game editing and scripting, Unity does for game development what products like Adobe's Dreamweaver do for web design - providing powerful tools to carry out menial tasks whilst the user concentrates on making a great product.

Taking a different approach to its main competitor, GarageGames' Torque game engine, Unity hides its engine source behind the GUI, letting the user concentrate on getting the game made. With this approach, no time is lost in learning how the mechanics of the engine itself work - placing trust in the Unity development team to maintain the engine - and working with them in requesting new features. Many code purists have criticized this approach, complaining that they would prefer to be able to tweak the engine's source manually, but others have praised Unity workflow highly, stating time saved in development anywhere from months to years.

Historically, approaches like this have proven to be the key to accessing industries previously out of reach of many young enthusiasts. Creating accessible tools that present concepts of production logically should be the responsibility of software teams - this is the best hope for pushing their industries forward as it doesn't exclude the creative talent otherwise put off by elitism and counter-intuitive methodologies.

Beginning with the building blocks of all projects - Assets - the GUI has a Project window (fig.1, no.5) which links directly to the Assets folder of the open project - saving any asset into the Assets folder of the project makes it instantly visible in the 'Project' window, and if changes are made in a third party application it will import automatically when Unity is switched to.

Fig.1 Unity Interface

The Scene window (fig. 1, no.1) is a rendered view of the active scene or level, and what the Unity developer uses to build everything in their game. Using a simple drag and drop from the Project view (which could be compared to the Library in Adobe's Flash), the user can introduce any asset as an active game object by dropping it into this window.

The Inspector (fig.1, no.3) is available to fine tune any game object or asset's Transform - its position, rotation and scale - and adjust values for any other attached components.

The Scene is accompanied by the Hierarchy window (fig.1, no.2) - which displays an alphabetical list of active game objects in the open scene. This allows easier access than attempting to select objects which are not currently in view in the Scene Window.

Completing the GUI are the Game window (fig.1, no.4) and Play controls (at top of the interface), allowing the developer to instantly test their level with on the spot compilation.

The layout of the interface is also completely customizable, and as of the latest release, version 2.5 (in beta at time of writing) features Creative Suite style docking on all sections.

Assets are the items from which the user constructs the game. These can be created within Unity - scripts, primitive objects, terrains, textures, or in third party applications - textures in Photoshop (other image editors are available!), 3D models in Maya, Max, Cinema 4D, Blender, Lightwave (the list goes on), audio in an array of formats - these are the raw materials from which any Unity project is built.

Once an asset is added to a level it becomes a Game Object (GO). These objects are the key to Unity's approach. They can begin life as nothing but an empty object containing only Transform information - Position, Rotation and Scale. GOs can be created empty from the menus in Unity (fig.2) or as fully fleshed out objects such as Lights, Primitive Shapes, GUI elements, Cameras, Particle Emitters and more. These objects however are simply empty GOs with the relevant Components attached to them, making them what they are. For example - a Camera object is simply an empty GO, with a Camera Component, Rendering Components and an Audio Listener Component attached - again this is key to the straightforward nature of the workflow - the user can introduce this object from the scene with the components readily attached and configured - they then have control over the settings of these components to customize the object.

Fig.2 - GameObject Menu.

Components are the core elements of the game engine simplified into game functions; they add behavior, or functionality to an otherwise lifeless object. For example should you want a simple scene set up with a ball bouncing on the ground -

i) Having created the ball and ground (as simple as adding a flat cube and a sphere from the Game Object > Create Other menu), simply add a Rigidbody component (fig.3) to the sphere to invoke the powerful Ageia PhysX engine, which immediately takes charge of the ball, applying mass, and therefore gravity to the ball.

ii) Add Collider components to the sphere and the cube, and the objects will behave naturally when colliding - the ball will fall and rest on the ground.

These two steps would ordinarily take considerable coding effort that ends up as time lost by developers who must either learn how to write physics behavior and script collisions by hand or already know how to do this, but have no pre-built tool to get such menial tasks done quickly. This leaves the user free to experiment with settings (variables) of the components - for example mass of the Rigidbody component - defining how it will fall - adding a Physic Material to it to induce friction (and therefore, bounce). Such settings are all adjustable via text fields, tick boxes and other simple form elements in the Inspector. Put simply, the Game Object > Component system gives the user more time to experiment with style and gameplay, instead of time spent fixing bugs and writing engine source.

Fig.3 - Component Menu, Physics section.

This is just one example of component usage and - bearing in mind that Scripts are also considered as components, the object - component system offers a limitless potential for expansion. Using the example above, we could add the following script to the sphere GO:

var explosion : GameObject;
function OnCollisionEnter (collision : Collision) {
   Instantiate(explosion, transform.position, transform.rotation);
   Destroy(gameObject);
}

Here we simply add functionality that removes the sphere from the game (the Destroy command) when it collides with another object, and the object that is tied to the explosion variable will be created, or spawned in the game world, this is known as Instantiation. Because this variable is declared outside of a function it becomes what is known as a Member variable of that script.

Scripts can be created from the Assets menu, and edited using Unitron - Unity's standalone script editor. With the desired object selected, the script can then be applied from Component > Scripts top-menu, or dragged and dropped from the Project window onto the Game Object the user wants to apply it to.

Once the script is applied, the user is then able to drag and drop the object of their choice to the explosion member variable in the Unity interface. For example we'd likely create a particle system for the explosion - which will be instantiated by the script upon impact, creating the illusion of the object's flaming destruction. The script, once attached, will be seen as a component of the sphere in the Inspector (fig.4), the variable in the script becoming a drop-down or drag & drop setting, awaiting the selection of a Game Object.

Fig.4 - Explosion Script seen as a component in the Inspector area of the GUI.

Comparable to Movie Clips in Flash, Unity's Prefabs are effectively saved Game Objects which are built in the Scene, and saved to the Project window, to be cloned, or instantiated later. In a game, the exploding sphere could be a bomb being dropped, but the user would want to drop bombs many times, and at their chosen moment. Therefore this item would be built in the scene, and the components it requires would be added, and then this would be saved into an empty 'Prefab', which can easily be created from the Project window. The original copy is then deleted from the scene and multiples can then be created from this Prefab.

Any Unity Project begins with the Application creating a root folder for the project, and within this, child folders called Assets, Library and during runtime, Temp. Making a new project with Unity means either starting from scratch, or as most new users will do, importing the Standard Assets (or Pro Standard, using the software's pro license) package available in the new project dialog. These free-to-use assets are a great starting point for the new user, and are prime examples of the kind of assets essential to getting started with game projects. One such example of this is the First Person Controller prefab, which is a ready-to-use first person player, complete with camera component, control scripts and a Character Collider for game world interactions. Touches like this give the beginner an ideal kick-start into production, as they can reverse-engineer such assets, observing the combinations of components with mind to understanding game mechanics.

With Assets at the ready to build the game, the developer then creates each level (or Scene), of the game, either placing objects into the scene for its start - an environment for example - or instantiating new objects during runtime using the Prefab system.

In building a rocket launcher, for example, the developer would save the missile model into the Assets folder of their Unity project, then return to Unity and drag and drop from the Project window (the mirror of the Assets folder) into the Scene. They would add scripts, and other components managing the missile's behaviour, to the Scene either by dragging and dropping, or by selecting components from the main menu. They would make a new prefab in the Project Panel, name it "missile" and then simply drag and drop the item from the Hierarchy (a list of items in the Scene) onto the new Prefab in the Project panel. The original instance is then deleted from the Scene, leaving a duplicate with a full set of behaviours attached (velocity, collision, etc.) that can be instantiated at any time.

With a developmental approach that lends itself to completely expandable ways of working, Unity lets the developer effectively build their own tools within the Inspector. The developer can choose to write scripts in either C#, Javascript (albeit Unity's own variant) or Boo (a variant of Python), the Member variables of which can form parts of the Unity GUI itself, allowing them to instantly adapt Unity to their own way of working. Scripts may also address any component attached to any object by referencing the component name, and choosing a command from the Behavior class.

Lets look at a simple example. With the following script (in Javascript), we'll allow a First Person Controller object to interact with another object - a 3D house model, featuring an animated door.

The script begins with 5 variables, all with datatype declarations; the first two of which also have set values within the script :

private var doorOpened : Boolean = false; 
private var timer : float = 0.0;
private var theHouse : GameObject;
var doorAudio : AudioClip;
var doorShut : AudioClip;

Variables such as these will appear as component parameters in the Inspector, however, given that doorOpened (a Boolean; true/false switch), theHouse (an object reference) and timer are only used locally within the script - they are not something the user will adjust - the private prefix is added. This stops them becoming Member variables, so will not be shown in the Inspector, to avoid visual clutter. The final 2 variables are Members, and will require assignment of objects of their specified data type in the Inspector (fig.5).

Fig.5 - Player Collisions script awaiting two audio clips to be tied to Member variables.

The first function in the script is Start(), which can be used to assign defaults for the first time the script occurs in each scene. Such defaults are utilized within the rest of the script, in this instance, it is used to set theHouse variable:

function Start(){
   theHouse = gameObject.FindWithTag("house");
}

Utilizing the FindWithTag command, the script assigns the object with the tag house to the private variable theHouse, declared earlier. Similar to the Instance Name concept in Flash, tags are assigned to objects in the Inspector (fig.6), and are simple ways to refer to them within scripting.

Fig. 6 - Assignment of Tags with the Inspector.

The script then features a function specifically for Character objects, called OnControllerColliderHit(), which registers all collisions with other objects, allowing the use of IF statements to check for particular objects:

function OnControllerColliderHit(hit:ControllerColliderHit){
   if((hit.gameObject.tag == "house1door") && (doorOpened == false)){
      openDoor();
   }
}

Upon collision with an item tagged house1door, these conditionals will run the openDoor() function, if the doorOpened variable is false. This means that the user simply has to tag the door child object of their house model with this tag, and the collision detection will trigger the openDoor() function :

function openDoor(){
   doorOpened = true;
   theHouse.animation.Play("dooropen");
   audio.PlayOneShot(doorAudio);
}

This function sets the doorOpened variable to true, which avoids retriggering the function in the collision detection earlier in the script - without this, the door could accidentally loop opening, any time the player collides with it. The second command finds the animation component, on the object applied to variable theHouse, and plays an animation named dooropen. The user specifies these animation names on models in the Inspector, having selected the particular Asset in the Project window (fig.7).

The dooropen animation within the original house model occurred from frames 11 to 40, and by simply informing Unity of this timeline information, scripts can pick out the particular frames and play them, using the name parameter. Finally, the openDoor function plays the audio file assigned to the doorAudio variable, using the PlayOneShot command.

Fig.7 - Animation clips can be added or deleted, and frame positions altered in the Inspector for the asset.

With the door open, and by consequence the doorOpened Boolean switch set to true, Unity's Update() function comes into play. Checking every frame, Update() could be likened to EnterFrame in Actionscript, and is where the user places commands or listeners that require constant attention. In this example, Update() is employed with two IF statements, the first listening for the doorOpened boolean to become true and the second for our timer variable to have counted five seconds:

function Update(){   
   if(doorOpened){
      timer += Time.deltaTime;
   }
   if(timer >= 5){
      shutDoor();   
   }
}

The first IF statement is simply present to add to the value of timer, which it does so using the Time.deltaTime command - in simple terms, a real-time counter running independent of game framerate. Upon reaching 5 seconds, the second IF then triggers the final function, shutDoor() :

function shutDoor(){
   doorOpened = false;
   theHouse.animation.Play("doorshuts");
   audio.PlayOneShot(doorShut);   
   timer = 0;
}

This function effectively cleans house. It resets the Boolean switch, plays the door closing animation (and its accompanying audio file), and resets the timer back to zero. Now the player is free to collide with the door again, causing the whole process to start from scratch.

By building simple behaviors, which address parts of Game Objects as components, scripting for Unity is straightforward and, crucially, fun to learn. For beginners who may be unfamiliar with scripting, the forgiving Javascript syntax is a big plus, and those thinking of making the leap from Flash to 3D development will find the similarities in concept and execution most beneficial.

Whilst other game engines keep their game world editors separate from compilation and debugging, Unity believes in one application to rule them all. With its Game window and play controls, the developer can compile almost instantly and test the open scene as it will look when built. The advantages of this are obvious, and make testing and experimentation with gameplay a joy. Having the ability to play, stop, alter values in the inspector is good enough but Unity goes one step further, invoking a full Play mode. This means that at soon as the game is being tested, any values experimented with in the Inspector, become part of that test.

For example - the user want to test an enemy's line of sight in a shooter. Pressing Play activates the Game window, and the user can test enemy response. However, without stopping the game, the user can adjust variables in the Inspector and see results instantly in the Game window. This way, the user is able to try out a number of different adjustments - and if they forget what changes have been made, the settings revert as soon as Unity is switched out of testing mode. Another great example of its emphasis on experimentation in practice.

Building a game project is the act of constructing an executable version of the game. In putting together a build of any Unity game, the Build Settings (fig.8) offer several options. Having started life on the Mac, Unity is well prepared to offer builds in Mac PowerPC, Intel and Universal Binaries. In addition to this, there are Windows Standalone, Web Player (standard, and with server streamed assets), Dashboard widgets, and with the relevant licensed add-ons, iPhone and Wii. This dialog then offers one-click complete compilation and build export in one - the user simply selects the levels (or Scenes) required in the build, and clicks 'Build'. Simple, effective.

Fig.8 - Build settings allow compilation of an entire Unity project into various deployment formats.

With 2008 having already seen several point releases and new features / deployment platforms being added to the Unity package, the future looks bright. A key factor as far as many are concerned is the leap to the PC, which could be a tipping point for Unity's potential in the development tool market. Whilst I've witnessed many companies reporting the purchase of a Mac purely for Unity, it is certain that many production houses will have unfairly overlooked Unity in the past few years due to its Apple roots. With version 2.5 due out in early 2009, Unity makes its first step onto XP/Vista. Having fixed many bugs, and added new features, plus an interface overhaul (although the interface's features remain the same as shots in this article), the latest version should see the buzz around Unity explode with their newfound market in PC users.

Having taken their time to work Unity up to a reliable, intuitive standard before heading to the PC says more about the UT team than any review - meshing business sense with a knowledge of their audience should see Unity's popularity snowball as new users line up to discover that at last, they too can be a game developer. Here's hoping that a new generation of creative people discover this excellent tool and point the future of gaming away from endless FPS games and towards one with more Katamari Damacy and Little Big Planet.

Although this article has barely scratched the surface of what Unity can do, hopefully it has shown you a little about how it works, and how it makes my life and many developers/lecturers' lives easier and more fun. What is also worth noting are the things that space constraints have forced me to omit. I haven't had time to praise the excellent Terrain Editor and its height/texture painting, the excellent in built render effects, network gaming, asset server, plug-in system, and masses of freely downloadable content/expansion available on the wiki - but why not find out for yourself, and give the trial version a spin? Unity3d.com.

Will Goldstone is an interactive designer and lecturer based in Bournemouth, on the South Coast of England. You can get in touch with him via will@willgoldstone.com.