During development, generally your testers will be running a version of the game that could be a number of days old.

By the time you’ve got back bug reports there is likely to have been significant progress on the game since. There’s every chance during interim development that bugs could have been fixed before QA found them. Also, the goalposts could be moved; some aspect of the title may have been significantly changed and that bug report you got no longer makes any sense.

For these reasons it’s imperative that when you get back bugs, you know what version of the game they were running. There’s a number of ways you can address this:

Version Numbering

• Can be in various forms. Could possibly be a hard coded string, some piece of built data, or the version number built into a PC executable header.
• Many PC applications shipped just use simple version numbering to denote their builds. You still see a lot of “beta version 2.0.1.1123″ style versioning on commercial software sitting out on webpages.
• Manually updating the minor revisions each time is an easy thing to forget. It is possible to set up most development environments to auto-increment this number. If there’s no native support, it can usually be hacked in as a pre-build step.

Source Control Revision

• There’s dozens of different pieces of source control software. With the majority of them it’s possible to synchronize to an explicit revision of the source tree. The revision number a game was built from can be used to identify a build.
• As a pre-build step it is possible to automatically embed this revision number into the game.
• Some source control software doesn’t have any sort of global revision numbering. Visual Sourcesafe springs to mind; that one only logs revision histories on a per-file basis. A single revision number to identify a particular build of the game is not possible. For Sourcesafe though it is possible to apply a label to the whole source tree. That could be done with each significant test build, with a version number of some kind.

Date/Time Stamping

• Simply the date and time at which the build was created. Similarly to the source control methods, you can easily pinpoint exactly what code and data made it into the particular build of the game.
• It falls down a little if your source control still accepts submissions, and you have other users submitting code whilst a build is being created. When cross referencing the date and time you actually built the game, it could appear that some changes got in that actually didn’t. This is no big deal if you lock out your source control whilst making a build for testing, or if you only have one person on the project.
• Don’t use the timestamp of the executable itself! Aside from easily being able to be overwritten (the create and modified dates could be blitzed over for example, with particular unzipping or CD burning software). On the Xbox with XNA it’s not actually possible to inspect the executable’s date using the System.IO calls.
• It is generally possible in most development environments to embed the current date and time into code. In C# this is actually possible in a very nice, clean manner. Updated intelligently each time you build an executable.

With your average XNA game you’ve got no QA department to rely on. Most testing would probably be done by the developers, and their friends and family. The easier and more transparent this identification-marking is, the better.

Automatic versioning in C#

C# does provide automatic versioning in the form of an implicit change to the assembly version. For a newly created XNA project you’ll have an ‘Assembly.cs’ file. At the bottom is the version number:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
[assembly: AssemblyVersion("1.0.0.0")]

If you change the line to the following instead:

[assembly: AssemblyVersion("1.0.*")]

The last two numbers in the version will now be automatically filled in when the assembly is compiled. The numbers it fills in with are based on the current system date and time. So by doing this you’re effectively able to timestamp the built date of your game into the version number of the assembly. Both PC and Xbox are able to grab this version number, so it can be displayed within the game or on any sort of ‘game has crashed’ screen you have.

The first two numbers, the major and minor version can still be used for their usual purpose. If you’re so inclined.

The ‘build number’ and ‘revision’ portions of the version can be grabbed and converted to a C# DateTime class, with the following code:

private DateTime DateCompiled()
{
    // The assembly version must have the last two numbers removed and replaced with *
    // It should look something like this: 
    // [assembly: AssemblyVersion("1.0.*")]
 
    //Build dates start from 01/01/2000
    System.DateTime result = DateTime.Parse("1/1/2000");
 
    //Retrieve the version information from the assembly from which this code is being executed
    System.Version version = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
 
    //Add the number of days (build)
    result = result.AddDays(version.Build);
 
    //Add the number of seconds since midnight (revision) multiplied by 2
    result = result.AddSeconds(version.Revision * 2);
 
    //If we're currently in daylight saving time add an extra hour
    if (TimeZone.IsDaylightSavingTime(System.DateTime.Now, 
        TimeZone.CurrentTimeZone.GetDaylightChanges(System.DateTime.Now.Year))) 
    { 
        result = result.AddHours(1); 
    }
 
    return result;
}

