XNA Game Studio Express Beta Impressions

I had a short look at the XNA Game Studio Express Beta a few days ago, so I thought it might be a good idea to state some of my impressions.

Let's start with the good aspects...

• The framework seems to be designed very well and careful. It seems to fit the .NET guidelines very well.
• This entire "game loop thing" is moved to a higher level. The programmer now has to derive his game-class from the Framework.Game class and implement some methods related to the game loop, e.g. "Draw". So all this stuff takes away the pain from the programmer trying to create a perfect game loop, which is not always fun, in particular in the .NET CLR ("Application.DoEvents").
• Device management has been simplified and moved to a higher level. Some traditional terms such as "lost device scenarios" have been revised and there is less witchcraft involved during device creation. This practically means, that large parts of the device creation work have been automated; "lost device" is now "ensure device"; switch to fullscreen is now as simple as calling "GraphicsComponent.ToggleFullscreen()". I think this was way overdue.
• Maybe this sounds radiculous, but XNA would be a perfect candidate for a multi-platform game environment. Why? Well, the XNA namespace contains really everything - not only graphics, sound and input, but it also has it's own IO-classes for data storage (!).

So let's come to be points I don't like...

• XNA is yet focussed on C# in VS Express environment. This means, that I cannot use other .NET languages, altough this shouldn't really be an issue by definition in the .NET CLR. I also cannot use use my non-Express VS - I have to use the Express edition.
• XNA has it's own project type (application and library). I cannot be sure, wether I can use other .NET class libraries in an XNA application or not. This could become a big issue. I could - however - compile my libraries into XNA format, but only *if* XNA supported C++/CLI as 2nd .NET language.
• XInput could be the biggest mistake. Yes, it allows me to access mouse and keyboard under Windows, and the XBox360 gamepad under both - XBox and Windows - environments. But what about all the other controlers under windows? One cannot expect that everyone buys an XBox360 pad for his Windows PC, but keyboard- and mouse-devices are not sufficient input methods for some game types. So PLEASE make XInput as general as good old DirectInput.
• I don't get this component stuff (GraphicsComponent etc.) ... VS Express displays these components as icons in the forms designer. This doesn't make sense. If they want me to "draw" my games, then they should at least enable the UML class designer in VS Express.

Well, XNA does some things very well. XNA will be a serious option for some game projects. It is not an option for a flight simulator project, simply because of XInput being the only input-API. It could be a serious candidate for a racing simulator (for example).

Wether to use XNA or not is a tough decision. In case you use XNA, you are pretty much bound to XNA and MS, and there is no way back and you are pretty much not flexible. In case you decide to go with XNA anyway, you have a rich game creation toolkit that will make your life easier. I think it's the best game programming API to date, and I don't see any other API reaching a comparable level, because all these APIs are designed with backward compatibility in mind. XNA is a fresh new API without a legacy burden.

In case you really want to go with XNA, you'll feel like Alice in XNA wonderland.