Once we knew our platform, it was time to start figuring out the toolset or frameworks that we were going to use to make the game. The essential decision we had to make was whether to build our games from scratch, essentially creating our own game engine in the process, or leveraging one of the many existing commercial or open source game engines that are available. Although the idea of creating our own game engine had some appeal, we knew that practical considerations weighed heavily in favor of using an existing one. Although there are costs associated with using many engines, and even though it makes you dependent upon somebody else's work, the cost/benefit equation really makes the decision pretty simple. We want to tell a story and create games; we don't want to reinvent the wheel, and writing a 3D game engine from scratch is very much reinventing the wheel.
It actually didn't take us very long to figure out which engine to use. We ruled out a few very quickly. Cocos2D wouldn't work because we want to create a full 3D game. Cocos3D is still a little too immature for us to be comfortable relying on it. Since we want to keep our options open for releasing on other platforms, some other engines were ruled out. Sio2, although a good mobile engine that supports both iOS and Android, doesn't have desktop or console support.
Ogre3D, a well-regarded open source game engine, just has too many rough edges for my tastes. The cost savings from the fact that it is free and open source seemed to be far more than offset by the additional time and headache involved in using it. I'm all for open source software when it's the right tool for the job — Blender is still my general purpose 3D app of choice — but the gap between Ogre3D and the commercial engines is pretty wide, not in terms of what you can achieve, but in the amount of effort it takes to achieve it.
We very easily got the list down to just three: the UDK, the Source Engine, and Unity3D. Then, two of those three got quickly crossed off the list, as well.
Although the UDK is an amazing engine, we ruled it out for one simple reason: the toolset is entirely Windows based. Although it can create iOS and Mac games, most of the work involved in creating the game has to be done on Windows. We're almost entirely a Mac shop and I, personally, am much more productive and happy when working on a Mac. Even if I didn't mind spending much of my day in Windows, I'd still have to compile, test, and upload to the App Store using a Mac, which seems a rather convoluted and inefficient process. It's probably not much overhead for a large game shop, but it's more hassle than I'd want to deal with.
The Source Engine has similar limitations. Although Valve has been promising Mac tools for a while, they have not shown up yet and there have been no recent comments from Valve about Mac support, leading me to question whether that they've dropped the plan. On top of that, Valve hasn't delivered official support for any mobile platforms yet. There are rumors of a Source 2 engine in the works that will likely address these issues, but we can't develop with something that's not out yet.
Before long, there was only one engine left standing: Unity3D. We've used Unity for a few client projects in the past and I'm, frankly, rather impressed with it. I thought that I would really hate working in C# but it turns out I don't mind it at all. I don't like it as much as Objective-C, but I don't have the kind of hatred for it that I seem to have developed for Java and C++ over the years. Like all languages, it has its quirks, but I don't feel like the language is working against me and I don't have problems context shifting between Objective-C and C# like I do with Objective-C and Java. Objective-C and C# are surprisingly compatible languages given their differences.
Although I've only got a few hundred hours of experience with Unity under my belt, it strikes me as having the right balance between ease of use and power. The development environment runs natively on the Mac (and Windows also) and it is capable of generating iOS, Android, Mac, Windows, and Linux executables. It's even possible to build your apps for the Xbox, PS3, and Wii, though doing so requires contacting Unity and negotiating separate licenses. There is, of course, some work involved to account for the various platform differences, but a surprising amount of it is handled for you.
Once we got the licenses squared away, it was time to get something built. There's one school of thought in game development that says you should try and get a prototype up and running as soon as possible. The earlier you start being able to play, the faster you'll know whether the game's going to work. So, let's get a skeleton of our level hashed out so that we can get our first rough prototype stood up.
Next Up: Just Getting Something Running
Previous: Platform Decisions
No comments:
Post a Comment