Last week we announced XNA Game Studio Express, which is a product that enables students and hobbyist game programmers to create games using C# that will run on both Windows and their Xbox 360. The XNA Framework is the set of .NET libraries that developers will code against to build their games. As we get closer to the beta, I wanted to take a few moments and explain three keys to understanding the XNA Framework—namely, the goals of the XNA Framework, what the XNA Framework is, and what it provides.
We set out to accomplish two primary goals when developing the XNA Framework:
Enable Cross-Platform Game Development
One of the key goals is to make it easy to develop games using the XNA Framework that will run on both Windows and the Xbox 360. We want to make it easy for you to develop your Windows game, for example, and then easily create an Xbox 360 version of it. Our goal is to provide a set of APIs that are about 95% normalized across the two platforms. There are some cases where we need to differentiate between the two because either the semantics are different enough that we shouldn’t hide it or there is specific functionality that is useful on one platform but not on the other. I imagine, though, that a high percentage of the games you create with the XNA Framework will in fact be 100% compatible across both platforms.
Simplify Game Development
Making games is hard. It’s hard for professional game developers and especially difficult for a student or hobbyist who is just getting into game development. It often takes a lot of code, time, and trial and error just to get to the point where you can start to draw something on the screen, or get input and make something move. One of the other primary goals of the XNA Framework is to make this much easier. As we’ve talked about this internally, we often talk about the “first 5 minutes” of the experience with XNA Game Studio Express and the XNA Framework. Our goal is for you to be able to start writing your game within the first 5 minutes of starting a project. You won’t have to worry about creating a window. You won’t have to worry about a message pump or an Idle event. You won’t need to enumerate graphic adapters and display modes. You won’t have to create a Direct3D 9 device and manage it when the window is resized or the game is minimized. The XNA Framework takes care of all those things for you. The first thing you do is write code for your game.
Another problem is content— specifically, getting content into your game and making it consumable at run time. A feature of the XNA Framework called the Content Pipeline will make getting content into your game extremely easy. Michael Klucher will be talking more about this feature in a future post, but think of it as being able to treat content just like you would your code, as a piece of your project. The Content Pipeline will take care of importing, compiling, and loading it for you.
Another aspect of the “first 5 minutes” is a set of Starter Kits that we will be providing. A Starter Kit is a complete, fully functional game that includes all the source code and media available as a project template. They are available in the New Project dialog box and create a new copy of the game for you to then modify. The aim is that if you are just getting into game programming, you can dive into a complete game and change or tweak a couple of things here or there and get instant feedback as soon as you hit F5. Each Starter Kit will come with complete documentation, including a set of tutorials that will walk you through modifying or adding features to the game.
Our efforts to simplify the game development process will continue to evolve through future releases. But our overall goal will continue to be lowering the bar for making games and opening up game development to an even broader set of would-be game developers.
When describing the XNA Framework and what it’s made of, it’s useful to think of it as a series of layers.
The platform is the lowest layer and consists of the low-level native and managed APIs that the XNA Framework is built on top of. Some of the APIs included in this layer are Direct3D 9, XACT, XInput, and XContent.
The core framework is the “first” layer of the XNA Framework and provides the core functionality that the other layers extend. If you had to associate something with Managed DirectX, it would be this layer. Found here are areas of functionality grouped into Graphics, Audio, Input, Math, and Storage. As we move forward with the XNA Framework, we’ll build out this layer to provide additional functionality.
The main focus of the extended framework layer is making game development easier. Currently, this layer has two main components: the Application Model and the Content Pipeline. As we move forward with the XNA Framework, we’ll extend this layer to make it even easier for you to write games and expand the target audience.
Games are the highest layer (even though we’re at the bottom of this list!). This layer consists of your game code and content. Also found here would be things like Starter Kits, templates, and game components.
So we’ve talked a lot about the goals of the XNA Framework and how it’s layered by functionality. But what is in the XNA Framework? Let’s take a look:
The purpose of the Application Model is to abstract away the platform your game is running on and let you focus on writing your game. You don’t have to worry about creating a window, handling the message pump, creating a timer or clock, or handling window messages. We provide all of that for you. We also provide a GraphicsComponent that makes it extremely easy to create and manage a GraphicsDevice, which you use for rendering. On the Xbox 360, you don’t need a window or a message pump to handle window messages, but you don’t need to worry about that either because the programming model is the exact same on both platforms. This is also where we provide our component model, which allows you to easily incorporate GameComponents written by others into your game. This is a great way to get up and running quickly or to build a library of reusable components. This is one area that I’m excited to watch grow as I think we’ll see some amazing things from the community and our partners.
Our Graphics APIs are based on the Direct3D 9 APIs. They started out as very similar to the MDX set of types but have gone through some pretty major refactoring and cleanup to make them even easier to use and more consistent with the .NET Design Guidelines. One big change from MDX is that we’ve decided to remove support for the fixed-function pipeline in favor of an all shader-driven programmable pipeline.
There are a few reasons why we made this decision. First, a programmable pipeline is the future of real-time computer graphics. Direct3D 10 does not offer support for fixed function. Neither does the Xbox 360. When we discussed this with some early adopters and customers, we were somewhat surprised when they stated that the cross-platform goal of the XNA Framework is more valuable than the fixed-function pipeline. The fear is that someone would start their game out on Windows and use the fixed-function APIs (perhaps without even knowing it) and get the game completed. Then they would decide to try and run it on the Xbox 360 and they would immediately get hit with dozens, if not hundreds, of compiler errors. It would be a better experience if you knew from the start that your code would work on both platforms from the start.
We realize that moving up to writing shaders and effects is a big step, so we’re trying to ease that by providing the API Migration Guide: Managed DirectX 1.1 to XNA Framework (Beta 1), as well as a BasicEffect type that is an Effect but exposes some easy to use properties such as lights and textures in a strongly typed manner so that the “first 5 minutes” experience is still in reach. You can, using the BasicEffect, get something up on the screen very quickly and easily without having to actually write a shader. Then when you feel comfortable with writing shaders and effects, or you’ve outgrown what type of rendering the BasicEffect offers, you can start writing your own shaders and effects and use those directly.
Our Audio APIs are built on top of XACT, which is the Microsoft cross-platform audio API for Windows and the Xbox 360. The idea behind XACT is somewhat similar to shaders in Direct3D. Sound authors use the XACT tool to create “packages” of sound effects and configure things like volume, looping, channel mixing (including 5.1), etc. The developer then takes the package, loads it, and can easily play sounds by name, not having to worry about initializing buffers, streaming data in, or other management. The sound author can create a “BigExplosion” sound that consists of a few different WAV files, has an LFE effect, and mixes between the other channels. The programmer doesn’t need to know any of these details; he just gets the cue for “BigExplosion” and calls Play on it. Nice and simple!
The Input API is built on top of XInput, which is the cross-platform API that drives the common controller (Xbox 360 Controller). Input offers an immediate mode API that requires no initialization. No need to worry about acquiring or releasing a device, setting the sharing mode, etc. All you need to do is call GetState on the appropriate controller type and that’s it! We provide a GamePad type that represents the Xbox 360 Controller for Windows and the Xbox 360, as well as Keyboard type for both platforms and a Mouse type for Windows.
The Storage API provides the way you can read and write game data (such as save games, high scores, etc.) in a platform neutral manner. On Windows, this isn’t a big deal since you have System.IO and the Environment methods that allow you to the correct location for the current user. On the Xbox 360, you need to associate game state with a profile and a storage device, such as the hard drive or a memory unit. Storage makes it very easy to do so, and, in keeping with the cross-platform goal, we “emulate” this on Windows so you can use the exact same code on both platforms to read and write your data.
Our Math API provides the types often used for game programming such as Vector2, Vector3, Vector4, Matrix, Plane, and Ray. We also include bounding volume types including BoundingBox, BoundingSphere and BoundingFrustum. Our bounding volume types include methods for doing intersection and containment tests. One thing to note is that our math libraries are right-handed by default. What I mean by that is on our Matrix, for example, we provide a CreateLookAt method, which provides a right-handed view matrix instead of offering a CreateLookAtLH and a CreateLookAtRH. The reason we’ve decided on going with this is to ease integration in both content and middleware components. If everyone can agree on the coordinate system, then it makes it much easier to use content or APIs from outside of the XNA Framework. I say “by default” because there is nothing that requires a right-handed system. So if you absolutely need to be left-handed (or something else) you can do so, you’ll just need to do some of the calculations yourself.
We are super focused on getting v1.0 of XNA Game Studio Express and the XNA Framework into your hands, but we are also looking at what our future releases look like. As I mentioned earlier, we will look at extending the core framework layer by adding additional functionality and we’ll look at building out the extended framework area to make it even easier to create games using XNA Game Studio Express. We will also introduce XNA Game Studio Professional, which will enable developers to create commercial games for the Xbox 360 by using the XNA Framework. Look for more details about what this means in the coming months.
I mentioned that one of the goals of the XNA Framework is to make it easier to write games; to allow you to focus on your game and not the platform. How simple is it? Well, the code below results in a working application and illustrates the basic skeleton of an XNA Framework game.
public class SampleGame : Game
private GraphicsComponent graphics;
this.graphics = new GraphicsComponent();
protected override void Update()
protected override void Draw()
static void Main(string args)
using (SampleGame game = new SampleGame())
Thanks for taking the time to read this post. I hope it explained what the XNA Framework is and what it provides. The beta will be released in just a few days, so please download it and take it for a spin. Then tell us what you liked, what you disliked, or what wasn’t clear—we want to make this the best product for you that we can.
The team can’t wait to get XNA Game Studio Express into your hands and see what you do with it!