Friday, February 15, 2013

Lately there has been lots of speculation and comments on the Web regarding the fate of XNA as a result of these blog-posts.

Due to technical difficulties with my main system I am arriving late at the party; many articles and tweets are out now, but anyway, I will give my view on the subject.

For me, the phase-out process that MSFT has been carrying out silently for, what, a couple of years, a year and a half, a year, <include your estimate here>, is not precisely a surprise. In fact, I stopped working in all projects based on XNA tech during late 2010 because something was troubling me.

At that time, I was an XNA/DX MVP creating my game engine, replacing XNA’s Content Manager with my own version of it, developing a videogame, to mention just a few, but for some reason I was holding myself back before starting a game-dev business based on XNA tech.

The hunches -based on facts- that supported my decision back then, in hindsight now prove me right on my wait. Of course it is important to note here that this worked for me; in other words, YMMV.

1. HUNCHES AND WARNING SIGNALS

Let’s see, in no particular order, these are the hunches that caught my attention:

Comuniqués started to slow down: these were a great read on the XNA Team blog, but suddenly, they started to fade out.

Our Community Manager moved to another division: we all remember her xxoo’s at the end of her messages and posts. That unexpected departure was the first warning signal to me.

XNA 4 was gradually presented as a “mature” product: or expressed in a different way, XNA was not likely to receive (major) updates. Maybe this one was very difficult to gather at that time, but for me it was the second warning signal.

Lack of strong support for XBLIG: how many times community members (and even MVPs) claimed for proper marketing, fast opening of new markets, and or even a decent location on the Dashboard? In practice, MSFT turned out to be reluctant, so third warning signal.

Lack of XBox Live services for XBLIG: in addition to the previous one, how many times community members claimed for Leaderboards, Achievements, DLC, and so on so forth? Do you guys at MSFT really expect that games with no global leaderboards survive the increasing demands from gamers?

Communication of Future Moves to MVPs: in the past, before entering a new dev phase, the Team used to involve XNA/DX MVPs on design decisions. Maybe for many readers this is not relevant, but from and MVP’s perspective that to some extent used to be involved in the roadmap, being asked “what do you guys think of …?” a few days before going public, is a warning signal. Fourth one, indeed.

The format of .xnb files was published to the world: this one might have been handy to me if published a couple of years earlier, but combined with the one below, gives -more than an indication- a confirmation that MSFT was silently phasing out XNA. Fifth warning signal.

Gradual relocation of all members of the XNA Team: when you saw one one of the most important programmers on the Team go to a different division on MSFT, and no one is relocated or hired to take its place for further development of XNA, (please be honest here) did you really think that everything was ok? Sixth warning signal. A major one, if you ask me.

Unattended suggestion on Connect: after the database clean-up the XNA Team did on its Connect’s page, suggestions were marked more and more as “Active”, “Postponed”, “By Design” and “Won’t be fixed”. Seventh warning signal.

DirectX SDK will not be updated any longer as such: let us clarify this point: the DirectX SDK was integrated into the Win8 SDK for the newest version of DX. What happened with the SDK for DX9.0c? Eighth warning signal.

No XNA 4 for Windows 8 RT: this is a technicality but, given that DirectX 9.0c does not get along with ARM processors, unless XNA gets a redesign based on DX 11.1, it gets pushed out of the picture for Surface (ARM-based) tablets. Since the XNA Team has been erased, unless a new official product comes unexpectedly out of the shadows for .NET, hoping for an official rope is kinda naive. Ninth warning signal.

XNA does not support WinPhone8, or does it?: after all the worries, talks and efforts to provide safe environments, MSFT does radically change by allowing the execution of custom native code on the new Window Phone 8 devices. This sounded like heaven for XNA’ers until MSFT announced that XNA wouldn't add support for WinPhone8. Games created with XNA for WP7 still run on WP8 devices, but they will not be able to get advantage of unsafe operations for the device. Tenth warning signal.

XNA is not integrated into VS2012: as a corollary of the point above, XNA was not integrated into VS2012, what in turn means that if you need to use the content pipeline, you will need to install VS2010 side-by-side with VS2012. I don’t know, eleventh?

No MVP award for XNA/DirectX: I can understand the decision for XNA given that it has been and still is being phased out, but why must the award for DirectX be also doomed? Despite the fact that the SDK is now part of the Win8 SDK, imho it is still a separated kind of expertise that cannot be merged with other areas. Final warning signal = confirmation.

As a former XNA/DX MVP as well as an old timer using MSFT’s technology, let me say that lately it has been really difficult to recommend the use of XNA to create games professionally given the facts above.

What can you say to devs when they ask questions like: “Can I use XNA for Windows RT?”, “Will XNA be integrated into VS2012?” or “Will XNA support DX11?”? Ditto for the question below …

2. WILL THERE BE A NEW OFFICIAL SOLUTION FOR .NET?

It is very difficult to foresee what’s coming next in terms of .NET and game development given the difficulties one may find when trying to deduce what the heck TPTB at MSFT are currently thinking/doing.

But let us see, to update XNA (or replace it) MSFT may consider that …:

… there is a novelty around “Going Native” with C++11 inside MSFT itself.

