One of the things I’ve been dying to play around with lately is Unity 3D, the game engine.  I’ve worked in game mods before, but this was years ago and I functioned in the capacity of artist or sound engineer.  Well time goes by, and I’ve become a pretty serious coder.

I had the good fortune of speaking with Joe Santos at the Unity booth at the recent GDC, who gave me a little walkthrough of how the tool works, as he was quite knowledgeable on the subject.  Through the remainder of the show, I kept hearing people speak of Unity, so I finally got around to downloading the evaluation version, and I have to say my first impressions are good.

Unity comes with a pretty nice IDE, and a scripting tool that would not intimidate anyone who has worked in Flash or simillar tools.

The IDE

The IDE is very visual, and nice to work in.  I believe this is one of the strongest points in favor of Unity.  Most of the action takes place in a game view, and a scene view.  Scene view is where you actually move things around and select objects – it can be rendered as a mesh view, textured, or a combination of both.  The game view is where you can review the status of your scene, and it comes with play/pause buttons.  Enabling the animation in your scene is as simple as hitting play.  One awesome feature is that you can actually tear off that game window and stick it on another monitor if you like.  I found this good because I would sometimes get confused when reviewing the game action and go to move my pointer over to the other parts of the IDE to change a setting.  Having the game view torn off just separated it more clearly in my head.

Of course you can select many configurations for the scene view, and how you choose to arrange it will likely have to do with how much screen real-estate you have.  More is always better.

You’ve got your gizmo in the scene view that allows you to quickly look at your objects from any angle.  You can grab the objects by their meshes and move, rotate, scale them as you wish and this part works a lot like 3DSMax (scale on any axis by selecting it, or scale uniformly by mousing on the middle of the gizmo).  Use the mouse wheel to zoom in and out.  Speaking of finding and grabbing objects, there is a great way to do it in Unity.

Unity Hierarchy Panel

In the IDE there is a panel called the Hierarchy.  This is a list of all the objects in the scene, and a quick visual reference as to how they relate to each other.  Using it, you can quickly find any item in your scene (which can get pretty full of objects).  In the Hierarchy panel, you can just select the object, then when you mouse over the scene display, press “F” and the scene will automatically move to the object and center on it, and the object will be selected.  This is a big lifesaver.  As you get more used to Unity, you’ll find that the Hierarchy panel can also be used for parenting one object to another very simply, or to attach a script to an object.  Scripts control the behavior and logic of your game.

A second important panel is the Inspector.  This panel is very similar to the panel in Flash of the same name.  All objects, behaviors and such in your scene have properties associated with them.  These properties are exposed by the inspector and can be manipulated there.  One nice thing is that these properties remain exposed even while the game is in “play” mode, and you can actually change them and see the result on your objects right away.  This makes it very easy to tweak small points in your animation.

The other major panel is the Project panel.  This is where all the assets of your scene get revealed.  I have to say that Unity has one of the most brilliant ways of handling asset imports that I have seen.  Essentially, you set up an asset folder in a particular location, and if you drag anything in there in your OS that is supported by Unity, it is imported!  Unity seems to be able to dynamically notice changes in this folder.  For instance, if you have a texture in there that is applied to a model, and you edit that texture in photoshop, as soon as you save it the texture is updated in Unity, with no need to refresh.  Very nice and simple.  One nice thing I noticed about the project panel is that all of your scripts get placed in a folder there.  This is pretty handy, because I can easily imagine that your scripts could get pretty scattered around otherwise, and be hard to find.

Between these three panels of the IDE, you can do quite a lot.

Scripting

Scripting in Unity is accomplished via some very well known languages, Javascript and C#.  There is also another one called Boo, but I must confess I have no idea where that language comes from.

You can script in any editor you wish, and you can set a preference as to what editor you like.  Seems like Unity originally had a proprietary scripting tool, but it now ships with Scite, which is quite well known, and a good editor overall.  I’ve heard that someone updated FlashDevelop to work with Unity, and that tells you something about how popular the engine is getting with Flash people.  I can see why.

The scripting reminds me a whole lot of AS2.  In fact a lot about Unity reminds me of the way we did things in Flash 7 or 8.  In other words, you attach your scripts directly to your game objects, and they have the ability to call functions based on frames passing in the scene.  Depending on how many frames pass per second, you can create animation within the function.  There are yet more parallels – prefabs in Unity are a lot like MovieClips, just more powerful and all 3D-like.