Courtesy of this post from dotnetfreak.co.uk of equivalent VB.NET code.

So, this is what I’m going with to tag my game builds. It covers me for what I need, and requires zero maintenance.

Note:

It is mentioned on a number of webpages that the ‘build number’ and ‘revision’ numbers don’t update on each build. It’s said that they only update each time you actually start the Visual Studio application.

However, I haven’t found this to be the case with Visual Studio 2008. Both the PC and Xbox XNA projects update this just fine. I can edit any .cs file in my project, and the game gets a new timestamp. I believe that the posts about the bad behavior were with Visual Studio 2005 and 2003.

XNA content pipeline files though, do not affect the timestamp at all. This makes total sense though, as the binary xnb data files aren’t part of the actual executable assembly.

References:

• http://dotnetfreak.co.uk/blog/archive/2004/07/08/determining-the-build-date-of-an-assembly.aspx
• http://stackoverflow.com/questions/324245/aspnet-show-application-build-dateinfo-at-the-bottom-of-the-screen
• http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.assemblyversionattribute.aspx

So, I alluded to the fact I wanted to begin writing about XNA in my last post. Over the Christmas break I began getting to grips with C# and XNA, and wrote some code to have a go at prototyping a game idea I had. I think it’s pretty cool that you can execute your code on a retail 360 as well. It’s not quite as nice as using a devkit with native code, but it’s pretty close.

Note to Microsoft: Make it easier to launch the XNA connect app from the dashboard. I know it’s not meant to crash, and it doesn’t that often. But I’ve been attempting some dodgy things and I’ve had it fall over several times. It would be great if it appeared at the top of your ‘Game Library’, as the XNA apps themselves do. For the connect app I have to always scroll to the ‘community games’ section and pick it from there.

Environment

Anyway, I thought the best place to start would be to describe the environment I’m working with:

• I’m targeting both 360 and PC for the moment, but there’s every chance I might drop one platform in the future. I have no plans to write anything for the Zune.
• I’ve setup two extra build configurations in addition to the existing ‘debug’ and ‘release’. One named ‘final’, which would be the intended executable for the final version of the game to be dished out to the public. ‘release’ is the configuration which would have optimizations enabled, but would still have debugging ability through assertions. The second new configuration is ‘profile’, which is the same as ‘final’ for all intents and purposes, but compiles in profiling code. I wrote my own basic profiler, as I had nothing but trouble with nprof on PC.
• I have the code in two portions: I have a library in which I put what I’d deem as my ‘engine’ code, the stuff in there is (relatively-speaking) clean and what I’d want to keep if I scrapped a game idea and went with something else. The other portion is the game-side code, here I’m less fussy about organization whilst I’m just prototyping some ideas. Any code samples I put on this site though will be in a simple form which just an executable target, no libraries.
• The code I do post will be namespaced ‘Cute’. Why? Well, I’m focusing on doing a graphically primitive cutesy style game, with bright colors and simple geo. I’m no artist. Rather than come up with some other namespace for code I put here, I’ll just post the one I use.

Build Configurations

So, on to the build configurations. Here’s an explanation of each, and the extra compilation symbols I define:

Debug: Code optimization is turned off, TRACE and DEBUG are defined. The same as a new project in devstudio would be for it’s debug configuration. I also define the symbols ASSERT and PROFILE for this build. This would be the build I’d drop down to diagnose any problems that were tricky on a release build, due to the code optimizations.

Release: The same as debug, except with code optimizations turned on, and DEBUG/TRACE not being defined. This is generally the build I work with most. It runs at a good frame rate, I have assertions and profiling. As mentioned I’d only drop down to the debug build to work more accurately with the debugger.

Final: This is the ’shipping’ build. Compared to release, the ASSERT and PROFILE defines are removed. Essentially all development ‘fluff’ is out the window; the executable is expected to behave perfectly. The frame rate should also be somewhat better than release too because of this.

I define a FINAL symbol here as well, in case I want to conditionally compile in or out pieces of code specifically for this build.

Profile: For this build I use the same setup as final, but with the PROFILE define enabled. I lose the overhead of assert checking from the release build, so have pretty similar performance to my final build. However my profiler is usable, so this build is perfect for testing any optimizations I might perform on the game.

I’ve shoved some screenshots at the bottom of this post, for clarity too.

Defined Symbols, Debug Output on 360

ASSERT and PROFILE defines? I’ll post in future covering how I use those. It’s pretty straightforward what they do when turned on and off though.

I define the symbols just a tad differently on 360 though. The Xbox 360 only has working debug output with the TRACE or DEBUG defines turned on. Here’s a table showing the debug output functions that are available, and how they behave on the two platforms:

PC

360

So, the defines differ on my 360 build. I have TRACE enabled on my release and profile builds, so I can get output. My profiler though I hope to eventually get to render to the screen, instead of just dumping captured data in text form. So I may be able to disable TRACE on my 360 profile build at some point in future.

On PC I route my printouts through System.Console.Write, on XBOX through System.Diagnostics. Trace.Write. I have a locally namespaced function that behaves correctly for both platforms. Yes, I could just have TRACE defined on the appropriate builds for parity… But I just don’t trust that it has zero other detrimental effects on performance.

Phew…

That’s it for the moment. Dry preparation is out of the way, this is more of a primer than anything. Something I can link back to in future to explain my #ifdef madness. Somewhat more useful stuff to come next…

Oh, here’s those configuration screenshots I mentioned:

PC: Debug, release, final, profile.

360: Debug, release, final, profile.

That said, I’ve started to code a little in my free time. I got a block of time over the Christmas break and I decided to have a good go at doing some stuff with XNA and C#. Was a good experience, I feel a lot more comfortable with C# now. I’ve learnt to live with some of the annoying differences between it and C++. I code in the latter every day for my day job; for another language that’s so close to it, it takes a bit of a leap to leave the old ways behind.

So, hopefully I’ll give this blog a bit of a new lease of life soon with some tidbits from my XNA adventures. I’ve got a couple of ‘in-progress’ articles going already.

Anyway, Metallica…

The last time there was rumblings of a Metallica game was back in 2003:
http://cube.ign.com/articles/422/422960p1.html

… and I would know nothing about such a game at all of course… *whistles*

Damage Inc. [Metallica car combat title] (PC/PS2/GC/XBOX, Climax/VU Games)*

http://www.destructoid.com/surfer-girl-is-back-with-a-cancelled-game-list-50625.phtml
Seems like a very long time ago now… I’d like to say more about it, but it’s probably not a good idea.

Like Aerosmith last year, my involvement is pretty minimal; I’m working on something else right now. The Metallica game is based on the World Tour engine, so all four instruments are playable. Unlike with the Aerosmith game, where you were limited to just guitar and bass.

As per usual, with the press-situation for these sorts of things I really can’t say anything in more detail. It looks fantastic and I think the fans are going to be dead impressed with it.

I learned how to code on the Amstrad CPC 464. Used to be mad for the system when growing up, read and re-read magazines, and spent hours playing a lot of very bad games. Plus a few good ones, mind. I think I only stopped using it in 1994, when we got our first PC.

Fast forward fourteen years, and things are very different. Whilst I used the CPC well past it’s best (commercial software dried up in 1991), since then it’s only had a passing interest. Cool stuff going on with it on the internet like SymbOS, CPCZone and CPCWiki kind of passed me by.

It was a couple of months ago that my interest picked up again. I was showing a colleague the CPC3D emulator I wrote a few years ago, on one slow night whilst we were waiting for a build to be approved. I then spent a little while seeing what’s going on with the CPC. SymbOS I first read up about a couple of years ago, a very impressive coding feat. CPCZone is kind of interesting, mainly just nostalgic reminiscing about the old machine. What sucked me in though was EBay.

I remember in the early 90’s when the 8-bits were coming to the end of their life, you had labels like Codemasters releasing budget games. For usually two or three pounds each. A godsend when you’re on pocket money. Many of them were very good games too. By this stage of the machine’s life though older software from around launch time was hard to come by. The machine was initially released near the end of 1984, with a bunch of software from Amstrad’s own publishing label: Amsoft. The internet consensus is that some of the worst games were released on this label, but I beg to differ. Many of the ones I had were real enjoyable, fun games to play.

Having old magazines listing the Amsoft games, I’d always wanted to get a few more, ones I’d liked the sound of. “Oh Mummy” was one that I’d always wanted. I first got to play that game on an emulator, in the late 90’s. No store near me whilst growing up stocked the old Amsoft titles. Once I remember there was a place that sold the disc versions of them, but at a ridiculously high price. But that was it.

Disc version? Yes, the vast majority of stuff I had wasn’t on disc. It was on cassette tape. Games took ten to twenty minutes to load, and you had to endure the modem-like screeching noise of the data being read from tape. Yes, I’m that old. Retelling this to some of my younger colleagues here, I felt positively ancient. Reminded me of teachers at University letting us know about the early days of programming with punch-cards. Ghetto stuff.

So yeah, after seeing some cheap Amsoft games on ebay I thought I’d like to try buying a few. From the image in this post, you can see though that the high-end price is a little ridiculous. Remember, this is for a cassette tape! I bought a number over the past few weeks, ranging from a few pennies each up to I think maybe $20 (USD) for the most expensive one. They have pride of place in my little bookshelf at home now, quite unique items to have in the United States. The CPC was never released out here.

By the way, the $67 game is ‘Roland Goes Square Bashing’. It’s actually one I wanted to purchase, but I really couldn’t justify spending that on a cassette tape that would sit on a shelf.

So, updating this site hasn’t gone entirely to plan. Fortunately though my workload has eased up a little now, there’s a number of things I wanted to write about so hopefully I’ll get the chance now.

Speaking of workload, the last ten months or so I’ve spent working on the now announced: Guitar Hero World Tour. It’s the first Guitar Hero game I’ve been involved with properly, having previously worked on the ‘Tony Hawk’ series at the same studio. I’m really proud of what we’ve done with the new game, and I’m sure everyone’s going to enjoy it when it gets released. Really hoping we can get into that 90-100 range on Metacritic, it deserves to.

It’s a double-edged sword working on something so popular. On one hand it’s nice to read the buzz about your game on the internet, people looking forward to new tracks being announced, and seeing how much some people can’t wait for it’s release. On the other hand, there’s the ‘fanboys’. I probably shouldn’t go into it too much, but our game tends to get a bit of rough treatment by commenters on various game websites. Our competition, Harmonix makes great games and has a very loyal following.  Some people have invested heavily into their product, both finanically and emotionally. It’s a shame this clouds objectivity of what we’re offering at times.

It’s widely publicized that our guys at Neversoft used to play the first two Harmonix-developed Guitar Hero games at company parties. In fact I think one of the first times I had beers with the guys I work with now, was over a game of Guitar Hero in our warehouse. We have massive respect for what those guys did with those games, they’re a quality developer. The first game prompted me to get my first console since emigrating to the US (I left my old ones back in England). I remember lugging that PS2 and the guitar bundle a few blocks back to my apartment from the local Best Buy, in the days before I got a car.

Most of my game playing time in this country has been on Guitar Hero. I’d played a decent amount of Tony Hawk before working on those games, but only casually on a couple of games in that series. GH though is a totally different story, one of my favourite games of all time for sure. I remember excitedly bringing my PS2 and the game in my luggage to Simon’s place in Colorado, for his birthday weekend in 2006. Went down a storm. I’d never have thought in a million years that I’d end up working on it.

Dream come true.

Recently there has been news of that great game ‘Dead Rising’ getting a sequel. It was a big success for Capcom, and I guess came as no surprise that it was coming.

However, the big thing that has generated a talking point is that it’s going to be done by a Western developer. Now, as I work for one of those myself; I shouldn’t be slinging mud. But I’m really a bit concerned that this game can go down some bad avenues.

Here’s what I fear:

• Game starts development. Team are giddy, they come up with some great ideas. This is good, very good.
• A lot of stuff sounds great, code are on the new mechanics, and the concept art is looking superb.
• Player in the game, zombies in the game. Game chugs a bit, but that’s okay as we’re just starting out.
• Milestone one, a first playable of sorts approaches, all hands on deck!
• Game gets a bit of polish, environments look nicer, characters look great.
• It’s dropping frames though, lets only have a dozen zombies spawned at once. Just for the milestone.(TM)
• Man, those zombies look good. Engine coders and artists given lots of praise. Milestone passes fine.
• Design folk are a bit bewildered, and finding it difficult to put in new mechanics with the sparse zombie layout.
• Art plays with fancy new HDR rendering and of course, bloom. It looks great on the HDTV in the conference room!
• People high up decide that as it’s an Xbox game, so it’s for hardcore gamers only. None of this primary colours shit, we want it gritty! Game becomes grey and brownfest.
• Design are still wondering why there’s only eight zombies shown at a time.
• Ship date is a few months away. Design accept that we’re not going to have as many zombies as the first one. No aggressive LODding either like the first one, the pop-in when you walked into shops was awful! We can use the memory we save on the zombie instances and textures on the environment!
• Screenshots are released, and gameplay video. Youngsters on the internet love how great it looks.
• Everything continues along same vein.
• Game ships. Gavin buys the game and is disappointed that yet again tech wins out over gameplay.

Now, this isn’t actually how it’s gone on any game I’ve worked on, despite the ranty sound of it! There’s always been strong people around to reign in this sort of thing to a sensible level. There’s no reason that the new developer may go down the route I detailed, it’s just that I think it’s real easy to lose sight of what Dead Rising was all about:

Lots and lots of zombies.

If you take that away, you’ve got a shell of a game. The tech of the game has to revolve around aggressive LOD-ing, that’s the focus. I just hope your code team consists of some seasoned PS1/2 era guys, and certainly not more than one or two fresh from University. Put the ShaderX7 book down, and back away slowly.

It’s okay that the zombie in the distance, twenty pixels tall, looks shit. It’s okay that the contents of any stores or buildings pop in a bit if you’re running fast. You don’t need to fix these things. What isn’t okay is dropping the sense of humour; and please for the love of God, don’t make it gangsta!

Guys… Make the game fun, that’s all. Just make it fun, and I’ll love you for it; and everyone will think that you rock.

I’ve never heard of Crave, nor that they ever published my game. A bit of googling later, and indeed it looks like they paid $120k for rights to the game. I’m not sure what to make of Crave, with such titles as The Bible Game under their belt, I’m dubious as to whether they can be considered a quality publisher.

It looks like they only ever re-released it on Gamecube, I can’t find any for the Xbox or PS2. The copy I ended up purchasing from eBay was the Crave one, for $10. I’ll be curious to see what the manual looks like. But I guess until I get a Wii (again), I won’t know what the actual game differences are, if any… There was a bunch of movies and legal screens which had Acclaim logos in. But I’d be really surprised though if they managed to get hold of the old code and data and replace that stuff.

One thing is for sure, I didn’t see a penny of royalties!

Finally, it’s officially announced.

I didn’t really get any sort of hand in Guitar Hero III. Probably a few lines of shared engine code, and the odd bugfix shared from a game I was working on at the time: Tony Hawk’s Proving Ground.

The Aerosmith game though, I’ve done a little bit of work on. So even though like GH3, I’ll be appearing in the credits… This time I can actually feel like I deserve a mention.

It’s nice to be able to talk about this game a bit now. We had the band at our building a few times late last year. It was real cool to be able to hear them doing their mocap (they played the music when doing the capture), whilst making myself a cuppa during the day. Nothing quite beats hearing Aerosmith tracks played live whilst drinking some Tetley. Tyler even paged the entire company when he saw the game in person, to tell us what a good job we’ve been doing. Top guy!

Game does indeed look very good. But obviously I can’t really say any more than that.