Unity Components: Scripts

One of the things I really enjoy about Unity is the way the engine handles objects in the game world. Everything you add to your game scene is inherently a Game Object, which is a data type built into the engine. The interesting part is the ability to attach different Components to any Game Object. For example, going to GameObject > Create Other > Cube will spawn a cube object in the scene with four pre-defined Components attached to it: Transform, Mesh Filter, Box Collider, and Mesh Renderer. But really it’s the same thing as if you had gone to GameObject > Create Empty and added those Components to the newly-created object manually. If you need to, you can even remove most of the Components. This allows a wide range of customization options for game objects within Unity.

Scripts are also considered Components that can be attached directly to Game Objects. They essentially provide the developer the ability to manipulate an object by giving allowing more control over it via a programming interface. From within a script, the developer can access any part of its parent Game Object, including its other Components and their properties.

Since all components except scripts have pre-determined names, accessing them through a script requires the knowledge of each Component’s corresponding property name within code. The entire list, along with every Component’s description, can be found in the official Unity documentation, but here they are in a nutshell:

  • Transform is accessed as transform
  • Rigid Body is accessed as rigidbody
  • Renderer is accessed as renderer
  • Camera is accessed as camera
  • Light is accessed as light
  • Animation is accessed as animation
  • Collider is accessed as collider
Script Example
Accessing the Mesh Renderer Component attached to this script's Game Object when the object is created at run-time.

In order to access another script on the current object, you’ll have to refer to the name of the script directly by passing it to the GetComponent method. For example, if I want to access the “CharacterController” script but I’m currently in the “Main” script, I would use GetComponent(CharacterController).propertyName.

Accessing Other Scripts
Use the other script's name in order to access it.

In the example above, you can see references to several components and properties within the thisOre GameObject. Its x- and y-coordinates can be found within the Transform Component attached to the object. Those properties are set to variables that have been determined in other locations, one of which is the height variable that is only accessible by retrieving it from thisOre’s “ICOre” script.

Scripts can access not only the Components within the Game Object to which they are attached, but also any Game Object in the scene. This essentially allows the developer full control over any aspect of their game, through code. There are many ways to access other objects. So far I’ve found that GameObject.Find and FindObjectOfType have been reliable for accessing specific objects and scripts, respectively.

Accessing Other Objects
Any object or script can be referenced easily when needed.

Being able to reference the properties and methods of Components within a script’s corresponding Game Object, as well as the properties and methods within other objects’ Components is vital for maintaining full control over your project. Luckily, Unity makes such things very easy to do, with clear instructions right on their site.

Finally, one of the best things about Unity’s scripting is that it allows any of three languages: JavaScript, C#, or Boo (a dialect of Python). As I come from primarily an ActionScript 3.0 background, it was a great surprise to find that writing in JavaScript is almost identical to the way I do things in AS3. I would imagine that other programmers who are interested in Unity but could be wary of having to learn an entirely new language may breathe a similar sigh of relief.

The Decision to Use Unity, Part 2

So, what makes Unity better than the other game engines, in our eyes? That’s what I’d like to go over in this post. There are several reasons Matt and I chose Unity as our game engine for Jestermen’s first project, “The Infernicore”.

Its Simplicity

Unity's UI
Relatively simple, but effective!

Unlike quite a few other pieces of software I’ve used, Unity’s interface is exceedingly simple. It is intuitive, easy to use, and allows the user all of the options he or she needs without requiring row upon row of toolbars and menus. In fact, there are only five main panels within Unity: Scene, Game, Hierarchy, Project, and Inspector. The Scene panel displays the game assets during construction; easily navigable using common keyboard/mouse controls (such as holding Alt + dragging with left click to rotate the scene). The Game panel offers a view of the game as the user would see it; in fact, by simply pressing the play button at the top of the interface, one can immediately begin playing the game. The Hierarchy panel lists all assets that are currently in the scene. The Project panel displays every file that is in the Assets folder of the project for quick access to dropping any of them into the scene directly. And the Inspector panel simply waits for you to click on something, at which point it will display all properties associated with the clicked object. Of course, there are other buttons and menus, but the point is that none of them are vital to the core development process, which is why it was a smart move to keep them hidden until they’re needed.

Its Target Platforms

Unity 3D version 3.5 offers a new publishing option which has a potential that is quite difficult to overstate. Its ability to build projects directly into SWF files that automatically run in Adobe Flash Player means developers who want to distribute their content through the web no longer have to worry about whether sites support the Unity Web Player. And now that Flash Player 11 has a new 3D graphics rendering engine, the fact that Unity creates 3D content is also not a problem.

Unity 3D Build Settings
So many options, so few clicks!

Flash Player support isn’t the only upside to Unity’s publishing potential, however. The fact that it can build to so many different platforms without modifying a single line of code, as well as the ability to switch between target platforms with the click of a button (literally, just one button!) should be even further cause for excitement. PC standalone, Mac standalone, Flash Player, Unity Player, Android, iOS, XBox 360, PlayStation 3, and Wii build options are all supported.

 

Its Robustness

As if simplicity and distribution potential weren’t enough, Unity comes packed with enough features to make one wonder exactly why the entire program doesn’t require a purchased license in order to use it. For example, its built-in physics engine means developers don’t have to spend time messing with things like gravity and collision detection unless they really want to. Simply use the included script editor to apply a script with an OnCollisionEnter function. If more information is desired, the full documentation for every aspect of Scripting in Unity can be found on Unity’s website. JavaScript, C#, and Boo are the supported scripting languages. For the full list of features, look here.

