For the past month or so, I’ve been working with Unity 3D, a 3D engine and IDE built by Unity Technologies. Prior to this experience I had only heard vague references to Unity, but it hadn’t really been on my radar until now. However, now that I’ve had a chance to dip my toes into it, I’m quickly becoming a fan. To sum up my experience:
Unity has done for 3D gaming what Flash did for 2D animation.
We’ve been looking at Unity as a potential solution to the great “cross platform” problem: How do we build one code base and deploy it to mobile devices and the web?
On the web, Unity has approached this in a similar way to Flash, where the end user must install a browser plug-in to see the content. However Unity’s content has much greater access to the system’s resources, in particular the 3D rendering pipelines, which Flash is just starting to add with the Molehill APIs. Result? Edge to Unity.
On mobile devices, both cross compile to native apps that run as native code on the phone. Result? Call it a draw.
When you look at building for both platforms using the same code base, the problem gets a lot more complex, and neither has really “solved” the technical challenges you’ll face. The first is handling different input methods. A lot of web interaction relies on rollover transitions for user feedback, however that interaction doesn’t exist on mobile devices which are primarily touch-based these days. Solving for both input methods can be partially accomplished through good user experience design, however it’s nearly impossible to avoid writing custom code for each target platform.
The second problem that neither Flash nor Unity can solve is asset loading on different platforms. On mobile, you have to respect the user’s bandwidth, or be prepared for the network to be unavailable, so you package all of your assets in the initial download and load very little at runtime. On the web, you can basically assume broadband these days, so you make your initial download as lightweight as possible, preload the bulk of your app, and lazy load the rest of the assets you need.
There’s no way for either Flash or Unity to solve these problems, so expect around 25% of your code base to be affected and change drastically when developing for a new platform.
With that said however, Unity is still a very impressive tool for building 3D games and simulations. It was built from the ground up with multi-platform development in mind though, so it has some nice features, in particular its well defined asset pipeline, and it can certainly push the barriers of production value beyond Flash, which mobile gamers expect, and web gamers appear to be trending towards.
Here’s a few more quick points of how Unity compares to Flash, in the context of building for web and mobile:
- Much better graphics capability and overall performance for what you get
- Potential for more advanced game play (particularly physics-based)
- The Asset Pipeline (getting art, sounds, and animations into the game) was well thought out from the beginning, so there’s basically one way to do it, and it’s easy.
- You can write your client and your server in the same language (C# is the default), which allows you to do logic on either side to improve performance, security, possibly maintainability.
- The plug-in barrier. Can you convince your users to install a new plug-in and restart their browser to view your content?
- The production values expected from a 3D application are going to be higher than the typical 2D experience. If you can’t meet the user’s expectations in that realm, you may have done yourself a disservice.
In the end, I really think it comes down to your creative vision. Choosing a technology is about making trade-offs, so when you ask “What do we want to build?”, you have to weigh what Flash does well, 2D animation and vector graphics, versus what Unity does well, physics and 3D.