Introducing the XNA Framework and XNA Game Studio
This chapter is from the book
This chapter is from the book
This chapter is from the book
Most developers I know decided to enter the computer field and specifically programming because of computer games. Game development can be one of the most challenging disciplines of software engineering—it can also be the most rewarding!
Never before has it been possible for the masses to create games for a game console, much less a next-generation game console. As a relatively new technology, XNA is going to experience tremendous growth. The sooner we get to know this technology, the better we will be able to understand the changes that will come in the future.
Microsoft is leading the way in how content will be created for game consoles. Soon other game console manufacturers will be jumping at a way to allow the public to create content for their machines. The great news for the Xbox 360 is that Microsoft has spent a lot time over the years creating productive and stable development environments for developers. We will be installing one of Microsoft’s latest integrated development environments (IDEs) in this chapter. Before we get to that, though, let’s take a look at the technology we discuss in this book—XNA.
What Is the XNA Framework?
You have probably heard the statement, “To know where you are going, you need to know where you have been.” I am uncertain if that is entirely true, but I do believe it applies here. Before we dig into exactly what XNA is and what it can do for us, let’s take a moment to look at DirectX because that is what the XNA Framework is built on.
The Foundation of the XNA Framework
Let’s take a journey back to the days of DOS on the PC. When programming games, graphic demos, and the like in DOS, programmers typically had to write low-level code to talk directly to the sound card, graphics cards, and input devices. This was tedious, and the resulting code was error prone because different manufacturers would handle different BIOS interrupts, I/O ports, and memory banks differently. Therefore, the code would work on one system and not another.
Later, Microsoft released the Windows 95 operating system. Many game programmers were skeptical at writing games for Windows—and rightly so—because there was no way to get down to the hardware level to do things that required a lot of speed. Windows 95 had a protected memory model that kept developers from directly accessing the low-level interrupts of the hardware.
To solve this problem, Microsoft created a technology called DirectX. It was actually called Windows Game SDK to begin with, but the name was quickly switched after a reporter poked fun at the API names DirectDraw, DirectSound, and DirectPlay, calling the SDK “Direct ‘X.’” Microsoft ran with the name, and DirectX 1.0 was born a few months after Windows 95 was released. I remember working with DirectDraw for a couple of demos back when this technology first came out.
Because of DirectX, developers had a way to write games with one source that would work on all PCs, regardless of their hardware. Hardware vendors were eager to work with Microsoft on standardizing an interface to access their hardware. They created device drivers to which DirectX would map its API, so all of the work that previously had to be done by game programmers was taken care of, and programmers could then spend their time doing what they wanted to—write games! Vendors called this a hardware abstraction layer (HAL). They also developed a hardware emulation layer (HEL), which emulates hardware through software in case hardware isn’t present. Of course, this was slower but it allowed certain games to be run on machines with no special hardware.
After a couple of years, Microsoft released DirectX 3.0, which ran on Windows NT 4 as well as Windows 95. As part of those upgrades, Microsoft introduced Direct3D. This allowed developers to create 3D objects inside of 3D worlds. DirectX 4 was never released, but DirectX 5 was released in 1997 and later had some upgrades to work under Windows 98.
When DirectX 8 came on the scene in 2000, some of the newly available graphics hardware had vertex and pixel shaders. As a result, Microsoft added in a way to pass custom program code to the hardware. Through assembly code, the game developer could manipulate the data the main game passed to the graphics card. This assembly code was consumed directly by the graphics hardware.
When there was no graphics hardware, games were slow, but they were very flexible. Later, as hardware rendering became prominent, the games were faster, but they were not very flexible in that all of the games really started to look the same. Now with shaders, the speed of the hardware is combined with the flexibility for each game to render and light its 3D content differently.
This brings us to present-day DirectX: We are up to DirectX 9 and 10. Before I talk about DirectX 9, I’ll spend some time talking about DirectX 10. DirectX 10 was released at the same time as Microsoft Windows Vista. In fact, DirectX 10 only works on Vista. This is largely due to the fact that Microsoft has made major changes in the driver model for this operating system. DirectX 10 also requires a Shader Model 4.0 graphics card.
The Xbox 360 runs on DirectX 9 plus some additional partial support for Shader Model 3.0 functionality. DirectX 9 is the foundation for Managed DirectX, an API that exposed the core DirectX functionality to .NET Framework developers. There was a lot of concern about whether this “wrapper” could be as fast as the C++ counterparts. Fortunately, it was almost as fast—about 98% was the benchmark touted. I experienced these benchmark speeds firsthand while on the beta team for this technology. I fell in love with Managed DirectX.
The XNA Framework took the lessons learned from Managed DirectX and used that foundation as a launching pad. To be clear, XNA was built from the ground up and was not built on top of Managed DirectX. It doesn’t use the same namespaces as Managed DirectX and is not simply pointing to the Managed DirectX methods in the background. Although XNA utilizes DirectX 9 in the background, there are no references to DirectX’s API like there were in Managed DirectX.
XNA Today
XNA is actually a generic term, much like the term .NET. XNA really refers to anything that Microsoft produces that relates to game developers. The XNA Framework is the API we are discussing. The final piece to XNA is the XNA Game Studio application, which we discuss in detail later. This is the IDE we use to develop our XNA games.
XNA allows us to do a lot of things. We have easy access to the input devices (keyboard, game pad or controller, mouse). XNA gives us easy access to the graphics hardware. We are able to easily control audio through XNA. XNA provides the ability for us to store information such as high scores and even saved games. XNA also has networking capabilities built in. This was introduced in version 2.0 of the product. Microsoft uses the Xbox LIVE technology for network support.
To get started using XNA, you have to install some software. You need to install the latest version of DirectX 9 as well as have a graphics card that supports DirectX 9.0c and Shader Model 1.1. (You should get a card that supports Shader Model 3.0 because some of the examples, including the starter kit we use in this chapter and the next one, will not run without it.) You also need to install Visual C# Express or one of the other Visual Studio SKUs, the DirectX 9 runtime, and finally XNA Game Studio. Fortunately, all of the software is free! If you don’t have graphics hardware that can support Shader Model 2.0, you can pick up a card relatively inexpensively for about US$35. If possible, you should purchase a graphics card that can support Shader Model 3.0 because a couple of examples at the end of the book require it. Windows Vista machines have graphics cards that support Shader Model 4.0 and definitely meet the needs of our XNA games.
In the past, only subscribers to the XNA Creators Club could play the games made by other developers. Xbox LIVE Community Games, introduced in version 3.0 of XNA Game Studio, has changed that. Through a peer review process, games can be approved and put on Xbox LIVE for the world to download. Never before has there been such an easy way for a game to be seen by so many people.
Not only is XNA Game Studio great for the professional, it is great for the game hobbyist, the student, as well as someone just getting started because you do not have to shell out a lot of money to get up and running. One exception to this is if you actually want to deploy your games on your Xbox 360. To do that, you need to subscribe to the XNA Creators Club for US$99 a year (or US$49 for four months). Writing games for the PC using XNA is totally free! As an added benefit of paying for the Creators Club subscription, you are able to review other creators’ games and are able to submit your own games to sell on Xbox LIVE Marketplace. This is discussed in Part XI, “Xbox LIVE Community Games.”
Oh, in case you are wondering what XNA stands for, XNA’s Not Acronymed (or so Microsoft says in the XNA FAQ).