What’s the downside to all of this? Surely it sounds too good to be true. I thought the same thing myself. And while I’m not exactly an expert Unity developer yet (I’ve only been using it for a couple months at most), I think I’ve seen enough to know that the pros greatly outweigh the cons. But as far as I can tell there is only one major con: the cost. Most features are present in the basic version, but building to anything except PC/Mac standalone and the Web Player will require a fee of some kind. Building to Android or iOS requires a $400 license for each. The Pro license costs $1500. And when version 3.5 comes out of public beta, publishing for the Flash Player will also require a fee. Jestermen encourages anyone to snag the basic version and actually develop something first, though. That’s what we’ve done, and we fell in love with the program. Try it and see!

The Decision to Use Unity, Part 1

Before Jestermen was even conceived, I had created a relatively simple Flash game that we have since renamed “The Infernicore”. I actually finished it in one week flat, and immediately uploaded it to Newgrounds. At the time it was just a small personal project based on what I thought was an interesting game mechanic. I didn’t even plan on converting it to a mobile app, much less make any money off it. So there it sat (and still sits!) until Matt and I decided it would be a good idea to push that sucker onto an app store.

Naturally, I figured that since the game was already done in Flash, and Adobe started supporting publishing for Android and iOS directly, I would just use the intended workflow to publish an app file using AIR in the Flash IDE. Long story short, I was quite disappointed to see that the performance on my Motorola Droid was far less than satisfactory. I spent hours trying to optimize the game, eventually coming to the realization that the problem most likely was not in my code; rather, it seemed to be that the graphics were not rendering fast enough. The slow frame rate completely eliminated the possibility of using AIR for Android with this particular application. Now, I’m not going to claim to be an expert on the subject, but I think I was diligent enough in my research that I could safely disregard the Flash/AIR route without any regrets.

AIR Render Mode GPU
Nope, didn't work.

With the project deadlines looming (yes, multiple deadlines; we set high standards for ourselves!), it quickly became less and less of a good idea to continue spending time trying to fix the Flash/AIR problem when I wasn’t even sure the problem could be fixed. So I decided to take my chances with a completely different engine. The only question was, which engine should I choose?

A quick Google search turned up a myriad of Android game engines, each claiming to be the right tool for the job. Among the more popular options included AndEngine, cocos2d, libgdx, Corona, Google App Inventor, and, of course, Unity.

AndEngine, cocos2d, and libgdx are purely frameworks; they’re code bases that will appeal only to those who are comfortable with programming. No visual IDE is included with them, which would have been fine except for the fact that proper documentation was either non-existent or perpetually out-of-date. Since the repositories are updated almost daily, bad timing could spell disaster for those who want to learn how to use them without having to spend hours sifting through old video tutorials and forum posts that may or may not be relevant to the current builds. Unfortunately, such was the case for me. Of course, I could have just opted to use a previous, more stable version of any of the repositories, but I decided to keep shopping around for the time being.

Hardware Acceleration Direct
Also no good. Curse you, Flash!

Corona is also just a code repository, but publishing using Corona comes at a premium. When I first learned about it I didn’t realize that it was possible to download the SDK for free, but by the time I learned that, we had already chosen Unity as our new engine. In any case, Corona may offer some potential, but it’s going to have to sit on the sidelines for now.

Google App Inventor was really user-friendly and simple. It used a completely visual, browser-based interface (no coding at all). In lieu of programming it offered a “blocks” UI, wherein the user simply created and snapped together blocks that represent variables and functions. But despite the satisfaction that came with the clicking digital jigsaw pieces into place, Google App Inventor had (at least) one fatal flaw: the inability to create objects at run-time. Obviously, such a limitation is a deal-breaker if one desires creative freedom in his or her games.

Finally, we’re left with Unity. There are many reasons that Unity stood out amongst all of the other engines, and I’ll get to them in my next post.

Unity 3D Logo
The end-all be-all of mobile game engines?

From Flash to Unity

I currently work as a full-time ActionScript 3.0 developer, utilizing Flash Professional as my primary IDE. Since I’m so familiar with Flash and AS3, along with the fact that there are so many Flash games on the Internet, I figured it would make perfect sense to use Flash for developing my own mobile games outside of work. After all, Adobe themselves began official support for doing just that not too long ago. Unfortunately, however, even with the supposed performance gains touted by proponents of the new Flash Player 11, I’ve found that my relatively simple game just won’t hold up on physical test devices. Despite poring over tutorials and Google searches about optimizing for mobile (yes, I tried directly accessing the GPU!), I came to the sad conclusion that it simply wasn’t meant to be.

But this post — and the next several posts, in fact — isn’t going to be about my frustrations with Flash. Instead, it’s going to be about the mobile projects my good friend Matt and I are making with another engine: Unity 3D, along with its apparently good friend, Blender!

I’ve actually known about Unity for a few years now, but I never took the time to look into it very closely. Upon further inspection, I have to say that I’m really impressed with how it combines such a simple, easy-to-use UI with so many powerful features. One of those features is supposed to be its compatibility with Blender. Over the next few weeks, Matt and I will be exploring the Unity-Blender-Android relationship in an attempt to complete the first Jestermen project: The Infernicore!

Look forward to progress updates, detailed development notes, and maybe even a few tutorials while we continue with the game’s production. Some of the primary topics I’ll be covering include the following:

  • The Unity interface
  • Importing Blender assets into Unity
  • Programming in Unity
  • Unity’s vast publishing options
  • And, of course, my day-to-day experiences with the entire workflow