An Idea of Game Packs

Posted in XNA, Zune on July 01, 2008 at 11:51pm.
There are no comments.

According to the Rules of XNA, you are only allowed to call the Run method of the Game class once. No matter how many Game objects you instantiate, you only can call Run once lest you get an InvalidOperationException. However the other day I began to wonder how one could work around this.

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.

Zune Performance

Posted in XNA, Zune on June 20, 2008 at 11:37am.
There are 6 comments.

Michael Klucher, a program manager on the XNA team, made a great blog post this morning about Zune performance in regards to the differences between the 30GB model (generation 1) and the 4/8/80GB models (generation 2).

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.

Releasing Zune Games Sans Source

Posted in XNA, Zune on June 19, 2008 at 1:54pm.
There are 3 comments.

As some of you may have noticed, my Repeater Zune game is completely devoid of any game source code or assets. The reason being that it was an experiment mostly. People are getting to a point where they have games they want to release, but don’t want others messing with or redistributing as their own. So I took some time the other day and figured out just how to do that. Here’s the high-level steps taken to produce Repeater.

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!

Repeater!

Posted in XNA, Zune on June 18, 2008 at 10:35pm.
There are no comments.

I’m proud to announce my third little Zune game: Repeater. Repeater is a basic electronic version of a classic pattern matching game. In this game you use the DPad to see how long you can last against a relentless AI determined to wear you out.

This is a simple game with no options and nothing fancy. But it’s definitely an enjoyable little experience. Grab the download here and let me know what you think: Repeater.zip.

---

Donations

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

RaycasterX Released

Posted in Dream Build Play, XNA, Zune on June 14, 2008 at 8:55pm.
There are no comments.

http://www.codeplex.com/raycasterx

RaycasterX is an MIT-licensed project geared towards the creation of a full raycasting engine for XNA. Currently RaycasterX is built against the XNA Game Studio 3.0 CTP providing support on both Windows and Zune. Xbox 360 support will be added when a version of XNA Game Studio 3.0 is released that supports Xbox 360 building and deployment.

RaycasterX is primarily based on the tutorials of Lode Vandevenne. Some changes and extensions have been added both for ease of use and the transition from C++ to C#.

This is the base engine I used for my ZuneShooter WIP. I have decided to stop working on that project for a couple reasons:
1) Performance on the Zune just couldn’t keep up with a fast-paced first person shooter, and I’m too pre-occupied with DreamBuildPlay to spend much time on it.
2) It really isn’t that fun. Controls on the Zune just aren’t fun for playing a first person shooter.

However if you disagree, here’s the full raycasting rendering code you need to start putting a shooter (or RPG or racing game or whatever) together. Have fun!

« Previous Entries