Piecing together Microsoft’s XNA gaming platform
- 📅
- 📝 791 words
- 🕙 4 minutes
- 📦 .NET
- 🏷️ Visual Studio, Xbox, XNA
- 💬 3 responses
I’ve briefly covered Microsoft’s XNA gaming platform before but have been trying to piece together what it is actually going to mean to developers.
Major update!
Sorry, had to clarify the whole commercial/non-commercial parts. XNA Framework is just a portion of XNA… that won’t apply to the big guys.
Homebrew/public
Microsoft have made it clear they want to open up XNA to interested parties which should mean home-brew software.
These guys will be using C# in conjunction with XNA Build, XNA Studio, XNA Framework and managed libraries.
Licensed developers
Licensed 360 developers get a whole set of tools and technologies that are under tight NDA just like those Sony and Nintendo insist on for their licensed developers.
These guys will be using C++ in conjunction with XNA Build, XNA Studio and no doubt 360-optimized unmanaged libraries based on Direct3D, Xinput and XACL.
Whether XNA lets Microsoft get the 360 and Windows XNA gaming platforms a little closer is anyone’s guess. Being under NDA I doubt the general public would even know.
Language
C# for home-brew developers, C++ for licensed studios.
There’s no way the licensed studio’s are going to change and C# lets the new guys get up to speed quicker.
Licensed studios will have full control, full speed and continue to use their existing libraries and middle-ware.
Core framework — .NET 2.0 BCL
.NET 2.0 Base Class Library — well a modified version of it for those using the XNA Framework and C#.
Seeing as C# is the only managed language on the menu and games are rather performance sensitive expect CLS compliance to disappear and plenty of under-the-hood optimizations now that they don’t have to support other languages.
Graphics framework — MDX2
The graphics framework is based on the graphic assemblies of Managed Direct X 2.0 (MDX2) which currently ships as part of the DirectX SDK.
MDX2 is currently beta and will never hit a final release now all attention is now focused on the “XNA Graphics API” version that will see the weight drop and aim to be more cross-platform — no doubt hiding away all the platform-specific optimizations inside the libraries themselves.
There will be no System.Drawing and no System.Windows.Form name spaces so forget about them.
Audio framework — XACT
Microsoft Cross-Platform Audio Creation Tool (XACT). Grab it from the latest DirectX SDK and forget about DirectSound and DirectMusic. They won’t make it.
Input framework — Xinput
XInput kicks DirectInput off the scene with it’s easier-to-use API and support for vibration and varied controller types and voice headset.
Grab the XInput Driver for Microsoft Common Controller, plug in the 360 controller on your PC and start messing round.
Build tools — XNA Build
XNA Build is based on MS Build but adds asset (textures, samples, music etc) tracking to the mix to ensure you don’t do like Microsoft and ship almost an entire CD’s worth of unknowingly unused assets with your Mech Commander. It also lists incremental and distributed builds on the feature list.
A March 2006 technology preview is available that integrates with Visual Studio 2005.
IDE — XNA Studio
Once again Microsoft takes from it’s existing .NET tool-set and makes an XNA version — in this case Visual Studio 2005 Team System..
Whether the cheaper home-brew/XNA Framework/C# version will have all the C++ features stripped is anyone’s guess.
Live Anywhere!
Microsoft have already announced their plan to take online gaming from the Xbox 360 (gamertags, achievements, friends, chat) and make it cross-platform across to Windows and mobile gaming.
It would make of sense then that the Live Anywhere! system is .NET framework for use with XNA — even if it doesn’t officially make up part of the package.
Have to sit and wait for this one to pan out.
Platforms
Microsoft will be supporting:
- Xbox 360
- Windows XP 32-bit/64-bit*
- Windows Vista 32-bit/64-bit*
Mac OS X?
Apple should really be negotiating to get XNA on Mac OS X. It already internally supports PowerPC (360, G3, G4, G5) and Intel (Windows, IntelMac) as what they offer developers seems rather weak — about the only reusable element is OpenGL.
This would allow existing XNA games to be ported with ease although would be of little use to existing Apple developers who use Objective-C/C++ and wouldn’t want to interop with C#.
Linux?
Linux already has Mono & DotGnu which could provide the basis for a .NET based gaming platform but I can’t see Microsoft wanting to open up the source for a successful Linux port.
The only obvious route here would be for Linux developers to either implement it themselves or wrap around existing technologies — Wine/OpenGL etc.
Sources & info
[)amien
3 responses to Piecing together Microsoft’s XNA gaming platform
I agree with Rim here and am totally against everything Steve had said here! Steve, to me it sounds like you are extremely biased and are unaware of quite a few things in the real world friend. It’s mainly geared for C# VB has little to do with it my friend. With that said XNA is an excellent framework as was pure DirectX for it’s time and I have fallen for XNA big time here and totally love it. I use to use C for so many years in the past and it was nothing more than a headache. I am proud of MS for not listening to these guys that are so for this C stuff! I also find it extremely easy, beneficial, and efficient to write using the .Net Framework and C# all together. This is excellent.
I love the blog Damien, it’s very informative mate; keep up the great work!
(Just came across this blog, dropping a belated comment to speak my mind)
Obviously I’m biased (MDXInfo staff), but I don’t agree to Steve’s assessment that using .NET will distract people from the skills they need to get into the real game industry.
A programming language is just a platform, a means to an end if you will. The true skills people need to be succesful in game development (or any software development sector) are not tied to a specific language. The ability to transform ideas into code and problems into solutions is the schoolbook example, but also game specific elements, like working with shaders, scene management, resource management and all fancy visual techniques are possible in Managed DirectX.
A thorough understanding of these concepts is going to get you much further than knowing C++. Yes, I find it easier to code in C# than in C++, but what’s wrong with that? With all due respect, writing off people that rather use .NET than C++ is a bit shortsighted. Granted, the porting issue may hold, but I’ll settle for being able to publish for the Windows and Xbox360 gamer crowds, that constitute a more than interesting part of the market.
There are some nice tools here, but roping it all into .Net is a mistake. MS may like to sell this to indies but given the limited portability options it just looks like as much of a dead end as the old managed DirectX before it — used for a few niches and amateurs (especially VB coders) but not much more.
ANSI C++ is portable, full stop, no ‘ifs’ or ‘buts’. No arsing around with partially implemented, permanently out of date versions of closed source frameworks like Mono. Libraries that you need to speed development are already there, proven, stable and fast, on all the platforms you need.
Mostly this looks like a pitch at the amateur game development scene for people who haven’t got to grips with C++ development — laudable but I wonder whether it just distracts these people away from the skills they will really need to get into the game industry.