So I set off with my Zune attempting such a feat. After a few hours and some fun little tricks, I was able to ping-pong between a bootstrapper application (no XNA used), a game launcher application (XNA GUI interface), and any number of Zune games I wanted. What this means is that I can create a single game package for the Zune that includes any number of games and the user never has to actually reboot the Zune.

However this post isn’t really about the Zune at all. That was just the first platform I tried it on. My thoughts extend beyond this, though. What about multi-game packs for Xbox 360? You could argue, “But Nick, you can just make each ‘game’ a piece of one big game and not deal with all this rigamarole!” and to that I say “Sure, you could.” However my argument is this: What if you (and others) create a bunch of standalone games for the Xbox 360 and release them. Now it’s the future and let’s say you want to bundle them all up and release it as a single pack. To meet the “one big game” criteria, you have some decent work tying it all together and making sure it all plays nice. What I’m proposing, though, would allow you to just input the previously built games, build the launcher UI, and you’re done. No source changes required for the original games

Of course I still have to test on the Xbox 360, but if it worked on the Zune (which runs a similar version of the .NET CF) I have to assume it would also work on the Xbox 360. I might give a prototype a try and see how it goes. Make a pack of mini games and submit it to the XNA Community Games beta or something. Who knows. I just found it to be an interesting idea that actually is possible. What to do with it, if anything, is a whole new discussion.

Anyway, I whipped up a couple of little creatures and figured why not share them with the world? They’re nothing all that special, but I think they’re each cool. So here are those magical PNG files you can just drag into the game to import them. I would love to see a read up from the developers on who thought of that and exactly how it all works.

Seems interesting. It was only granted recently (June 3, 2008) but I wonder how long it will stick. Afterall, if the company doesn’t enforce their trademark against the literal dozens of games online using “Tower Defense” in the name, can the trademark actually be upheld? I’m no lawyer but I remember being told that the key with trademarks is that if you don’t enforce them, you lose them. Seems that this companyhas some work to do if that is the case.

Now back to random searching.

Edit: It also appears that Valve owns the patent for generating virtual eyes.

It’s great to finally have an answer, even if it’s that the Zune is being limited to save battery power. While great for the general Zune media functionality, it’d be nice for games to have more power. So in the usual rally of “customers drive software”, I’ve created a Connect suggestion that games should be able to request that these features be turned off so as to gain those clock cycles and faster refresh rate. You can go ahead and see there here: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=352193&SiteID=226.

If you want to make Zune games and want to see this get changed, please register at that site and vote on the issue to let Microsoft know that this is important to us, especially the developers looking to start making more and more advanced games for the Zune where every cycle is valuable.

It’s really nice :). HyperCam is still far superior for tutorials and things because it’s more lightweight making it better for long videos. Not to mention FRAPS only works for games. But if you need to record some gameplay, better believe that FRAPS is a great way to capture your video and audio.

I then usually will take that output (a rather large AVI file) into VirtualDub with the Xvid Codec and shrink it down. Usually it turns a 500+MB video into a 20MB video. It’s that good.

1)  Write the entire game like normal. I created a single Windows game project and made the whole game. Then I used the “Create copy of project for Zune” option and made the Zune version.

2) Build the game and extract the compiled content. Basically just build your game like normal and go into the bin/Zune/Release directory and find all the content. Take that stuff out and place it somewhere else. We’ll need that in a minute.

3) Create a second project in Visual Studio (either in the same solution or a new one). This should be a Zune Game Library project. Place all of your game’s code except for Program.cs into this new project.

4) Create a new Resources file for your library project. Right click on your game project in Visual Studio and go to Properties. Click the Resources tab. Then click the text in the pane to create a new resources file. Now drag in all the built content you had create earlier into this.

5) Go into your game class and create a new ResourceContentManager.You pass in the Game.Services collection for the first argument and then your library’s resource manager next. Then we can use some reflection to assign our new ContentManager as the game’s content manager (since the Game.Contnet property is get-only). Assuming your library project’s name is ZuneLibrary1 then that code looks like this:

public Game1
{
    //all that other constructor stuff

    ResourceContentManager content = new ResourceContentManager(
             Services,
             ZuneLibrary1.Properties.ResourceManager);

    FieldInfo contentField = typeof(Game).GetField(
             "content",
             BindingFlags.NonPublic | BindingFlags.Instance);
    contentField.SetValue(this, content);
}

The reason we want to set the content field to our new instance is so that every place we use the Game.Content property will now use our ResourceContentManager instead.

6) Next make sure all of your load methods take into account that the directory structure has potentially changed. For instance I put all of my files into the resources file without subdirectories so I had to remove those in my code.

7) Now build this project and get the DLL file it makes. This DLL now contains (internally) all of the XNB content files and classes for your game.

8 ) Place this DLL in your game project’s folder and add it as a reference to your game project in Visual Studio. Now your game should compile and run just like normal, but now all of your source code and assets are hidden.

Of course, as with anything, there is a downside. If you read this post by Shawn Hargreaves (of the XNA team) you’ll find there is a significant downside to this for some games:

There is one major downside to embedding content as assembly resources, however. The entire assembly (including resource data) will be loaded into memory in one go, and the CLR does not provide any way to unload assemblies other than by unloading the entire AppDomain.

What this means for Zune game development is that if your entire game (code and assets) is less than 16MB, this is fine. If, on the other hand, you need to be able to dynamically load and unload assets to stay in this limit, this solution won’t work for you. But for small Zune games, most people will be fine staying under 16MB I would imagine.

There you go all you closed-source people. Hopefully this helps you all out. Now go forth and make some cool Zune games!

Donations

Help support this site and future Zune game development by considering a small donation:

(click app to give focus, use arrow keys to fly around)

Pretty fun stuff so far.