The “update” event of Unity is a lot like an EnterFrame in Flash, however Unity (being focussed on games) has the aditional nice feature of a Time class that keeps track of DeltaTime – the amount of time that has passed between frame executions.  This is very handy, as I’ve seen a lot of code written to keep track of this and accomodate for it in animations to make the animation smooth-looking.

There are events and event-handlers (and these must start their names with “on”). Functions are defined with curly-braces as one might expect.  Classes and script names are capitalized.

Anything that can be attached to a game object, such as scripts, are known as components in Unity.  Many game objects have components attached to them automatically, and these can be accessed by member variables to affect certain behaviors on the object with your script.  Multiple components can be attached to one game object, and interestingly there is a getComponent method that can be used by any of those components to find another component attached to the same object.  The calling component can then execute a method on the found component.  Not sure how I feel about that, as it seems a bit messy and an odd way to handle scope, but we’ll see how I like it as I play around with it.

Earlier we mentioned that you can parent one object to another in the Hierarchy panel.  This is handy in the script world as well, because there is definitely a displaylist at work in Unity.  Essentially all game objects exist in a hierarcy – some objects are parented to others, all the way up to the scene they exist in.  Every object has a Transform component associated with it that keeps track of position and scale.  Using the hierarchy and the transform components associated with them you can iterate the displaylist and find any game object.  This is powerful.

You can also find game objects through a tagging system (which essentially is the name of the object).  Hard to say what might be the better way of doing things, but I think I favor the first method, as it seems less prone to human error that might be introduced through the Inspector panel.  As mentioned, once you’ve found a game object, you can find any components associated with it, and call methods in them.

Lastly you can also get references to other game objects through events handled.  In other words, much like AS3 if you handle an event, you can look inside that event to see where it originated from.  Now you have your object reference, you can look for components on the object, and execute methods of the components.  (Components should be thought of as classes)

Handling of variables in your component-classes seems pretty straightforward; variables declared in functions are accessible only to functions.  Variables declared outside of functions are member variables.  Member variables can be marked private, or can be static.  Note that you can not edit private variables in the inspector while the scene is playing, unlike other variables.

Make a new game object dynamically with the Instantiate keyword.  I wonder if a factory class is a possibility?  For that matter I wonder about a lot of things like that, it’ll take a while to figure out the best way of organizing code.

Logic, loops, etc.

It seems like loops and logic work pretty much how one might expect them to in a JS based language.  The one thing I hadn’t seen before was the “yeild” keyword.  This allows a method to continue from the line after the yield keyword the next time it is called.  Very interesting.  It means you can essentially change the behavior of a method on a per-call basis depending on how far through the method the instructions are executed.  Looking forward to playing with that.

Compiling

Unity compiles all scripts to .NET dll files.  These get jit compiled by the player at runtime.  This makes for wicked-fast javascript (or just a little chuggy C++).  This is plenty enough speed for some very good games.

And thats the Oddly first view of Unity.  Looks like piles of fun with a not-so-heavy entry point for anyone who has worked in an ECMA language, and perhaps has some familliarity with tools like Max or Maya.

I’ll let you know how my experiments go!

While on the west coast, I recently had the chance to take in the Grad show for the Art Institute of San Francisco.

This is an institution that is producing some very high quality graduates, so I was excited to have a chance to speak with colleagues from their school.

The graduates handled themselves very well.  All seemed very prepared to speak about what they are passionate about, and it was nice to see the level of enthusiasm they displayed.  I spent the majority of my time looking over digital media projects and concept artwork, but I did have a chance to browse the fashion and interior design submissions as well and was equally impressed.

While there, I was able to award one very grateful student with a pass to GDC, sponsored by the good people at Sony Playstation.  I was also onhand for the awards ceremony, which you can see below in my admittedly blurry picture.

Art Institute Graduates

Check out the awesome pic below of me outside of the Blizzard booth at GDC.  This pic was snapped for me by one of the wonderful ladies from the Sony Playstation team that were neighbours to Blizzard.

Tim and Blizzard

I’m a fan of Blizzard’s games.  I’ve played them all, and as much as it pains me to wait for a new release, I do so with the knowledge that everything Blizzard releases is awesome.  They take their time to do it right, which is something to really respect about the company.

That didn’t stop me from trying to wheedle some insider info out of the staff regarding the upcoming release of Starcraft!  All of us in the shop are anxiously awaiting that one, and we even pulled out classic Starcraft to have another go at it.  You know what?  After all these years it is still a great game.  That says something right there.

Alas, I came up empty handed, so no extra scoop on the Oddblog.  We’ll just have to wait like everyone else.  Booo….

