XNA Content Assistant

The logistics of how content gets built in the VB template will change when GS 3.0 is released. Rather than hard-code all of the content building specifics into the VBContentManager class, this functionality has been moved into a stand-alone application, which will act as a bridge between a non-Game Studio project and the Content Pipeline. This application is called the XNA Content Assistant, and is a Windows form application with a graphical interface. However, it also supports being called from the command line in an invisible mode.

I'm currently putting the XNA Content Assistant through beta, naturally I want to debug such an important component thoroughly. It is functional at this time, and so here's a preview of what it looks like, and what it does:



You start out by opening your game's Visual Studio or Visual Express project file. (when running from a command line, you would supply this as an argument)



Based upon the location and contents of the specified project file, the XNA Content Assistant will automatically determine where your content folder is (even if you did not name it "content"). It will then automatically determine which XNA framework version your game is programmed against. The XNA Content Assistant understands how to build content for Game Studio Express (1.0 Refresh) projects, Game Studio 2.0, and Game Studio 3.0 projects created in either VB or C# in Visual Studio 2005, 2008, and the Express editions.

On the GUI, we can see the Assistant has successfully harvested content from my "Timeclock" application, and I am proceeding to select a platform (this would be the 2nd and final parameter you would need to supply via command line)



And lastly when we execute the build process, we can see that MSBuild's output is integrated nicely into the Assistant's UI, to help troubleshoot build issues such as missing fonts, etc. It also exports a log and a copy of the content project submited to MSBuild in your project's folder for reference.



As future XNA versions are released, XNA Content Assistant will be updated and your existing template can simply continue to utilize the updated Assistant, rather than requiring code changes to the template itself (i.e., the VBContentManager class, which will be largely obviated by the Assistant).

XNA 3.0 CTP

The XNA/GS 3.0 CTP is out and I'm in the process of updating the VBContentManager in preparation for the official release.

XNA 3.0 content processing expects to use the .NET Framework v3.5 edition of MSBuild. For those not interested or ready to move to XNA 3.0, XNA 2.0 compatibility will be retained in the VBContentManager.

To that end, the GS 3.0 release will mark a small change in how the VBContentManager works. A version enumeration is now required by the VBContentManager class, and moving forward, the VBContentManager will be augmented with new version support (rather than replaced wholesale) so that future editions of the VBContentManager can target prior XNA versions (dating back to 2.0). Just pass in which XNA version you're targeting, and it will process your content accordingly.

The VBContentManager currently available for download was never updated with functional, XACT-based audio importing. I do have this working in my "production" VBContentManager, and as part of the 3.0 update I will include this for backward compatibility with 2.0's XACT-based audio. And of course the new audio importing for 3.0 will be available as well, which is what I'm working on now.

Microsoft.VisualBaggage

Here's an interesting article on Paul Vick's blog (not exactly new, but it was to me): VB Runtime agility, Orcas and new platforms.

Touring

Someone asked the creator's club a question about writing a Mille Bornes game. I remember liking that game as a kid, but the first version of it I played was the older more simplistic game of Touring.

