Before I continue, I should state that just because Microsoft has said XNA is not in the company’s future plans doesn’t mean it’s suddenly useless. You can still build fantastic games with it and in tandem with frameworks such as MonoGame and MonoTouch, you can deploy XNA-built titles on many devices, including mobile ones.
What’s unavoidable is that XNA won’t benefit from updates and bug fixes and that means all you’re doing is improving your skills with a toolset that will be superseded — perhaps sooner rather than later, given the next iteration of consoles could be on us this year. While it’s hard to shift from an API and work pipeline you’re familiar with, in the long run, you’ll be better for it.
Fortunately, the skills and experience you’ve nurtured using XNA — C#, the .NET Framework, HLSL, etc — can be transferred nearly seamlessly to a number of other technologies. I won’t pretend to have knowledge of the entire spectrum of alternatives and their various configurations, but I do have some experience with several cross-platform middleware options, which I’ll talk about here.
Unity, a cross-platform engine and IDE developed by the company of the same name, should be your first port-of-call. It uses Mono, the open-source implementation of the .NET Framework, as its scripting backend and supports a number of languages, C# among them.
It’s biggest strength is that you can “develop once, publish anywhere”, as the company’s own motto declares. As long as you keep hardware restrictions in mind and are prepared to make a few tweaks to get things working on the various platforms, Unity gives you the option to have, say, Windows as your lead while leaving the door open to relatively painless ports to OS X, Linux, iOS and Android, as well as the three major consoles.
Unity was designed with artists in mind — the IDE allows you to drag and drop assets into a project, where they’ll be imported, optimised and transformed into game-ready models and textures. The “scene” controls are modelled off of Autodesk’s Maya, so any experience here is easily transferred.
Finally, Unity’s “ShaderLab” language lets you create vertex and pixel programs using NVIDIA’s Cg, which are then compiled into optimised forms for OpenGL (and its embedded subset) and DirectX. Cg and HLSL are nearly identical, thanks to collaboration between NVIDIA and Microsoft, so everything you picked up writing shaders for XNA can be used here too.
The disadvantages of Unity stem from the differences between the indie and paid-for versions. For the hobbyist, you can definitely cope with the Unity logo splash screen and reduced feature set, but the moment you want to render to an off-screen surface to perform post-processing (a fairly common activity in all but the most basic games), you’ll need to drop $US1500 on the Pro version.
That said, it’s hard to go past Unity’s maturity, ease-of-use and cross-platform features. Unless you have some damning reason to avoid it, it really is the best choice for XNA castaways.
The easiest way to describe SFML (Simple and Fast Multimedia Library) is a new-age version of SDL that supports 2D hardware acceleration via OpenGL out of the box. It comes in two flavours — the reliable, though aging 1.6 version and the 2.0 release candidate. While it started out as a C++/C project, the latest version comes with .NET libraries that are easy enough to plug into.
I haven’t had a chance to check out 2.0, but my experience with 1.6 was excellent. I was able to throw together a simple test in .NET that ran fine in Windows and after a bit of work registering the right libraries, in Linux also.
Documentation wasn’t SFML’s strong suit, but looking at it now, it’s come a long way. True, it’s not as extensive as MSDN — how could it be? — but the developer, Laurent, is active on the official forums and seems happy to answer questions.
Unlike Unity, ensuring your game works on Windows, Linux and OS X is not as straightforward — you’ll need to constantly test that everything looks as it should. You’ll also need to learn GLSL if you want to write shaders, though you can always code in Cg and use its compiler to create GLSL.
SMFL is perfect for those that like to stay close to the metal, as it were, compared to the level of abstraction in something like Unity. If you’re interested in writing your own engine (though you should almost always be writing a game if you don’t want to end up in refactoring hell) or understanding to a better degree what’s happening behind the scenes, then there’s nothing wrong with SFML.
A few years ago, OpenTK would not have been a bad choice if you were after a cross-platform multimedia API. Unfortunately, the project appears abandoned, the last blog post dated 2010. That said, it still works, but like XNA, it doesn’t have much of a future.
The reason I mention it is that, depending on your needs, it might be perfect. It comes with a cross-platform GUI framework based on GTK# and there’s support for audio. The bad news is that 3D hardware acceleration is handled by the Tao framework, the website for which is now being squatted, but you could always code up your own OpenGL backend… but then, that’s why you’re looking for libraries in the first place.
Ideally, you should use Unity or SFML. Pouring time into OpenTK will leave you worse off than sticking with XNA. Much worse.
And Everything Else…
This is by no means a comprehensive list. For example, I haven’t talked about the managed DirectX library SlimDX, but it does cover what you’re likely to stumble across searching for a cross-platform alternative to XNA — one that doesn’t force you to abandon what you already know. Personally, our studio has moved onto Unity, coming from a built-from-scratch engine based on SlimDX.
The lack of portability and the additional support burden of a homebrewed engine has proven troublesome, which is why we’ve found Unity appealing. It’s definitely early days, but moving beyond the Windows ecosystem — be it DirectX or XNA — should be seen as an opportunity, not a roadblock.