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 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.
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.
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.
Several members of the XNA Game Studio Team have blogs on which they post XNA-related tips, techniques, and tutorials.
The following references will provide you with more information about developing with the XNA Framework.