VB.NET XNA Tutorial 1: Getting started

First things first; let's get this whole XNA thing straight.

The XNA framework is a managed wrapper for DirectX. So you'll need the latest version of DirectX installed.

XNA comes to you branded in a somewhat vaguely (and soon to be confusingly) named piece of software called "Game Studio Express". The deal is, Microsoft diverted their previous Managed DirectX project into the XNA project; the XNA project grew to include not only a managed wrapper for DirectX, but also some other tools like the Content Pipeline, and XACT. All of this was then wrapped into a software suite - not called XNA - but actually called "Game Studio Express", which was designed specifically to be an "expansion pack" of sorts for Visual C# 2005 Express Edition.

So anyway... what this all means for us VB freaks is that in order to get the managed wrapper for DirectX on our development machines, and in order to have at that Content Pipeline and XACT stuff, we have to do what everybody else has to do: install Visual C# 2005 Express Edition, and then install Game Studio Express. Which is all the more counter-intuitive for us, since our goal is to avoid using C# in the first place because we're too lazy to start using curly braces and semi-colons.

Don't worry. But you'd better get crackin'; you've got some progress bars to baby sit and many a "Next" button in your future. Enjoy it, involve a beverage perhaps.

Once you've got Game Studio Express installed, your newly acquired C# IDE gains XNA-related project options that no other IDE gets. To learn a little bit about what we're going to be missing out on in terms of XNA-related IDE options, let's go ahead and poke around the C# IDE for a sec. Run the C# IDE, and start a New Project - check out the types of projects you can start:



Go ahead and start a new Windows Game project, just to look around. Pop open the solution explorer and add a new Item to the project; check out what options we have available for creating New Items in the C# IDE:



Using the C# IDE, there are nifty items available like "Sprite Font" and "Game Component":



So those are Game Studio Express IDE hooks, they're just templates for making stuff. Nothing we can't handle ourselves.

Ok, we've seen enough. Cancel all that business and let's move over to our Visual Basic IDE.

Game Studio Express isn't going to do anything for our Visual Basic IDE, so if you go looking for a Windows Game project you're going to be disappointed



Update: The remainder of this tutorial is obsolete. A VB.NET XNA Windows Game project template for use with Visual Studio 2005 and Game Studio 2.0 Beta was posted on this blog in November 2007

But, what it has done is installed the managed XNA libraries, the Content Pipeline compiler, and tools like XACT. We've got everything we need to do some serious damage, there's just a couple things we'll have to do that the C# guys don't have to:

• 1. We will need to initiate our own project, rather than use the Game project template. And that means we'll have to create those nifty items like "Game Component" and "Sprite Font" by ourselves, too.
  
  In tutorial 20, Alan Phipps demonstrates how to start an XNA Windows Game using the Visual Studio .NET IDE.
  
  In addition to the advice he gives there, I would suggest removing the System.Drawing reference from your project, as this can create an ambiguity with items of the same name (such as Color and Rectangle) that exist in the XNA namespace.
  
  I also suggest you not wait until tutorial 20 to start making your XNA projects in this way, but hindsight is 20/20.



• 2. We'll want to use the Content Pipeline, because it's fairly cool. The Content Pipeline has some rules though - mainly it wants us to convert our resources into a "cross platform format" (something that works on both Windows and XBox360). So for example, if you have a sprite texture that's a .gif file, the Content Pipeline will want that to be an .xnb file. And sounds are even more wacky. If you make a sound resource with XACT, it will actually need to be broken down into 3 files: an .xgs file, .xsb file, and .xwb file. Yea, I know. This sounds crazy already and we haven't even started yet. Hang in there, we're almost done:
  
  The Content Pipeline hassle does seems kind of unnecessarily complicated at first. You'll like it though, I promise (and you don't have to remember those file extensions). Here's the deal: out in your 's .NET 2.0 framework folder there is a program called MSBuild.exe. MSBuild knows how to convert textures (like "spaceship.png") and sound projects you create with XACT into all those .x-blah-blah files for the Content Pipepline. It's actually really easy; MSBuild does all the work for you. You just tell it what you want to convert (pass it file names in a batch) and it converts them all for you.
  
  Now here's the catch; the way you "tell MSBuild to convert stuff in a batch" is to pass it a C# project file. Yea, like "WindowsGame1.csproj". Which kinda makes sense when you remember that all this stuff was designed to work with Visual C# Express Edition projects. MSBuild takes a .csproj file and for each resource it finds described in there, it creates a Content Pipeline .x-whatever file. With C# projects, this call to MSBuild is performed at the time the project is compiled. In XNA marketing lingo they call this "automatic". For us this will be a "manual" process... but we're lazy, so we'll automate it, and at the end of the day it'll end up being just as automatic as the next guy's.
  
  In tutorial 21, Alan Phipps demonstrates how he simply builds a "fake" .csproj file with his resource references in it, and then feeds that file to MSBuild in order to trick it into thinking it's processing a C# XNA project.
  
  Not bad! So I do the same thing, but I chose to integrate this process into my engine with a "compile" flag (rather than have it be a separate project that must be run). I'll show you how I did this in the next tutorial, and between the two you can choose to do it my way, Alan's way, or say "screw this, I'm using C#"

That's it for Tutorial 1. A little bit of dry reading, but rather than do a bunch of stuff the "wrong" way then refactor it later to the "right" way, I'd rather we just start out understanding the right way to do it. And if you managed to cram all of that into one sitting, you're doing better than I did when I first tried to understand all this stuff.

In the next article, we'll check out my adaptations of the "Start a new project" and "deal with the Content Pipeline hack" and I'll probably start brushing up against the merits of putting all of this stuff into a common project you can reuse for future games (in other words, we'll start building the engine).