Nicholas Francis of Over the Edge Entertainment
To date, we have used this system to build “GooBall,” a 3rd-person driving game/shooting game, a hover bike racing game, and a helicopter prototype. It typically takes us 3-4 man-days from idea to playable prototype — the prototype for GooBall was created in only four hours.
I’ve heard that Unity compiles executables for Mac and Windows. Which parts of Unity are cross-platform?
The Unity Editor is a Mac-only application; it consists of 30,000 lines of Objective-C code, so it’s staying on the Mac. The actual engine, which is written in C++, is cross-platform, so from the Mac editor you can build both a Mac and a Windows game.
Tell us about the shader technologies inside Unity.
All graphics in Unity are driven by shaders. A shader is a text file that describes exactly how something should be rendered. It can contain multiple passes, level-of-detail and versions for different cards. You write shaders from inside the Unity Editor, so you get live updating of your scenes as you develop them. Each shader can export several properties (e.g. colors, textures, floats), so the same shader can be shared between many materials in a game. This makes it simple for graphic artists to work without needing to worry about how something is actually rendered on the hardware side.
Originally, the shading system was open sourced, but since I was never really able to get anyone to contribute code for it, it was rolled into Unity. Today, we use shaders for everything, even for drawing tool handles in the editor. Shaders can either target the OpenGL fixed-function pipeline, or you can write them using fragment programs in Cg, and it will automatically work with any cards that support whatever you happen to use in your shader. This all happens inside the editor as a preprocessing step, so end users don’t have to install Cg.
How easy is it to integrate physics into a Unity project?
Physics is one of our coolest features — we have integrated the Open Dynamics Engine, which is a wonderful piece of OSS software. To use physics in a game, you just attach a RigidBody component to a game object, after which it’ll fall down, happily passing through other objects. When you add a Collider component, it will land on whatever else there is in your scene to collide with.
We then have a range of components that work with this system, adding damage, destructible joints, explosion/blast wave effects. When you want to get your physics object to do something other than being just physical, you need to script it. Here, physics can be a challenge to get right. Often, physics looks and feels so cool that you want to put everything under physics control, but it quite often makes it harder to get in a good gameplay feel — instead of moving your player and the enemies, you are constantly pushing them around. Once you get it right, though, you usually get some great feedback on it.
Do you think Unity is well-positioned to attract the attention of independent developers?
I definitely hope so. There’s a class of hardcore geeks who will never be satisfied with something they didn’t code from scratch. However, for people who just want to sit down and create games, and actually finish them as well, Unity is a very solid tool to utilize. In addition, since so little is hardcoded in Unity, there is a lot of room for cool ideas — the damage stuff is just a bunch of scripts I put together in a few days.
Tell us about the workflow of Unity — for example, from idea to finished game.
Here’s how we do it. We always start with using some common demo assets (programmer art), and do some quick scripts for the player control, just to get a feel for if this game is actually going to be fun. After that, we sit down and do a 2-3 page design brief, outlining the key points of the gameplay. Then we begin in earnest — and this is where the integrated editor comes into play. We can read Photoshop files with all layers, build complete scenes in Maya and import into Unity.
If you want to reorganize your files, just move them about; we store everything in a huge database, so no references are lost even if the files move about and are renamed.
As we build on a game, some reusable components emerge. We turn these into prefabs — objects that are shared between scenes. You can then place them in your scenes and modify them to your heart’s content. If you change the master copy, all scenes are updated automatically! The neat thing here is that we keep track of what you’ve changed in the scene, and don’t update stuff that you have modified. So if you put in your standard enemy and boost his hit-points, you can then modify the standard enemy’s damage. The enemy you place will get the damage parameter from the prefab, but maintain his hit-points.
When you build the final game, we sweep through all the scenes, find out which assets you actually use and only export those in the final app. This last step is so powerful that we kept tweaking our GooBall GDC demo up until 10 minutes before we had to burn the CD. That was so scary, but felt somewhat neat afterwards.
With the release of Tiger coming in early 2005, can we expect to see the use of Core Image to add special effects to Unity-built games?
I’m not sure about it — I haven’t had time to check out the beta, so I don’t really know anything about it. Also, I’m worried about the graphic card requirements. Sure, it’s neat technology, but if it renders your game unplayable for 90 percent of your audience, I’m not sure it’s such a good idea to use. In that case, I would prefer to roll our own lightweight version. In Core Image, it seems that the focus is on image quality. For a game, you might want to sacrifice that to keep it a constant speed. That being said, it might be so cool we just cannot help ourselves. We definitely want to get some type of image-based effects in.
Recently, you’ve made the change from Python scripting to C# scripting. What prompted this change?
Performance! We were occasionally switching to C++ because Python was just too slow — when your code physics are running at 100MHz, you need all the speed you can get. This meant moving to a statically typed language, which basically means C# or Java. Java is really nice, there are many people using it out there; but in the end, C# won. You can write in C# (which is so close to C++ that I don’t think about it when I switch), you can write in JScript, which very much resembles ActionScript in Flash.
At present, we are using Mono, as it is the same on both Mac OS X and Windows, and it has a lot of great features — ahead-of-time compilation, so you get so close to full C++ speed (our Python scripts were running at one percent of C++ speed). They are even implementing Java for it, and if it gets ready we’ll definitely be adding that as well.
Speaking of scripting, I’m interested to know why not something like Ruby or Lua? C# seems so… so Microsoft.
It is imperative to us that we make scripting be as fast as absolutely possible — having to write in C++ is something that just stinks once you’ve tried the three compile-link-execute that scripting supports. This limits our platform choices to C# and Java. Through Mono, we get a fantastic environment supporting far more languages than Java.
So how would you go about adding features to Unity via the scripting language?
All your scripts derive from a class called Behavior. The behavior provides saving, loading, and editing of all your public variables, as well as the important ability to be turned OFF.
You can then override some functions:
- If you implement
Update, you get called once per rendered frame. - If you implement
FixedUpdate, you get called once per physics frame (typically 100MHz). - If you implement
Render, you get a callback for each camera where you can implement custom rendering functionality.
In order to communicate with other components, there are two main methods:
- You can get them (e.g. does my
GameObjecthave a Transform, if so, move it up a bit), call methods and access their properties. - Messages: Components can broadcast messages — if you implement a function called
CollisionEvent, you get precise information whenever your game object hits something.
You can also send messages yourself — our Missile script just reacts to collisions, and sends out an ApplyDamage message to any game objects within a distance. It does not know what the game objects do when they receive a damage message, nor does it care. Some will explode, some will catch fire, some just don’t react to that message and completely ignore it.
How useful would Unity be for 2D games?
Funny you should ask, just today I took out 10 minutes to dream up doing a 2D side-scroller. Well, actually it was more 2.5D. The graphics were 3D but all the gameplay was 2D. To be honest, 2D is not what Unity does best, but it still does it better than anything else.
Can you see any non-game use for Unity?
Unity is designed for making games, but I don’t see any reason why not. When the people who did Flash were coding that, I don’t think they imagined that one day somebody would take it and do a multi-player graphical adventure game with it. That’s one of the cool things about releasing it at an affordable price — just seeing what people will use it for. I’ll be a bit disappointed if all we see is 3D racing shooters based on our pre-made car handling and damage scripts.
Could you tell us some more about your game, Gooball?
GooBall is a very simple game — you have a ball and have to get through several levels within a time limit. What sets this game apart is the ball’s ability to be gooey. It can stick to and jump off vertical surfaces, slingshot round the underside of things and generally do funky stuff. One of our main focuses has been to get a console feeling into it. We’ve kept the game very simple; there are no add-ons or shops, just pure adrenaline and dexterity challenges, combined with a sharp and simplistic graphics style we’re very happy with. We’ve put an insane effort into getting the ball ‘just right’. David has been coding the ball for three months and doing nothing else. Currently, we have the game code mostly complete (just need to do menus, hi-scores and stuff), and are starting the great asset push — this should have us done in October, ready for a Christmas release.
Can you elaborate on the different licensing options for Unity?
Basically, we want to put it into the hands of all the people who’ve so far been staring in bewilderment at the Torque source. We plan on releasing the Indie version at $200-300. This is fully featured (shaders, physics, everything) except you cannot build a Windows game, and are only allowed to distribute electronically.
Then we have the ‘Pro’ license at $1000. This is the same as the Indie, except you can release on CD as well. If you want to release on PC, that’s another $1000. We don’t want royalties with any of these. It’s very hard to find something that’s fair. I think this strikes a good balance, as Indie developers can get their hand on it and do wacky stuff. They can get it out and make money off their creations. If they are going CD or PC version, that means they have some type of distribution lined up, and make money from their creations — hence it’s only fair that we get some as well, so we can keep Unity cool.
When will Unity be released?
Hopefully, we will ship in the first-quarter of 2005. When we decided to release it to the public, a lot of weird things had to be cleaned up. We can live with an engine that has some quirks, but we want it to be accessible and usable from the start, so we’re cleaning up, simplifying stuff, etc. I’ve just started doing the manual — that’s going to take a while to get up to the quality we want as well.
GarageGames markets their AAA level engine Torque at $99, and there are a dozen other engines on the market, even open source projects such as the Crystal Space Engine. How do you feel they compare to your engine?
Torque might have been (possibly still is) AAA, but I haven’t seen anyone doing AAA games except for GarageGames. I think the main difference between Torque and Unity is that with Unity, you get the complete tool chain (that several AAA houses have seen and are drooling over) all integrated into one app, ready to go. With Torque, you get an enormous amount of source code, and have to figure your own way from there. As for Crystal Space… It’s a nice, LGPLed engine; however, you are, as with Torque, completely without a modern tool chain.
Any last words?
We hope to do for the game biz what Apple did for the movie guys with Final Cut Pro — provide a tool that empowers users and makes the Mac the place to be for Indie game developers. If your readers would like to learn more about Unity, please visit OTEE’s homepage.
Since 1998, iDevGames has been educating, supporting and enhancing the community of game developers that develop video games for Mac OS X & iPhone. Subscribe to our