Mostly Tigerproof

Today I was walking along Courtenay Place and caught a scent that I hadn’t smelled in a long time. It brought back the strongest memories of old video arcades, Ghosts ‘n’ Goblins and pinball machines. It was like MAME had come to roost in my head for a moment.

When I tried to figure out what I was smelling, I realised it had come from the pokies machines in a pool hall that’d walked past. I still can’t pin down exactly what it was. Pine chipboard cabinets riddled with borer and marinated in tobacco smoke? Maybe I can just smell the coin-op?

One of the things I’ve been screwing around with is Unity 3D. Unity is a heavily data-driven game engine with an integrated level editor.

It’s so heavily data-driven that all the game code is written in script and the native code layer is almost entirely hidden (only in the pro version C++ plug-ins can be created). The engine contains most of the systems you’re likely to need for a game: 3D rendering with shaders, a level editor, a 3D asset pipeline, a physics engine, a rudimentary GUI system, network state synchronisation and RPC.

Unity is the subject of all kinds of hyperbole around the web. Back when I first heard about it, I wondered how much of the praise was down to Mac-heads who were simply delighted that the authoring tools were Mac-only. Since then, they’ve ported the tools to Windows and I’ve discovered that it really is pretty damn nice. It’s extremely quick to learn – I had a playable prototype of the game mechanic that I was trying out on Day 2 of using it.

Unity’s greatest asset is its clean design. It has a beautiful component architecture where you write update methods and event handlers in script, encapsulate them into component objects and then assemble them into game objects via drag ‘n’ drop. Exposing tweakable parameters is merely a case of declaring a component member public.

Unity is my first choice for prototyping, but I’m doubtful it’d be flexible enough to ship a full-scale game based on it. The drawbacks are:

• No script debugger. The editor offers excellent facilities for inspecting and changing object properties in a running game session, but there’s no line-by-line script debugging.
• No load/save framework. In spite of all the network serialisation stuff, you’re on your own when it comes to writing out a save game. There’s Dot-Net’s object serialisation and I/O though, so it’s not completely low level.
• The GUI framework looks to be somewhat bare in places. No modal dialogs for example.
• The physics API is an intelligently chosen 80% solution. It caters to the common uses of physics. If you’re in the weird 20% like Portal or Braid, you’ll probably spend more time fighting Unity than worthwhile.

That said, it’s superb for what it is and it’s been getting more flexible with every release. It’s a taste of the future of game development. Ideally, the only code required for a game should be gameplay-specific. Middleware has been getting steadily more and more comprehensive, and I can see the day when the only folks working on engine-level stuff work at Unity, Autodesk, Epic and Intel.