Frameworks
I frequently get emails from people asking me what direction they should take in the future, whether it should be Unity, XNA/MonoGame, or something else. That’s not a question I can answer directly because it depends.
To illustrate my point, let’s take a step back and talk about frameworks. Software developers (including game developers) love frameworks. There’s pretty much a framework for everything. Strike that. There’s many frameworks for everything.
Unity, XNA, MonoGame, and SharpDX are all frameworks. All game engines are.
The nice thing about frameworks is that they provide you with a large collection of code that gets you off the ground quickly. That’s what makes frameworks useful. It’s why we have them in the first place.
There’s a catch, though.
Anytime you see the word “framework”, you should be imagining a double-edged sword. It simultaneously helps and hurts you. On one hand, frameworks mean less for you to do yourself. There’s code and functionality that exists that you would otherwise have to write on your own. The framework gets you a jumpstart into your game.
But on the other hand, frameworks will also simultaneously box you in within the framework. It sometimes limits what can actually be done at all. Other times, it changes how you do things, pushing you down a path towards an architecture that is less than optimal, or more difficult to maintain. This side of the picture is forgotten all too often.
Frameworks do their best to try to minimize the times and places where you’re limited by it. They make it extensible, configurable, and customizable. But even still, there are always limits to how far you can go with this. All frameworks place some sort of limits on you.
Unity, XNA/MonoGame, and SharpDX are all frameworks, all intended for game development. But they all come in at different levels. SharpDX is the “thinnest” framework of this bunch. It is about as thin of a wrapper as you can get around raw DirectX and still program in C#. (Of course, even DirectX is a framework with certain features and certain limitations.) Compared to Unity and XNA, SharpDX limits you the least, but also leaves you with the most to do (offset significantly by the SharpDX Toolkit).
XNA is the mid-grade variation. It gives you less power than SharpDX (not the least of which is that it is still based on DirectX 9, while SharpDX gets you the new features in DirectX 10 and 11). But it also means you have less work to do than you would with SharpDX.
Unity is a fully featured game engine. It is a heavier framework. It means you get a lot of value right off the bat. But it also means you get stuck with potentially more limitations, or boxed in to doing things a certain way. It seems to me that Unity games all have a similar UI feel to them. An artifact of the shared framework they all use.
I haven’t used Unity enough myself to know the details about its limitations. The only example that comes to mind readily is some things that have come up in Kerbal Space Program, which uses it. (Awesome game, by the way.) They’ve used Unity to great effect, and built a really cool game. But they have a number of bugs that they cannot fix (strange things happening when you fly a spacecraft into a place with very high gravity) simply because of the limitations of the engine they’re running on. And it’s not worth their time to essentially rewrite the entire Unity framework into something that actually fixes the bugs. They’re basically resigned to just telling people their ships might spontaneously explode if you fly to close to the Sun or Jool (their equivalent of Jupiter) and there’s nothing you can do about it.
Most Unity games don’t necessarily have this problem. The problem I described is very specific to Kerbal Space Program, but it is an example of the things you may run in to.
One of the gotchas with working with a framework is that it’s usually pretty easy to see its benefits, but it is much harder to know the ways that it will limit you. Usually, a framework’s home page will spell out the benefits and not the drawbacks. But more than that, you usually start using the benefits on day 1, and it takes weeks or months to get into a situation where you’re boxed in or somehow limited. At that point, you’re already committed, and you have to find a workaround.
So you can choose something like Unity, which gives you a lot of framework (== a lot of power out of the box, and more limitations), XNA/MonoGame, which gives you quite a bit of power out of the box (but less than Unity) and fewer limitations, and SharpDX, which requires you to write a lot of your own code from scratch, but has few built-in limitations (besides what the hardware can handle).
Depending on the game you want to build, the amount of time you have to build it, your level of competency in programming, the amount that you (or somebody on your team) enjoys programming, and whether any of a specific framework’s limitations will have a significant impact on your game, and what expertise you already have, different people and different games will inevitably have different answers. For some, Unity is a great choice. For some, they’ll feel like they have to go the C++/DirectX route. For me, and most of the games I dream up, XNA is right. (Which is the reason I wrote all of my tutorials about it, and why I’m so supportive of the effort to get Microsoft to resume development on it.)
To answer the original question, the truth is if you’re just getting into game development, there probably isn’t a wrong choice. (There might be better choices, but probably not a wrong choice.) Any path you take will teach you all sorts of stuff that can be applied later on in other paths if you go a different way another day. My recommendation is to pick the path that seems the most exciting to you. If six months from now, you want to try a different approach, the knowledge that you’ve gained in one path will still be very relevant, despite the framework change.