Share via

XNA Framework Overview

  • Article

The XNA Framework is a set of cross-platform managed libraries for game development on Windows, Xbox 360, Windows Phone 7, Zune, Zune HD, and Microsoft Surface. First introduced in 2006, releases of the XNA Framework are tied to releases of XNA Game Studio. Version 4.0 was released on September 16, 2010 as both a stand-alone download and bundles as part of the Windows Phone Developer Tools. The previous version, XNA 3.1, was released on June 11, 2009.

XNA 4.0 is built on the .NET Framework 4.0 Client Platform. Earlier versions of the XNA Framework were built upon .NET Framework 2.0 (for Windows) and .NET Compact Framework 2.0 (for Xbox 360 and Zune).

XNA Framework Application Model

The XNA Framework application model is very different from the event-driven model in which most applications developers work. Most game development uses a polling loop model and XNA is no different. The central class for any XNA game is the aptly named Game class. More properly, it is a class that inherits from Game and overrides some of its methods in order to process input and draw your game on the screen. This Game-derived class is normally named Game1 when you create a new XNA game from one of the Visual Studio templates but it can have any name.

XNA Games are normally written in C#. While it should, in theory, be possible to use any .NET language for XNA development, C# is the only officially supported language and all templates and code samples from the XNA team are written in C#. An XNA game begins its life the same way as any other C# program, namely at its Main method. The Visual Studio templates put Main inside a static class called Program. Main creates a new instance of the Game-derived class (which we'll call Game1 from here forward) within a using block and calls its Run method. Game1's constructor initializes several class fields such as the GraphicsDeviceManager instance which manages the game's GraphicsDevice instance. The GraphicsDevice is the central graphics component of an XNA game. Through it (directly for many 3D applications, indirectly when using the SpriteBatch class to draw in 2D) all graphics appear on the screen.

It is standard practice to set the GraphicsDevice's back- buffer width and height within the Game1 constructor by setting the GraphicsDeviceManager's PreferredBackBufferWidth and PreferredBackBufferHeight fields to the dimensions you intend your game to run at. On the Xbox 360 it is common to set the back buffer to 720p (1280x720). The Xbox 360's hardware scaler will automatically scale up from there to 1080p and down to the old 480i (640x480) that SDTVs run at. Due to a hardware constraint, the Xbox 360 cannot properly scale down from 1080p to 480i. As such, development at 1080p requires a separate rendering path to handle drawing to SDTVs appropriately. For this reason, many developers elect instead to work in 720p. On Windows Phone 7, the screen dimensions are 800x480 in landscape mode when you Game.IsFullScreen is set to true (this hides the phone status bar) and 480x800 in portrait mode when IsFullScreen is true. Though it is possible to develop a game that works in both portrait and landscape mode, most developers pick either portrait or landscape and then stick to that one mode.

Once the constructor has finished, the Main method calls Game1.Run. This begins things. The GraphicsDevice itself is created. An instance of the ContentManager class is also created and assigned to the Content property. Game1's Initialize method is called, then Game1.LoadContent after which point the game enters a loop, calling Update and then Draw over and over again until player signals an intention to quit, at which time Game1's Exit method should be called to provide an orderly winding down and exit from the application. When exiting, Game1's UnloadContent method is called. Any resources that implement IDisposable that you create (excluding those you loaded through ContentManager) should be disposed of in UnloadContent. When UnloadContent is finished, the XNA Framework calls the Unload method of the ContentManager it created for you, which releases and disposes of all assets that had been loaded. Then the game does some final internal cleanup work and exits.

The reason this is called a polling model is because no events fire when your game receives input or when it needs to be redrawn. Instead, you check the input devices for input every time Update is called and act upon that input accordingly (e.g. to make something move around on screen or try to use an item). When Update finishes and Draw is called, you start by clearing the back buffer to some color in order to eliminate the previous contents and then begin drawing the scene as it should appear currently. The "back buffer" gets its name from the fact that it acts like a screen in back of the actual screen that the player sees. There are two buffers. Every single Update-Draw loop those two buffers "flip". The buffer you had just drawn in during the previous Update-Draw loop is switched forward and drawn to screen while you take the buffer that had been drawn on the screen during that last cycle, clear its contents ,and then draw the scene as it should appear now. Then when you finish drawing, Update is called again and the cycle begins all over.

Game Time

Game time is a very important concept in game development. In order to make things appear smooth, you need to make sure that movement on screen is proportionate to the amount of time that has passed in the real world. There are two ways to control the game time: use a fixed time step or use a variable time step.

