After a very small and virtually unidentifiable break from the monolithic RTS series, I decided that it was time to put my completely empty wallet's worth of money where my ever-so-large mouth is and get to work on developing some sort of game. Yes, that's right. I am actually going to work on a project that doesn't (d)evolve into me getting obsessed with some component of the overall tech which I eventually spend months trying to perfect. I, this time, pinky-swear (cross my heart, etc.) that I'll see a project through to the end. That's the goal anyway.

Stop laughing.

Microsoft's XNA and Game Studio Express
When I first got the idea for the kind of game I wanted to create, I also figured that I'd try something completely new in the way I went about developing it. Microsoft's new development framework XNA was released as a public beta mere days before I decided to get back into programming, so I figured: Hey, why not. In doing a very minimal amount of research, I downloaded the accompanying Game Studio Express assuming that it was the necessary course of action. And then I realized that, in order to properly install GSE, that I needed to have Visual C# Express installed. Granted, I had never had absolutely any experience with C#, but that didn't seem like an entirely crucial detail to the whole endeavor.

XNA is, to my understanding, a very user-friendly API (or "framework"). It's not an "engine" as I've heard some of my cohorts try and label it as. It's basically a collection of Managed DirectX functionality along with very easy-to-use audio/input solutions with a bunch of other game-centric functionality (math and storage utilities, for instance) all combined into one handy-dandy framework. The most crucial thing about XNA -- which, as far as I can figure, stands solely for Ex-En-Eh -- is that it's a set of tools built around making cross-platform development between Windows and the Xbox 360 as easy as possible. Basically, by signing up to Microsoft's Creator's Club ($49 for a four-month subscription and $99 for a year-long subscription), developers can release their creations on the Xbox Live Marketplace for 360 users to download, use, and abuse in their game-playing shenanigans. I'd assume that these creations would have some sort of warm and snuggly place in the Xbox Live Arcade where other games of an indie persuasion have found a home; games like Roboblitz, Geometry Wars, and Marble Blast Ultra.


Game Studio Express.

As far as I understand, the differences between development for Windows and 360 games, as far as Ex-En-Eh is concerned, are minimal. Windows developers would have access to the full .NET Framework whereas 360 developers would have access to the .NET Compact Framework, but that's the only significant departure from the norm that I've noticed thus far. What exactly the "Compact" portion of the name means, I can't really say, but the MSDN docs say that the .NET Compact Framework "has been optimized to leverage and expose the power of the Xbox 360."

My first misgiving with the whole XNA deal is that some of the Game Studio Express features cannot be integrated with the full-featured Visual C# version of the IDE -- namely some of the templates and, now, the content pipeline features. This was especially a problem for me during the first beta of GSE where, for whatever reason, I was completely unable to get some of the customization aspects (syntax highlighting scheme, in particular; I'm picky) of the IDE working in any capacity. This was a problem remedied with the second beta, though, and I've been using GSE ever since. I've always considered the Visual Studio package to be the greatest development environment I've ever used, and Visual C# (Express version or not) is no exception. The fact that Game Studio Express is a free IDE custom-tailored for use with the XNA Framework is such a tremendous boon to the not-so-well-finances (read: broke) developers is so many measures of "Amazing."

When I was starting up development of my current project, I really had no intention of ever taking advantage of the cross-platform development goodness that Microsoft swears XNA will allow me, but it still seems like a pretty slick deal even without the console platter entering into the mix. Starting up a new project in Game Studio Express, I was offered the user-friendly version of choosing between a "Windows Game," a "Windows Game Library," an "Xbox 360 Game," and an "Xbox 360 Game Library." I, as stated, was intent on going the Windows game direction, but a couple of the choices in the New Project menu distracted my sporadically-ADD self from my goal: SPACEWAR. Since I had done little-to-no research into this whole new Microsoftcentric development option, I really had no idea exactly what kind of project a Spacewar was, nor what kind of requirements I would have to meet in order to hold myself up to the level of Spacewar developer… So that was the first thing I did.


Spacewar (XNA Starter Kit).

As it turns out, Spacewar is considered an XNA/Game Studio Express "starter kit" and is, in itself, a fairly well-done simple game of one-vs.-one Asteroids (screenshots below). The kit itself is an entire project template consisting of all of the game's assets and code organized for what I'd suppose are experimentation and idea purposes for developers. There's an entire information page that greets the developer that decides that a war in space seems like a good first step in the XNA development cycle and it details the basic idea of the game and why it's included with GSE along with extension ideas for developers who decide that screwing with another developer's rhubarb is the best way to get off on the right metaphorical track. This, in my opinion, is a downright intelligent move on behalf of Microsoft; it's a great way to ease new developers into their game-development system by a learn-through-example tutorial method. It wasn't something that I personally played around much with, but it's still a very nice addition to an entirely free package.

