The real question is not whether machines think, it’s whether men do.

In Unity we stand!

Posted: January 28th, 2010 | Author: | Filed under: Soapbox | 1 Comment »
Unity 3D

Unity 3D

So one of the projects I’m currently working on that (being so covered in the traditional game-development shroud of secrecy that I cannot reveal anything about lest they deem it necessary to terminate my immediate existence)  uses the Unity engine for iPhone development. I believe there are also hopes that this may expand to encompass the newly announced iPad.

So how easy is it to create games using this new toy? Pretty easy it seems, to begin with anyway. Grab 3D models from your artists and drag/drop them into your assets folder, and they automagically appear in your editor. Match it with the appropriate texture, add a few scripts to implement behavior, and voila, instant game! At least that’s how the theory goes anyway.

How does it measure up in real life? Not so good, though admittedly, it could be due to the limitations of the iPhone edition, as well as my own relative inexperience with the engine. As I suppose could be expected, there’s the performance limitation for the iPhone. We’re limiting ourselves to 400ish polys for the main characters and 100 or less for environmental objects. The terrain engine is unsupported on the iPhone, so our terrain is merely a simple mesh. Also unsupported are shaders (though there’s said to be some emulation thing we haven’t figured out), and things like stencil shadows. Some developers have apparently been devolving to ancient techniques that from the 80’s to produce better-than-blob shadows.

Then there are other unsupported features like networking. Unity comes with full multiplayer support thanks to Raknet (which incidentally is my favorite network library). However, this is not supported on the iPhone platform. There are theoretically .Net sockets, but my junior programmers have opted to write their own plugins in Objective C, so they can incorporate multiplayer bluetooth support as well.

The GUI system is important because this is a major yardstick for the polish of the game. Unity chose the interesting approach of having their GUI system mostly script based. This makes it very possible to create spiffy animated UIs with all sorts of effects only limited by the programmer’s imagination. There doesn’t seem to be a visual editor for it, so the artists are at the mercy of the programmers to implement their visions. To be honest, I like it this way, as artists seldom have the mathematical background to implement the beautiful movements that programmers can pull off rather efficiently. The could do it with a Flash-like editor, but I guess that is something that Unity could eventually evolve towards.

Scripting happens in a choice of Javascript-like or C#-like languages that run on top of Mono. The team has mostly opted for the Javascript approach because it looks more familiar to most. As far as scripting behavior goes, it is pretty good, and I haven’t found anything glaring to complain about. It gets the job done. I’ve yet to see if we can do more esoteric operations, like programmatically attaching meshes to bones, controlling animation cycles and digging into the guts of the engine. How deep can you go in a drag/drop game editor? That’s yet to be tested!

Overall, I am happy but not. It certainly does the job. I don’t feel like I’ll have as much control over the process as I would with a traditional engine, which is to be expected. The limitations for the iPhone version put a severe cramp on our style, but the PC version looks pretty promising from this side of the proverbial fence.


One Comment on “In Unity we stand!”

  1. 1 Big Red Button Game | e-Goh said at 2:34 pm on February 15th, 2011:

    […] my previous rants on Unity, you can probably tell I am not a big fan.  I would probably still recommend it for project teams […]


Leave a Reply