Red Button Bulletin 3 - Goodbye, XNA. Hello, Unity.

As a heads-up to non-developers: today's entry will be a little technical, but I've had a lot of mini-discussions about our shift in development tools, and I wanted to address it fully for those that are interested.

Our previous two games, Olu and All Your Creeps, were both written with Microsoft's game framework XNA.  Our next game, currently just called Codename: Jenga, is being written with Unity.  There's a lot of reasons behind the shift (rather than just a bulleted list), and it isn't any one reason why we're switching - it's a combination.

Engine/Editor instead of API

XNA does one thing very well - provide a managed framework for programmers to build games.  However, for any non-technical team member, it's a headache to use.  It's built around the idea of a codebase, with some afterthought put into content management.  There is no designer to speak of, and there's technically an "engine," but really it's just a set of classes that saves you some time.  Unity, on the other hand, is an editor and engine first, with the ability to customize any object with your own scripting.  At any point during game execution, you can pause the scene an inspect it and change any publicly-exposed variable (such as location in a scene or material). Also, it is generally more malleable since everything is exposed through the editor.

3D support versus 2D support

Although both tools can do both 3D and 2D, XNA is targeted towards 2D games, and Unity is targeted towards 3D.  XNA includes an extremely optimized sprite batch system, and Unity's coordinates are always three dimensions - even if one is only used for layering.  Throughout the process of building Olu and All Your Creeps, many systems I built from scratch would have been available from the start in Unity.  This sort of leads into the next point as well...

Many more systems included in the engine

XNA provides very few systems out of the box.  For example, you can draw a 3D object, but without animation.  If you want animation (2D or 3D), particles, or physics, you'll have to find a third-party library to use.  Unity provides all of these (and many more) in the engine.  It provides plenty of options to manage content, adjusting import settings, swapping textures, changing shaders - all through the editor.  In XNA, you'd have to develop your own tools or solutions to these problems.  Either that or just change a setting in the game and restart.   And in case Unity doesn't include a solution or the included solution isn't good enough...

Unity's Asset Store

XNA's community is strong - at least, in the early days it was.   However, one area I felt it always struggled was sharing reusable code and systems.  A few solutions became pretty popular to solve common problems (EasyStorage comes to mind), but it was hard to seek out solutions and spent time integrating them into your codebase.

Unity's solution to this was the Asset Store.  It provides a place for anyone to sell anything related to game development - from game assets to UI systems.  It created a culture that sharing your reusable content was valuable - and the more "plug-and-play" your system was, the more valuable it was on the Asset Store.  So far I've only bought a pathfinding and UI system, but these polished systems saved me dozens of hours in work.  And due to the modular structure of Unity's scripts, they're much easier to "plug-and-play" than a normal addition to your codebase.

Same development environment

This is a short note - but I'm still using C# and Visual Studio for "scripting," so there isn't much of a transition from a programming perspective - I'm just using different systems.

Easier and wider cross-platform development

This is the BIG one.  If there was one reason that I chose Unity over XNA, this is it.  XNA lets you develop one place and deploy to Xbox 360, PC, or Windows Phone 7.  The codebase can stay the same - but many limitations of the deployment you can only determine by testing.  Graphics card not working well enough on a testing PC?  Then you'll be troubleshooting until you figure out what part of the code to revise.  They've improved this by creating two "profiles" of PC's (high-end and low-end), but you're still left with the risk of PC development - every system is different.  Not to mention that you're limited to XBLIG, Windows Phone 7 Marketplace, and PC.  I'm not going to address XBLIG concerns in this post, but I will say that many people would not expect their game to succeed on XBLIG.

With Unity, there are 6-7 different platforms you can develop on (depending on how you define "platform").  We're targeting PC/Mac/Web at first, but can easily expand to mobile when we decide to go down that path.  And for PC - there are already predefined performance profiles for different graphical levels (which can be further customized).  It helps mitigate some of the risk associated with deploying a game to PC, along with not knowing every iteration of PC specs.

Familiarity

Although we used XNA for our previous two games, Jesse (our Art Director) has used Unity for over 2 years - so we have a resource on the team that's very familiar with the tools.

XNA is still a good choice for many people - it just didn't make sense for our next project.  My hope is that this info doesn't necessarily drive people away from XNA, or blindly toward Unity, but educates on the benefits and risks associated with both.  As always, you can contact us with questions, either on Facebook, Twitter, or email (info [at] redbuttongames [dot] com).  Follow us on Twitter and Facebook as well!