Let's talk about games and, more to the point, the making of games. I'm going to start a weekly column (here!) sometime next week entitled "Mechanics" where I'll do my gamer/designer thing by choosing a game that I've been playing recently and analyzing a certain mechanic or set of mechanics that, I think, are remarkable in some fashion. But that's next week.

Microsoft did this really rad thing when they released the XNA Game Studio a couple years ago as a means of giving hobby game developers a means of creating games with a toolkit/API specifically designed for hobbyists that were interested in creating games. This isn't the first time the company has done something like this, as DirectX fills a similar sort of need, but with XNA Microsoft decided to step up their game. So to speak. XNA is best described as the marriage of the higher-level aspects of DirectX, Microsoft's own C# (a managed language), and the benefits of both the PC platform and the Xbox 360. The end result is a vastly more approachable environment for game development without a lot of the limitations of setups like Blitz Basic and pygame without overloading the less programmaticly inclined wannabe-game developers that may get scared off by the concept of working with C/C++ and DirectX or OpenGL.


With the original release of XNA almost two years old that is all old news; XNA 3.0 is currently in beta and will launch with an Xbox 360 XNA game browser capable of displaying and delivering XNA games made by the hobbyist/independent game developer community to the Xbox 360 owning masses in a Youtube-like fashion. That's the idea, anyway. When I submitted my first XNA game I apparently crashed the console of the person who was reviewing my submission. I, apparently, failed to package the game correctly or something. Either way, my first game, which I'll talk more about in a moment, was far from being up to snuff for any sort of widespread public release so the peer reviewer was probably just doing me a favor. The point is that XNA allows game developers to deploy games to the Xbox 360 with an only an absurdly trivial process required to setup the PC/Xbox 360 XNA game compatability. As far as building a copy of the source code for deployment to the Xbox 360? Well, once the XNA Game Studio executable has been installed and setup the only action required by a user is to right-click a project and select "Create Copy of Project for Xbox 360 [or Zune]." The first time I was able to see my game on my 360 it was exciting, to say the least -- though, to say the honest answer, the first time I saw my game on my 360 I realized that I didn't setup a way to deal with the interface without access to a mouse. Nor did I map a button for escaping the program. These realizations are all part of the experience.

That game I made was the first full game I've ever made. I called it Asplode! which, along with my current game Cubegasm, make for some very awkward conversations of the "Uh. What was the name?" and "I didn't catch that" variety, but that's neither here nor there. Coming from a C/C++ background with absolutely no thought paid to the concept of actually learning C# before utilizing it for a full game yielded some very awkward optimizations when describing my project to new people. Despite the many faults that Asplode! had it was a lot of fun for me to work on and, more to the point, it was the kind of learning project I needed to get my codebase the kickstart it needed for an actual 3D game project.

The lack of familiarity with C# is one of the reasons I'm writing this: with the release of XNA 3.0 due in the next few months, there is one very important thing that any XNA game developer needs to understand: memory management is necessary even within the confines of a managed language. The primary difference between working in a language like C/C++ and C# is that, in C/C++, memory is managed very carefully by the programmers and the task is, more or less, given to a developer whether he/she likes it or not. C#, however, cozies up to new programmers and holds their hands while all sorts of terrible code is written that may not rear its ugly head until the worst possible moment (end of the project). C# has an automatic garbage collector that, as the name implies, cleans up loose objects when they go out of scope/use. On the PC, the garbage collector is generational and can perform different types of collections ranging from gen0 (fastest; performed on simple object types with no finalizers) to gen2 (a full collection that actually halts the execution of a program). This is important to keep in mind for XNA game development for the PC platform but, on the Xbox 360, the garbage collector issues become more pronounced as the 360 GC isn't generational so when it fires it actually has to pause all of the currently running threads while it does its thing.


This brings me to the impetus for writing this little introduction to a two-year-old system. For Cubegasm, my current action/RTS, I need vastly more complicated methods of handling rendering, updating, and then collision detection (along with a basics physics simulation layer). Now, I'm no good at physics nor am I a prodigy when it comes to the kind of calculus that is saved for a third- or fourth-semester college class but, due to the infancy of XNA as a community there isn't an abundance of "middleware" that exist for C/C++ applications. When I was interested in integrating a physics solution into my game I heard good things about Bullet and, subsequently, BulletX but when I actually tried it in my project I discovered that it fired off the garbage collector every two seconds or so (down from the two times immediately after initialization that I had my game firing it at). So, as an aspiring game developer that wants to write his/her own program from scratch here's what I'm going to recommend: think carefully about your game design. Ambitious is great, I encourage it, but no one ever got anywhere by being overly ambitious about a game project that, eventually, disheartened everyone involved with it to the point that it gets cancelled. And, if your target platform is the Xbox 360, then remember that your game isn't going to be running on the latest greatest PC hardware but, rather, the hardware that is within every Xbox 360. What runs great on the PC is almost certainly going to run much slower on the Xbox 360 due to less powerful hardware, memory restrictions, developer assumptions about the system, and so on.

Now for a list of communities/blogs that will almost certainly prove invaluable:

• The XNA Creator site.


• GameDev.net.


• Shawn Hargreave's blog.


• Eli Tayrien's blog.


• Michael Klucher's blog.


• Nazeeh ElDirghami's blog.


• Stephen Styrchak's blog.


• XNAInfo blog.

In the end, remember: if you use XNA then you, despite being the kind of developer that has no publisher backing, money source, or the kind of time/manpower that full studios have, have the ability to develop a game for a goddamn console. Just think about how cool that is.

For the interested, along with the release of Asplode! I packaged up the project source code because I thought that it may prove useful or interesting to someone. It's not incredibly well-organized or commented but I'm still using some of it for Cubegasm so it can't be all bad.