… to support ARM processors, the new tech needs to be built on top of DX11 APIs (which supports “legacy” cards by only enabling the subset of allowed features for the card).

… XNA is neither a pure DX9-wrapper nor a game engine, making it difficult to justify its maintenance.

… the dream of “develop once, deploy to the three screens” vanished given that not all the features supported on the PC were supported on the 360 and the WP7 platforms. Plus, the screens are changing: WP8, Surface, XBox.Next, ...

… due to the managed design of XNA, and in spite of some indie impressive efforts (like this one and also this one), XNA lacked middleware support of big fishes in the Industry.

… there was never a world/level editor. XNA is VS centric, so how can it compete with editor-centric solutions like Unity3D or UDK?

… last but not least, XBLIG failed as a business line an new lead marketplaces for indies emerge (Win8, WP8). Period.

So, to answer the original question, with C++ regaining position inside MSFT and being DX11.1 mandatory for latest platforms, why bother? Which leads us to the next question …

3. WHAT CAN “XNA’ers” DO NOW?

You feel disappointed. MSFT let you down (for some, again). You cannot find the exit from this nightmare. And you do not want to learn or get back to C++.

If that is your case, then, do not panic! Right now, there are many alternatives out there for you to consider, specially if you like or love C#:

1. SharpDX: created by Alex Mutel -as an alternative to SlimDX, this pure wrapper of DirectX (from DX 9.0c to DX 11.1, both included) has positioned as the lead solution for advanced user who want to program DX games on top of the lowest level available to C#.

Although this set of APIs is open source, it is consumed by many of the solutions that will be listed next. What is more, games for Win8 from MSFT Studios (through partners like Arkadium) have been developed using SharpDX (i.e.: minesweeper, solitaire, and mahjong).

Alex has been also developing a Toolkit to ease development of common tasks (sound familiar?), which for sure extends a bridge to those of us coming from XNA.

2. Monogame: the open source sibling of XNA. Fueled by SharpDX for all latest Windows-based platforms. Multiplatform not only for Windows, thanks to Mono.

With few-to-none modifications to the source code of your XNA creations, you can port your games to a wide variety of platforms.

This open source solution has recently reached its third stable version, adding many requested features, like 3D support.

Although it lacks a content pipeline replacement, which is currently under development, it can be used from VS 2010 and VS 2012.

Coding by using this solution resembles coding with XNA. It has its own multiplatform content pipeline which optimizes output per platform, among other tools. And games like Soulcraft show off the power of the solution.

6. Axiom: being a former user of this solution before the time of XNA, I am very pleased to see that the project has revived.

Axiom is now a multiplatform solution for .NET based on the popular OGRE graphic engine, which also consumes SharpDX for Windows targets.

Honestly, I do not know whether there are games created (and published) with this solution, but I hope there will eventually be sooner than later.

7. WaveEngine: Vicente Cartas (MVP for XNA/DX) has just let me know about this cross-platform engine, which will be released as a beta in less than a day ahead (thanks for the tip!).

Oriented towards the mobile-dev market, the engine is a result of a two-year effort of the Wave Engine team. Knowing past work of Vicente on JadEngine, I cannot wait to watch some cool demo videos here (like Bye Bye Brain).

Best of all, the engine is completely free, so it is with no doubt worth trying as soon as it gets released!

8. Unity3D: I cannot forget to mention Unity3D since it started almost at the same time that XNA did, however, adoption among devs grew exponentially on later years because of a combo of factors: a robust editor, multiplatform support, increasing number of appealing features, and a variety of well-known success stories among indies (for instance, ShadowGun).

Make no mistake here, the experience of using Unity3D is quite different from XNA’s: its editor-centric, coding -either in C#, Javascript or Boo- serves as scripts, sometimes you need to broadcast messages -as opposed to an OOP rationale, and last but not least, 2D programming is not straightforward (not even on the latest version; you need to buy one of the available plugins as a workaround).

… publishes as open source the source code of XNA that does not implies a security risk or bring any potential legal issues to the table (like say, the content pipeline).

… reduces barriers for indies (like say, the access to XBox Live services) for the upcoming XBox.Next so as to compete with other platforms like Ouya, iOS, Steam and so on so forth.

… and continues to support indies through initiatives like the Dream.Build.Play compo.

Personally, I do not care the language or solution a dev picks to develop a game provided it is the right language or solution for the project. In this sense, this “Going Native” campaign that some people at MSFT may seem to support by stressing perf differences among C++ and C# whenever they can, is imho unnecessary given the fact that there are many successful indie games out there developed with managed code.

Plus, as a former C++ dev, I do not want to get back to C++ because I feel really confortable with C#. If sometime in the future I had to go to a lower level language I would prefer “D”.

Thus, I hope MSFT creates a common compiler for C++/C# which in turn will help us turn the use of hybrid solutions into a common scenario for indies.

5. TO WRAP IT UP …

Without starting a nonsense discussion for a Pyrrhic Victory, imho the fate of XNA was predictable if you took a careful look at announcements from MSFT, whether you deemed them as facts or mere hunches.

But one thing remains strong for sure: XNA’s spirit.

Thanks to solutions like SharpDX and Monogame one can still talk about C# and XNA-based coding as a valid option for a game-dev business.