I've been thinking of putting together a simple game to test the XNAMachine engine with, something a little more simple than Star Maze just to see what it's like to build something with it, and this seemed like the perfect thing. So rather than completely rip off that guy's idea of making Mille Bornes, I've been putting together a Touring card game (ok, so I'm mostly ripping off his idea...)

Making a 1-player Touring game would be a little "too easy" I think, so I'm building both server & client programs to allow for multi-player sessions of Touring to be started by whomever wants to play. If the engine proves to be a decent performer for this application I'll begin the process of "porting" what's completed of my Star Maze project over to the XNAMachine engine.

At this point I've got most of the object structure done for Touring, the game logic is easy, and so now I'm writing the network code for the server. There are no movement predictions or tight synchronizations to worry about here, the server & client really just need to relay simple commands & acknowledgments back & forth so it's a really good starting place for network code I think.

At the risk of enduring a copyright violation lecture I've obtained some rather pristine editions of old Touring games from eBay as texture sources, and I've been browsing around a neat little website called soundsnap, which has a lot of nice free sounds & music loops.

This is something of an unexpected diversion but I guess that's typical; the hardest part about programming is finishing something, right? No worries...

Vacation 2

I'm in Japan this week. I don't speak or read Japanese so sometimes it feels a little crazy, but at least we haven't gotten lost yet. The train system here was a challenge at first (especially to a foreigner from a small US town without any serious public transport in the first place). But a lot of things are in English of course so it's not so bad. Today we're in Kawaguchi which is a small country town just north of Mt. Fuji. Just hanging out here, it's like a mountain resort type of place.

I wanted to get some good work done on the XNAMachine engine on the 11 hour flight, but after a couple hours I realized I didn't have the right power adapter for the plane's weird DC plug.

The XNAMachine

I'm continuing to plug away at my new engine here and there, mainly by jotting ideas down into classes & interfaces, and then shaping them into workable objects. It's kind of like throwing lumps of clay down into the IDE & then shaping them into recognizable things. It's probably the world's most inefficient way to design something but I'm having fun with it.

The XNAMachine (my obvious name for this new engine) has grown into 5 primary categories which I've split into as many Namespaces within the project. The primary namespaces are, in no particular order

• Core - this contains classes such as the base Game class, the VBContentManager, a static math helper class, all the primary singleton stuff


• Objects - the base game object is defined in here along with a base game component for including objects in the XNA Game's components collection. Future items in here will be other common bases; screen, camera, and some sort of base spacial partitioning class either a grid or a quadtree or both


• Augments - a base class + various primitive implementations of game object expansion pieces


• Automations - this is the bit I've been working on the past couple of days, it's a system of rudimentary classes that primarily hold information which can be used to modify various properties of augments. Automations are intended to be Augments, but it's such a big category of "stuff" that it got it's own namespace. An example of an Automation Augment would be, for example, if you have a Transformation augment attached to a game object, the game object gains the ability to be transformed by a matrix. You can then attach an automation augment to that game object, specify which element of the transformation object you want the automate, and this will allow for "scripting" various activities over pre-defined times & destinations. I have a system like this now, it's just not nearly half as elegant as this revision will hopefully be


• Augment Update Services - the way I'm experimenting/planning to update augments is to create a collection of service implementations that perform various tasks, each built to accept a single augment at a time. Every single augment will have a reference to the service it uses to update itself, so when an augment wants to update, it simply passes itself in to it's service reference.

So that's kind of the gist of it so far, and I'm getting reasonably close to finishing up the classes in the Automation Namespace, but my wife is hardcore giving me the stink-eye so I better turn my laptop off before I get busted.

Composition

Well I've been bitten by the Composition bug. In a big way. So to satiate my newfound curiosity, I must confess I've been spending time on an experimental clone of my 2D engine using a technique of dynamic Composition.

The Composition version of the engine is based around a single "Game Object" class. This class is effectively nothing more than a collection of IAugmentation interfaces.

In my existing engine, the Sprite class has become quite large; what's more, not all Sprites always utilize every member and feature of the class. By partitioning this class into several different stand-alone "mini-classes" (all of which implement the IAugmentation interface), these mini-classes become "Augmentations". From this, one can start with an empty game object and build it into anything by adding the appropriate behavioral and/or data Augmentations to it's IAugmentation collection.

What's seductive about the Composition model is that this building process is not significantly different between design time and run time. To me this is the primary advantage of using Composition over Inheritance, which AFAIK is largely static at run time. I.e., once you define your class that inherits from <whatever>, you're stuck with that at run time. With Composition, you could simply remove one Augment and add another.

My only concern with what I've developed so far is that dictionary lookups are becoming somewhat frequent - i.e., I find myself querying whether or not a game object has been augmented with <augmentX>, and if so, retrieving that augment for use. These queries don't exist so much in the Inheritance model, and this aspect may require some fine-tuning as things get progressively more complex. But, we shall see.

Fun stuff!