XNA's Future Looks Bright
Recently, I've felt that I have been much too unbalanced in my talk about XNA. XNA has plenty of problems, but I expected most of these problems (certainly the major ones with XNA's goals) to be fixed within the next year. While claiming that something is "the future" is idiotic, I do believe that XNA is a very viable and promising future. And what's more, I think it's absolutely critical that XNA succeeds, because it may be the only hope for our industry to move forward on a technical level. I think Microsoft is going to see this one through, too. MDX was a short term research project; XNA is a long term platform strategy like the Xbox itself.
The reason I'm writing this entry now is that a number of things have been announced fairly recently with XNA, all of which paint a much brighter future than the relatively bleak present I've discussed here and in other places. Incidentally, I'd like to encourage anybody interested in this stuff to hang out in #xna on the EFNet IRC network. Lots of cool people there, and many of them not nearly as technically obsessed as I am.
First, XNA 2.0 is coming. This is something the XNA community has been aware of for some time, but the details were only revealed recently. There's a number of major changes here, and I suggest you read the blog posting. XNA Game Studio Express is effectively the same thing as the pre-release SlimDX that I had posted back at the end of June; a first draft intended to explore basic principles and to get a more precise gauge of customer and developer interest. It's clear at this point that developer interest is massive, even amongst the typically slow to move pro game studios. MDX always had a dedicated hobbyist and indie following, but nothing more than that. (Plus it wasn't exactly strategically useful.) XNA has a real future here.
Second, the XNA team has been very aware of criticisms and problems, much more so than would normally be expected from a corporate group. This is something that's been pushed fairly heavily across Microsoft in recent years, but the XNA guys are in a particularly good position to make use of it. They have done so quite well, running a team blog as well as keeping other people interested and writing about XNA. They also have their own, reasonably active forums where a number of the XNA guys hang out and post. (In particular, information like this.) That kind of thing really helps to boost developer confidence, even when the actual content of the message is not what people want to hear.
Third, I don't really consider SlimDX and XNA to be competitors. The people who would use SlimDX would not be happy on XNA, and I get the feeling that many of these people would simply switch back to unmanaged DX or or soldier on with MDX even as the coffin is lowered. My basic take on XNA hasn't changed -- it's an Xbox API that happens to run on Windows. I just think there's a very real market and range of opportunity for a library like that. SlimDX, on the other hand, seeks to tackle a pure PC market by providing more traditional or Windows-specific APIs related to making games focused around Windows. Like MDX before us, SlimDX is not a platform strategy so much as it is just a convenience. At some basic level, our development model simply makes more sense for what we are. Similarly, XNA is a platform, providing access to something we would never have had in any capacity without it -- the ability to make Xbox games. SlimDX and XNA are brothers, even if there's some sibling rivalry involved.
Lastly -- and this is by far the most important point -- XNA makes managed games acceptable. Right now, games are written in C++, end of story. People know this. It serves to distort people's perception of what languages are suitable for writing games and why. I'm not interested in the actual reasons now, since it's not relevant to this post. The real key is that XNA based games are coming, and people are noticing. We can thank the Dream-Build-Play contest for that, because it served as a fairly violent catalyst in the matter. As XNA games start to appear, people (indies, pros, everyone) will begin to understand that managed code is great for games. Even if we accept the claim that managed code is not fast enough for cutting edge high end games, most games are not cutting edge high end graphical monsters of eye scorching brilliance. Consider that the top 5 PC games today are The Sims and World of Warcraft, both of which are fairly average looking games. It's not like managed code will "take over" or become "the future" or anything like that. Saying those things simply corrupts the discussion with rhetoric. What XNA does for us is to make people understand that managed code is not inherently slow or inherently bad for games (and we can probably blame Java for creating or at least providing evidence for that horrible misconception in the first place).
I'm not fond of XNA in its current form. I'm not interested in using XNA in its current form. But at the end of it all, XNA can succeed and it needs to succeed. I would hope that the people working on XNA share at least the last sentiment. I think in a year's time, a lot of very skilled developers will be doing absolutely amazing work with XNA, and they'll be doing it at speeds which the guys working with C++ and DirectX will never be able to match. Some of you have probably seen the strategy I've developed for completely shutting down language threads on the spot, without taking any moderator action. When XNA's time comes, I hope to be able to force managed code doubters into silence with nothing more than a list of links: a list of incredible XNA (and SlimDX I hope) games being built that look incredible and blow away the indie work we've seen to date*.
* No offense guys, I think indies are doing great stuff already. I just feel that the work done on XNA when that environment has fully matured will allow people to step up into another league.
One of the things that bugs me is they say they're incorporating a Network API, but what if I want to develop a master server for a multi-player game, and I want it to run on a linux distro? What then?
Are they forcing us to write on Windows/Xbox360 only if we plan on using their Network API? If so, that's really shitty if you ask me.
EDIT: Oh, in other news I saw that long ~2 hour lecture with Bjarne Stroustrup, he was talking about C++0x. He mentioned that there is a good possibility that they will be introducing networking to the standard library.
That way, we don't need to use WinSock, or Socks. We simply use their standard library. I'm not really clear on the details, or how it works, but I really like the idea.