I certainly learned a lot from attending GDC this year.  I somewhat feel like I have enjoyed a glimpse of  what is to come, and that might not be entirely unrealistic.  Video games have always been the field that has pushed forward the technology of home computers.  They are what makes us need more processing power, more graphhics capability, more memory.  This in turn leads ultimately to the establishment of standards for the hardware and software driving these increased capabilities.

Onlive Gaming service

For console gamers, I saw the OnLive service, which looks to me like it could make great inroads to the gaming industry.  This is a subscription  service that works through your internet connection to let you play your favorite games.  It works much like a thin-client.  The only hardware you get is a very simple and tiny box you plug into your high-speed  connection.  It has a USB port, and you just plug in a couple of controllers.  Go online, and you’re gaming!  And they have some good titles lined up too.
You can bring your box with you and plug it in anywhere.  The  OnLive service has  created proprietary compression techniques for streaming the gameplay to you, and as a nice addition lets you screencap video of your gameplay for bragging rights (or shame).
The only thing I can see slowing this service down might be physical hardware limitations – users can not be located that far from the servers running the games.  And I imagine those servers must be pretty darned kickass.  It boggles the mind to think what kind of computing power would be going on if a half million people were playing at once.
Still, if it flies well in the test areas in California I can’t see much holding them back.  I spoke with friends at the major console publishers, and they confirmed that they really don’t make anything from console sales.  In fact, manufacture and sale of the console itself sometimes runs at a loss – the industry is that competitive.  Where they do make money is on the games themselves, and I could  see a service like OnLive providing a more predictable revenue stream in that regard.
The service  is set to launch with PC games initially, but will run them cross-platform (use your PC, Mac, or the little box they provide).  No word yet on what the service will charge or exactly where it will be available.

Speaking of increased computing power, the trend toward multiple cores will continue, not just on the CPU but on the GPU.  This is both good and bad.  Applications  that require very heavy computing will benefit the most, but less intensive tasks will not see much of a boost from more cores.  Proper multi-threading across multiple cores will be key in taking advantage of upcoming hardware.  GPUs will start to get used more and more for tasks outside of just graphics.
OpenGL will continue to be strong against DirectX, mostly because of the rising popularity of smart mobile devices.  Being able to build once and deploy across  many devices is the golden goose everyone is chasing, but it is not likely to happen just yet, and even if it did the many input methods of smart devices will still demand heavy modification of most applications.

The Flash Player is the cat that got out of the bag.  I spoke with four  separate companies that were either working on, or had already, accelerated  versions of the Flash Player capable of using OpenGL.  And the gentlemen of the Khronos group said outright that Adobe’s Flash Player would have OpenGL.  Makes sense when you realize that other companies have already done it for specialized purposes (like games).

I do somewhat wonder if the Flash Player is late to the party for accelerated 3D  on the web though.  There were three companies showing very sophisticated browser plugins playing fully accelerated OpenGL-based applications.  Two out of three had pretty sizable developer communities around them and were showing off great games.
The point is, OpenGL is well on its way to the web, either via an  accelerated Flash Player or something else, and guys who develop for the web,  if they have never looked into it, would be best to do so.  And hey, in the meantime you might make some fun iPhone stuff.  As an aside, all three of the companies mentioned above have the ability to port their apps to the iPhone with the press of a button (but you’ll still have to write some code if you want to make use of some of the unique input of the iPhone, and you’ll want to plan ahead for an  interface that works when a hand is sitting in front of the screen).

There is a lot of room  out there for design  companies that can design across multiple screen sizes and interfaces.  The fine art of liquid layout has never been more important.  But it goes beyond that into the realm of designing more specific to not just screen size, but hardware capability and input interface.  A company that understands the difference between a good application on the iPhone, a smartphone, a PDA, netbook, laptop and desktop and who can establish a pipeline that supports all will be very well positioned indeed.
Of course I have to mention Flash again.  It seems to me there is a lot of room for Flash as a rapid prototyping tool.  I’ve used Flash many times to spin off a quick prototype of a possible interface, and it is very good in this regard.  I can see a lot of companies appreciating the ability to visualize layout and interface design specific to the devices they wish to support at the design stage of their projects.
And of course, if flash is finally able to expose OpenGL to the developer (and dare we wish for multi-threading??) perhaps it will achieve the ubiquity across devices that it has across browsers.  And that would be good for everyone.

Meanwhile, 3D for the web is here, it is married to 3D on devices, and there really is no reason to not dive in.  The price of admission is learning some new tools, knowing some close-to-metal code, and getting familliar with some open standards.  But these are good skills that would see any programmer well off for years to come.