My Experiences
The first step in the beginning of the development of my current project, after I decided on using XNA/GSE/C# was to, you know, actually learn the basics of C#. Thankfully, this turned out to be a far easier task than I had originally anticipated as the similarities to C++ are numerous and many. The biggest problem that I had a difficulty adapting to was the differences in memory management between the two languages. C#'s memory management seems to be more focused on short-term memory allocation and simplicity whereas C++'s required far more handholding and monitoring on the part of the developer. Other than that required adaptation (along with pointers/references), though, I've found the jump to C# to be very friendly and, for the most part, I'm actually finding some of the more subtle changes between the two languages to be helpful.

For more in-the-know programmers, I think the best way to describe the XNA Framework would be to combine Managed DirectX with the D3DX functionality and add-on a far more simple set of input, audio, I/O, and content alongside it. This is a more pronounced similarity now than it was during Beta 1 when I started experimenting with the thing, though. When I started, the Content Pipeline (more on this in a bit) was not in place whatsoever and the input system wasn't quite as user-friendly as it is now.

The one downside about starting development in an entirely new environment is, just that: starting development in an entirely new environment. All of the frameworks and utilities that I built up during my years of C++ OpenGL/Direct3D development were pretty much rendered useless; thankfully, I wasn't reminded of that due to the fact that I've essentially lost a very hefty majority of my work from the last year and a half due to a series of hard drive crashes (an occurrence which stung). So when I got started with the whole XNA thing my first task was to get a basic mouse/keyboard input system up and running (this is after I got a basic project up and running and got a bit more familiar with C#). After that, I got a first-person camera system up and running -- and, for the record, spring dampening can be tepidlyincredibly annoying.

I realized one of the most glaring omissions from the XNA framework shortly after I started developing the input system. While I was working on the mouse input (and the how to handle it), I thought it would be nice to get some kind of on-screen representation of the values it was nabbing, just to ensure that my code wasn't completely incorrect. So, in looking around for the simplest and quickest way to render some text to the screen, I discovered that there was no inherent functionality for bitmap fonts within the framework. This seemed a pretty odd thing to leave out of a framework which, for the most part, has a pretty strong focus on making the most basic aspects of small-time game development as simple as possible. That said, there was a set of third-party utilities released called XNAExtras which were done by an at-the-time Microsoft employee that handle the Bitmap Font job very nicely.

After all the graphical housecleaning was done and finished, I moved on to actually working on some of the more game-centric components of the… game. First was terrain (tee-hee), which actually proved to be more of a chore than I had originally intended. Yes, yes, I'm quite aware of how a simple brute-force terrain implementation could cause me trouble is funny to some for whatever reason… Though it wasn't the geometry that was causing a problem so much as it was the vertex normal calculations, but this, like so many other bugs in the history of development, was eventually resolved. Silly indices. Here's the evolution of this beautiful, elegant, well-coded brute-force terrain implementation:


Terrainstuffs.

Since I'm still trying to work out the kinks and the rust in my own ability to program, I've been sticking to topics of development that are close to my heart. So, yeah, terrain engines were first, and lately I've been working on a fairly elaborate (ish?) particle engine. The basic structure of the thing, as far as my handling of it is concerned, is that there are particles contained within the blanket of a general particle system which would manage and render all of the particles under its control. A particle effect, then, would be a collection of systems which would generate a single effect; for instance, a "fire" effect would have the flame, the smoke, and maybe the sporadic spark. An explosion could have sparks, fire, smoke, and debris all under the veil of a single "effect." The whole thing is pretty much completed as of now, I just have to allow the effects to be created from a file and that do 'er. Here are some shots of the thing:


Particlestuffs.

I am, admittedly, not much of an artist. I do have a decent sense of color coordination and what looks good, though. So for my game (which is, as of now, an entirely Trent-centric project) my goal is to make it look as good as possible with only a very marginal requirement for outside art. What this will, most likely, mean is that some of the assets are going to be procedurally generated, and I'm going to rely a whole lot on vertex/pixel shaders and post-processing effects to handle the burden of the aesthetic feel of the game as a whole. If I had to compare what I'm shooting for to a pre-existing game, I'd probably say that Darwinia wouldn't be too far off the mark; it's got a very stylized look that is, admittedly, one of the few things I thought the game executed perfectly. So if I could even begin to approach its style, then I'll consider it a job well done.

I have some of the details of the game worked out, but for the most part it's a design that is entirely in my head (and some scattered drawings on a whiteboard) that I'll have to wait until I have a better framework of utilities in place before I actually begin developing the gameplay. For the next couple of weeks, I plan to work very extensively on getting the visual style of this game-to-be worked out, though, and I'll probably post occasional updates on how that fares.

That's about it for now.