Pandemonium

November 12, 2008

Easy Upgrade

Filed under: XNA — bittermanandy @ 10:08 pm

I was planning to spend the next couple of nights upgrading my Kensei engine and Pandemonium game to XNA 3.0, and making notes of the problems I encountered, so that I may write an article explaining how I overcame them and others may more easily overcome the same problems if they encounter them too.

Unfortunately, I can’t do that – because if I did, the article would consist of the following: “It just worked”.

Yes, it really was as easy as loading up VS 2008 and loading my existing solutions into it. It took a few minutes, to be sure, but I only had to press OK a few times and everything worked. It was so easy that I didn’t believe it at first – I did a batch build of all projects, then a batch rebuild of all projects, then double checked all the references to ensure it really was using XNA 3.0 and hadn’t just pretended to upgrade from 2.0. But it was true – the upgrade really did take zero effort.

So I thought I’d kick things up a notch – bam! – and investigate what Microsoft had seen fit to provide us with in an area that was sorely lacking in 2.0: installation and distribution of my game on Windows. Please understand that this is only a preliminary look at what’s offered, and I might easily have missed some subtleties. Basically you’ve got three choices:

Package as CCGame: this particular option seems to be quietly glossed over in the docs so I suspect it’s just a hangover from XNA 2.0. It’s got the same old drawbacks, in that the recipient has to have the XNA redistributable already installed, and it doesn’t offer any choice of installation location or creating shortcuts on the desktop or Start menu. However, on the plus side, the final output is a single compressed file. It’s much easier to give someone one file than several files and folders.

Setup Project: assuming you have VS 2008 Professional or higher, you can now create a VS setup project that creates an MSI file. (Instructions are also provided to use a third party installer such as Wise, should you so desire). This would also create a single file, as well as giving total control over installation folders, shortcuts, the ability to show licensing agreements; but the downside is that it doesn’t automatically recognise content project files as dependencies, which would need to be added individually. There could be thousands of these in a typical game. Not going to happen. You’ll drive yourself mad trying to keep it in synch with your game. Personally I’ll be avoiding this option like the plague.

ClickOnce: obviously the favoured choice at Microsoft, it’s got a lot of good things going for it. You can set version numbers (and make them update automatically), it installs the .NET and XNA prerequisites for you, you can massage which files get included and define download locations or whether to autorun the CD you burn it onto… brilliant. Plus you get all the expected shortcuts in the Start menu (but not the Vista Games folder, oddly). The downside? The final output isn’t a single file! It’s an exe, and a manifest, and a folder containing all your game files with the extensions changed to .deploy. I don’t really get what that’s supposed to save you. Sure, you can zip it up – but then your user has to open a zip file and run the right exe. You could just as easily zip your game from the bin folder and tell them to run the XNA installer separately, you’ve not saved anything.

Overall these options are a big leap forward from XNA 2.0 but I still wish they’d taken just one more step and either made ClickOnce create just one file, or made the Setup Project more intelligent. At least now there’s a better-than-evens chance that whoever you give your game to will be able to install and play it first time, but it’s still not quite as simple as it could be. It’s possible that I’m missing something, but where the upgrade from 2.0 to 3.0 was a perfectly smooth 10/10 experience, I’d still have to give the Windows distributable options no more than 8/10.

One thing I do like isn’t strictly an XNA feature at all, but C# 2008. Select View -> Code Definition Window, and every time you select a symbol in your code (class, function, namespace, enum…) the window will update to show you the code definition of that symbol. It’s priceless and I officially love it. I’m looking forward to using all the other new features of the IDE and the language.

(Though bizarrely, the Open Containing Folder feature on the active item tab only worked the first time I used it, and never since. If anyone can tell me why I’d be very grateful as I’d use that all the time).

Advertisements