A fixed time step tries to run the Update-Draw loop a fixed number of times per second. As long as the Update-Draw loop takes less than X milliseconds where X = 1000 / the number of Update-Draw loops per second, the game will update smoothly. If an Update-Draw loop takes too long, then the XNA Framework switches itself into "IsRunningSlowly" mode. In order to catch up to where it is supposed to be, it simply skips over Draw and makes back-to-back calls to Update until everything has caught up. Then it begins drawing again. The reason for skipping draw is because though it looks bad, the game logic itself, i.e. all of the stuff in Update such as your input handling code and your code that moves the player around and adjusts enemy positions and does all other non-drawing things that your game requires, is far more important. If that gets desynchronized then the player's input starts being disregarded (if Update were never called then it would be impossible to check input and thus impossible even to quit the game without turning off the system) and other bad things happen as well. Since the Draw method should have no impact on your game's logic but instead simply draws the results of what happened in Update on the screen, it's much better to skip a Draw call or two if something must be skipped. This skipping of draw causes a visual stutter, though, which doesn't look good and leaves players underwhelmed.

A variable time step just continually runs Update and Draw one call after another. If one cycle take a little longer then the amount of elapsed gametime that is passed in to your Update and Draw methods by the XNA Framework when it calls them will simply be larger than it was previously. Televisions, monitors, and other screens typically redraw themselves at a fixed interval. This time period is called the vertical refresh rate. It is typically measured in "hertz", abbreviated hz, which means "cycles per second". A refresh rate of 60hz, which is typical for most TVs and monitors, means that the screen redraws itself 60 times per second. When using a variable time step, you can either synchronize with the vertical refresh rate, which means that the framework will wait until the time in between when the screen has finished redrawing itself and it begins redrawing itself again to swap the two buffers, or you can choose to not synchronize with the vertical refresh rate. Not synchronizing can cause a visual artifact known as screen tearing. What happens is that the two buffers swap while the screen is in the middle of redrawing itself. If the image is static or scrolling vertically then it's unlikely that this swap will be noticeable. If however, there is horizontal movement of things on the screen then the swap causes objects that are moving that intersect the scanline on the screen where the buffer swap happened to stay in the place where it was drawn while everything underneath it shifts to the left or right (depending on which direction the object is moving). At its extreme it could cause things like having a character's head floating off to the side of his or her body or having things like trees and walls look like they were caught in a weird, sideways earthquake.

The XNA Framework defaults to a fixed time step that tries to draw 60 frames per second on Xbox 360 and Windows PCs and 30 fps on Windows Phone 7 (in order to preserve battery life and provide a good user experience). You can switch to a variable time step if you wish. By default the XNA framework in variable time step mode will synchronize with vertical refresh. You can change that too if you like. Which type of time step you choose is often a matter of personal preference. Objectively, a fixed timestep is probably better on plaforms with standardized hardware such as Xbox 360 and Windows Phone 7 while a variable time step is probably better on platforms with variance in hardware level such as PCs (which can have different CPUs, GPUs, amounts of memory, etc., all of which will change how fast your game runs on it). But time step choice is often a subjective choice based on personal preference and each system has its own merits. Fixed time step will more easily reveal any performance hitches your game might be having due to the visible frame skips which in turn can help you identify and optimize slow areas of your code through the use of profiling software. Variable timestep will smooth over the occasional performance hitch since it won't skip any frames, but it requires far more care on the developer's part to ensure that all movements are adjusted by the amount of time that passed between frames. It can also make your game feel slower and occasionally get a languid look to it if a few cycles take a particularly long time, though there's nothing you can really do about that, unfortunately. Whichever you choose, it's important to always make sure you adjust movement amounts by the amount of elapsed time from the last frame in order to ensure that everything is really where it is supposed to be when the player looks at it.

Content Pipeline

The Content Pipeline is a special set of assemblies that use MSBuild to compile game assets such as image and sound files into streamlined, pre-processed binary files called XNBs (so named for the fact that the file extension of the compiled version of a source file is changed to .xnb) which load quickly at run-time. The Content Pipeline is only available on Windows.  For XNA 4.0 it requires the full .NET Framework 4.0. Previous versions of the Content Pipeline require the full .NET Framework 2.0. The Content Pipeline requires the full .NET Framework due its use of MSBuild.

XNB files are platform-specific and are designed to be loaded using the XNA Framework's ContentManager class and related internal helper classes without the Content Pipeline assemblies. As such, content built with the XNA Content Pipeline can be used at run-time despite the fact that the Content Pipeline might not exist on the target platform. The Content Pipeline is not included with the XNA Framework Redistributable and the XNA Framework EULA prohibits the distribution of the Content Pipeline assemblies except as packaged with XNA Game Studio.

For more on the Content Pipeline see the Content Pipeline Overview.

Platform Framework Version(s) Supported

The following is a list of which versions of the XNA Framework can be used with the platforms on which the framework can be used for development.

  • All versions of the XNA Framework have supported both Windows and Xbox 360 development.
  • As of February 8, 2011, only games developed with XNA 4.0 can be submitted to the Xbox LIVE Indie Games Marketplace.
  • XNA 3.0 and XNA 3.1 support Zune development.
  • XNA 3.1 supports Zune HD development. Development for Zune devices is not supported in XNA 4.0.
  • When used in conjunction with Surface SDK 1.0, XNA 2.0 and XNA 3.0 support Microsoft Surface 1.0 development.
  • The upcoming Surface SDK 2.0 will include support for developing Microsoft Surface 2.0 games and applications with XNA 4.0.

Blogs

Several members of the XNA Game Studio Team have blogs on which they post XNA-related tips, techniques, and tutorials.

  • Shawn Hargreaves Blog. Shawn's blog contains a wealth of information on all areas of XNA development. Along with the MSDN Library documentation, it is one of the best sources of information about how the XNA Framework works and how to use it in your applications. 
  • Aaron Stebner's WebLog. Aaron's blog is a great resource to turn to when you are having problems installing or using the XNA Framework development tools such as XNA Game Studio and the Windows Phone Developer Tools. He has many excellent posts on diagnosing and troubleshooting issues with the tools along with helpful posts on many other topic areas such as WiX, the .NET Framework, and Visual Studio.
  • BadCorporateLogo. BadCorporateLogo is Stephen Styrchak's blog about XNA Game Studio and related technologies. It contains a number of very helpful posts about using the XNA Game Studio tools, particularly about the XNA Content Pipeline.
  • Michael Klucher's Blog. Michael is the Senior Program Manager for LIVE Mobile. His blog is primarily a mixture of XNA tips and news.
  • Nerd Herder. Nerd Herder is Dean Johnson's blog about working on the XNA platform and tools team. He has a number of good articles on the use of Xbox LIVE avatars in XNA games developed for the Xbox 360.
  • Nick Gravelyn's Blog. Nick's blog contains a number tips and techniques that will help you become a better developer within the confines of the XNA Framework.
  • XNA Game Studio Team Blog. The XNA Game Studio Team Blog is updated periodically with news that is likely to be of interest to the XNA community.
  • Windows Phone Developer Blog. The Windows Phone Developer Blog helps keep Windows Phone 7 developers (both Silverlight and XNA) up-to-date on the latest developments within the WP7 community. Posts range from news about updates to the Windows Phone Developer Tools to updates to the Application Certification Requirements to information about new learning materials and more.

References

The following references will provide you with more information about developing with the XNA Framework.

  • App Hub. The App Hub, formerly known as the XNA Creators Club Online, provides a broad range of code samples and a very active forums section. The App Hub is also where developers wishing to develop for the Xbox LIVE Indie Games marketplace and the Windows Phone 7 marketplace register to do so. There is a registration fee associated with developing and testing games and apps for the two marketplaces. The fee is currently waived for students who are registered with the DreamSpark program who wish to test and submit games and applications for the Windows Phone 7 marketplace. DreamSpark registration also enables students to deploy XNA games to their Xbox 360 for testing, but does not enable them to submit games to the Xbox LIVE Indie Games marketplace or to playtest or peer review other creators' games. All other site access and materials are free. The forums require registration but do not require payment of the fee. Please note that the "publisher name" you choose when you register will be permanently associated with the LIVE account that you link to your registration and cannot be changed. As such, you are highly encouraged to consider your selection of a name carefully so that you choose one which you will be happy with in the future.
  • App Hub - Getting Started Guide. The App Hub's getting started guide is the best place to always find the most current version of XNA Game Studio and the Windows Phone Developer Tools. It also has links to documentation, tutorials, and videos that provide a very nice introduction to developing with XNA and Silverlight for Windows Phone 7.
  • Windows Phone 7 Training Course - XNA Framework 4.0 for Windows Phones. The MSDN Windows Phone 7 Training Course series provides a great set of hands-on labs and videos to get you started with XNA game development.
  • MSDN Library - XNA Game Studio 4.0. The XNA Game Studio documentation on the MSDN Library provides a very nice introduction to the XNA Game Studio development environment and to game development with the XNA Framework. The XNA Framework Class Library Reference and Content Pipeline Class Library Reference are also found here.
  • XNA Development - Game Development for the Masses. XNADevelopment.com is a community site run by George Clingerman, one of the XNA MVPs. His tutorials have been the first introduction that many developers have had to XNA. They provide a nice step-by-step introduction to the fundamentals of game programming with XNA.
  • Bob Taco Industries -> Links -> XNA - All. BobTacoIndustries.com is a site developed and maintained by Michael B. McLaughlin. The "Links" page in the "For Devs" section provides a curated collection of links to a variety of .NET programming topics, including XNA development.
  • Sgt. Conker. Sgt. Conker is a community site maintained by several XNA developers, among them Catalin Zima, one of the XNA MVPs. It tracks the latest news within the XNA community and also hosts a number of excellent articles and tutorials concerning XNA game development.
  • #XNA hashtag on Twitter. The #XNA hashtag on Twitter is a great way to connect with fellow XNA developers, find out what others are working on, and let everyone know how your own XNA projects are coming along. It's also usually a good forum for quick answers to small questions.
  • MSDN Library - Surface SDK 1.0 SP1 - XNA Quick Start. A tutorial for creating a basic XNA application for Microsoft Surface 1.0 using Surface SDK 1.0 SP1.
  • MSDN Library - Zune Programming (XNA 3.1). MSDN Library documentation on special considerations when programming for Zune devices with XNA 3.1.