Summary: Unity3D is a cross-platform game engine and development suite.
Who this will be relevant to:
- People who want to make games
- .NET enthusiasts
- Anyone who's ever wanted to quickly whip up a GUI/demo/prototype in a 3D engine.
Matt nominated me to write the tools email for September, so I thought I'd take the opportunity to talk about Unity3D; a 3D game engine and development suite.
Probably the simplest overview of Unity is straight from the horse's mouth:
http://unity3d.com/unity/. In essence, it's both a development environment like XCode or Visual Studio, as well as a collection of engines and tools (including licenses!) for physics, light baking, 3D sound, model importing, etc, and a pretty solid and reasonably well documented API for scripting.
It's been around for a few years now; I first used it at version 0.8b in 2006, and it's just hit 3.4 last month. Originally it saw a lot of use by indie game developers, but a lot of major studios are switching to it, mainly because of its tools and ease of use, but also its killer feature: cross platform exporting. Straight out of the box, Unity exports to a web format (requiring users to install a plugin that works on all browsers), Flash (as of a week ago), Mac and Windows stand-alone executables, PS2, PS3, Wii, Xbox, Android, and of course, iOS. The IDE itself runs on windows and mac, but there's a strong emphasis on the mac side of things as that's where it came from originally. For coders, under the hood your scripts compile to Mono/.NET (Mono being an open source cross platform implementation of .NET), and you can write them in UnityScript (basically javascript but with a few ease of use touches), C#, or Boo (syntactically like Python). Since the scripts are compiled to .NET, there isn't much of a performance hit from this.
The most interesting change for me (coming from a C/C++ background) is the strong emphasis on component architectures. Rather than having a big hierarchy of classes, Unity tries to make it really easy to write smaller modules as components that can be added to or removed from objects at runtime. Through reflection (runtime detection of class methods, etc), you can call any public function from any other script via a message broadcast, however there's a bit of overhead (i.e. you'd be better off caching a reference at initialisation time if you're doing this in an inner loop). Compared to the class hierarchies you'd see with games written in C++ (anyone looked at the Quake3 source code?), this makes for a much cleaner more modular system. That said, I'm sure it's still perfectly possible to write shit code in any system...
Rather than risk this turning into a huge advert, I'll stop here, but feel free to post questions to the group and I'll endeavour to answer them or point you in the right direction. The take home message is that Unity is a seriously powerful tool for game development, and if you have any inclinations in that area, you can't afford to overlook it.
Cheers,
Tom