10 Comments »

  1. Good call on the Code Definition Window. I’ve just tried it out based on your suggestion, it it looks useful. As for the Open Containing Folder feature, I’m afraid all I can say is ‘works on my machine’.

    Comment by JB — November 13, 2008 @ 11:54 am | Reply

  2. Hey Andy, it looks like there’s something wrong with your RSS feeds?

    Comment by Shawn Hargreaves — November 13, 2008 @ 5:53 pm | Reply

  3. Odd. Looks OK to me. Anyone else having problems? In Outlook, another reader, etc?

    Comment by bittermanandy — November 13, 2008 @ 7:23 pm | Reply

  4. Nope, fine on FeedReader 3.13

    Comment by Charles Humphrey — November 14, 2008 @ 10:29 am | Reply

  5. I would imagine that ClickOnce would work perfectly for a CD distribution, like you said. If you’re looking for a single file distribution, could you just use NSIS or something similar? I know it would be nice to have a one-stop shop for installation, but something like ClickOnce is definitely easier than previous installation methods.

    Comment by Otto Borchert — November 14, 2008 @ 7:56 pm | Reply

  6. Not heard of NSIS but I’m guessing it’s much the same as Wise installer or similar? Instructions are provided for an MSI project “…or third party solution”, so I’d imagine that you could, yes. Basically the docs list what registry settings to check for to detect whether XNA 3.0 is installed and if not, what to do about it; that handles the prerequisites side of things, and you’d then include the required files exactly as normal.

    The downside for that as I mentioned for an MSI project is that you have to identify and list all the content files (non-assembly) yourself individually, as opposed to ClickOnce which determines them automatically. And that would be a royal pain on all but the most trivial of games.

    Comment by bittermanandy — November 14, 2008 @ 8:33 pm | Reply

  7. Hi Andy, glad to see you were so pleased with the upgrade experience… And now to explain a bit about ClickOnce!

    I think you are looking at ClickOnce from a very specific point of view, and from that point of view, you can’t understand some of its implementation. If you are distributing your game on a disk, then it hardly matters whether the disk has one file or ten thousand. Your complaint is that when you distribute your game some other way – then it is extremely cumbersome to have more than one file… But why are you publishing to disk if you want people to install from the web?

    ClickOnce provides the option of publishing to the web, which will deploy the application files to a web site of your choosing, and create a web page with a link – a link that will install your game with one click. By clicking the link, the ClickOnce engine will download and install only the application files that are required.

    The “required” part of that is important. There might be no obvious benefit for a first-time install, but it is extremely important for the ClickOnce update feature that you mentioned. When an update is made available, ClickOnce will download only the files that have changed from the installed version to the current version. If your game has 10,000 files, and you publish an update that fixes a bug in only one file, then ClickOnce will only download the one file!

    The thing to realize is that you have deployment options in ClickOnce. If you expect your users to deploy from a disk (CD/DVD/USB/whatever) then you should provide a file address when you publish, and you’ll need to distribute everything. If you want your users to install from a file share or from a web site, then provide a UNC path or URL when you publish, and then just send your users a link. The published setup.exe will perform the download as required and install only what is needed. VS 2008 has a “local IIS server” that will let you publish to a simulated web server on your local machine for testing.

    If you want to publish to disk and then distribute that as a file, I suggest using something like WinZip to create a self-extracting EXE. These have the option of automatically executing an EXE that it extracts, thus allowing your customers to completely install your ClickOnce application by running only one EXE.

    Comment by Stephen Styrchak — November 16, 2008 @ 7:06 pm | Reply

  8. Stephen – I understand what you’re saying and I did notice the other options for ClickOnce. Undoubtedly, they do each make sense in their particular intended realm.

    I just figured that a standalone, single-file, MSI-like executable is the most flexible and convenient way to distribute my game. I can then put it on a CD, or email it to a friend, or upload it to a website (of my choice and controlled by my standard access rights system), or chuck it on a USB stick and take it into work, etc. The other methods that ClickOnce supports might each be a little better for their intended purpose, but aren’t flexible enough to cover more than one usage scenario.

    Perhaps a self-extracting EXE is the best compromise. It’s just another step in the build process, which isn’t crippling but is a minor irritant.

    Comment by bittermanandy — November 17, 2008 @ 2:52 pm | Reply

  9. Code Definition Window is also in VS2005, very useful.

    Comment by Andrew — November 19, 2008 @ 1:50 pm | Reply

  10. (1) From what I have read elsewhere, and some of my own limited testing, creating a Clickonce distribution that will install straightforwardly on Vista lies somewhere between Difficult and Impossible.
    Much of the problem seems to relate to working around the UAC, but there are other issues as well.
    Does anyone know better / have a failsafe how-to procedure for making it work ?

    (2) The other issue I am up against is being able to tell a user ahead of time whether their graphics card supports the necessary Shader Model – which is at the very least 1.1 and probably 2.0.
    I could present the user with a long list of known graphics cards that don’t and ask them to check for themselves but this hardly seems like a good solution.
    However if I can’t find out programatically, the alternative is that the user goes through the trouble of installing .Net 3.5 SP1, XNA 3.0 redistributable, Windows installed 3.1 and finally my game, only to discover that their graphics card won’t support it.
    Anyone know how I can detect the graphics card capabilities from the browser, or failing that some pre-loader or something?
    That way I can warn users to turn back earlier or go buy a new graphics card – rather than getting a load of complaints in my inbox.

    THANK YOU!

    Comment by Andrew — March 3, 2009 @ 10:09 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: