Greetings from the Future

Xerxes is one of the first playable characters to which you have access in Weapon of Choice. His Jet Engine gun is one of the most powerful weapons in the game and it gives you the ability to fly around in a jet-pack like fashion. His hovering spin double-jump lets you maneuver even further while in the air! Here's an image from the design specs for his weapon.

As it turns out Xerxes is based on a real person that just happens to live in the year 2188. Here's his new MySpace page. I'd like everyone to get to know him as he has some fascinating insights into the Earth's future. And please, show him some hospitality by adding him to your friends list.

Weapon of Choice launching on Community Games Beta

The game is about be released! That is, in a very limited fashion. I'm hard at work ironing out the bugs for a version to be published to Community Games beta. I've spent a surprising--annoying amount of time dealing with text and images that run off the sides of the screen with a standard-def TV. Early this coming week I plan to run the game on a HDTV. I hope there aren't any new text issues there too, but there probably will be. It will be good to see how the Peer Review process goes and to find what issues there may be. Also it will be nice to see what feedback we get from other developers.

In order to play games on the Community Games beta you have to sign up as a premium member. Only people that want to make games for Community Games should do that, though. Starting with the Holiday season of this year, the real non-beta version will launch and everyone that has an Xbox 360 and an internet connection will be able to play demos of Community Games and buy them. No special membership will be required! Microsoft says that Community Games will be available in a similar way that Live Arcade games are currently. You'll be able to browse a list of games and try them out as you please.

Currently there are over 70 games released to the CG beta 'games catalog'. I've tried a few so far. Swarm is a fun twist on Missile Command. Colosseum is very polished looking. Drop Engine is difficult but has lots of gravity gameplay in it. Spectrum is confusing in the same way that 'Double' mode in Raiden III can be. City Rain is more deep than most CG games, and has an entertaining environmental slant to it. ("Don't put a landfill near the river. You'll pollute the water supply!" Feels like something the a lame comic villain would do to Gotham city).

Monster Watch

With the arrival of the Chuul on Earth and the devastating processes they've initiated, alien mixtures of various origins have been encountered.
Here is the most recently observed case.

Bombing Mushroom
Dimensions
Approximately 1.5 to 2.5 meters tall, 1 meter wide. Spore over 3 meters tall.


Known Behavior
When agitated closes cap quickly and thrusts into sky. While floating to new location, large seed-like entity dropped to attack or block pursuers. Spore capable of lashing assault.

Saving and Marketing

While the conversion of the game to the 360 is 'over', along the way I tore up all kinds of things getting the game to work on the console. Among those was the ability to save and load game data. The game records data such as what level you've reached, what levels you've beaten, how many times you've taken a given path, what Operatives you've rescued, etc. Saving still worked fine on the PC, I just delayed making it work on the 360. Earlier this week, the time had come to fix it.

XNA made it fairly easy to save/load game data on the 360. Since I was already using a filestream on the PC, I was able to simply cut the saving and loading code out and place it in a separate function to run on the PC and Xbox. From there the PC and Xbox needed individual wrapper functions. The Xbox function was easy to setup using the StorageDevice. Before saving the first time the player has to choose a storage device (such as a hard drive or memory card). The snag I ran into was when I tried opening the Guide to have the player choose the device, it never showed up! It turns out help documentation in Visual Studio didn't mention that XNA auto-picks a device if you have only one, and never shows the Guide. I would have known this if I were using the msdn help because a user comment there explains this auto-picking behavior and links back to the XNA forums. That'll show me for thinking I can live without the internet!

Marketing for Weapon of Choice starts soon! While MBG has very little money for marketing we do have lots of moxie, and vim, and chutzpah and other descriptions that make it feel like we're working on a silent film instead of a video game. Those adjectives combined with elbow grease, knuckle cracking, and sweaty brows have created a really sweet trailer for the game! Sadly, not all the stars have aligned for it be uploaded yet, but that time will come very soon, along with several gorgeous screenshots and a snazzy new homepage. Yippee!

And just to spice up this entry a little and reward anyone that read to the end, I'll throw in this sketch of a very large creature in the game. He's all in pieces here, but through the magic of video games he'll come to life, right on your screen! Then he might crush you with his hooves.

Thuper threads and Lightened loads

I've tried four versions of threading at this point and finally have a noticeable speed up in the game. The original version was using the .NET threadpools. I've found out those weren't meant to be used in a situation that required high performance. Then I tried an implementation of my own design that resulted in a slower framerate. Then I got a little help from an old friend which resulted in a threading solution that worked, but the framerate stayed about the same.

The fourth and current version makes the game faster and is a combination of methods. When using XNA on the Xbox 360 you have access to four hardware threads (1, 3, 4, 5) and a one thread for the main game application (thread 0). With that in mind, my update threading uses four threads to update all game objects simultaneously. The new design gives each thread one quarter of the level objects in succession. That's important, because the longer each thread can run uninterrupted, the better.

Some profiling output for the 360 was set up using StopWatch. In addition, I have a boolean that can be toggled by a controller button combination. Without threading the update takes around 25ms. With the new threading the update is down to around 17ms. It's not an incredible gain, but it does make a significant impact on the framerate and the smoothness of the gameplay. While more framerate improvements are planned for the near future, the framerate for the game on the Xbox 360 is finally playable!

The other good news of the week was the load time improvement. Previously I had game objects, animation files, and gameplay data all in separate files per object. I've since consolidated them from over 1100 files down to 3 files. The load time on the Xbox 360 for a full level has gone from over 6 minutes down to around 30 seconds! I'd still like it a little faster, but at the moment it's a great change!

At this point I consider the 360 conversion finished! Cheers and tears! It's time to move back to working on the game itself!

Bad Threads and Good Shaders

In an effort to better use the Xbox 360 I've been looking into multi-threading the update loop in the game. After waffling between a custom managed thread system and the .NET ThreadPool, I settled on the ThreadPool. It seemed to make sense on the PC. I have it arranged basically as follows:

• The level allocates an array of 'ManualResetEvents' to signal when a thread is finished working.
• The max worker threads are set to 4 as per this article.
  
• The object list for the level is in a tree layout. Where a branch starts, a thread (provided it's ready) is set to updating that branch. ThreadPool.QueueUserWorkItem is used to start on the branch updating function.
  
• The Event array is checked until a new thread is ready. Previously on the PC I was able to use WaitAll and WaitAny but the 360 only supports WaitOne. It's uglier but it seems to work.
  

When I finally ported it to the 360, it turned out that the pool was allocating lots of various objects during runtime down inside the .NET functions. As we saw before this causes the 360 to collect garbage which slows everything down.

While exciting and promising, I've decided to set threading aside for a time and move forward elsewhere with the game. Hopefully some time in the future I can beneficially use threading.

The good news of the week is that I did get a decent framerate boost from switching to a custom shader! Shaders are code that run on individual pixels and vertices. I was previously using the provided BasicEffect shader to draw all my Quads (MBG's advanced sprites). I found this example and was able to spend some time hacking out pieces unneeded. After about a half a day I whittled the shader down to very little, since the game requires no special lighting methods.

The framerate for the PC version boosted around 15% and the 360 version increased about 10%! It was certainly worth the time and makes things look that much smoother.

The framerate adventure continues!

I'm happy to report the framerate for Weapon of Choice on the Xbox 360 is playable! It's still not 'great' but it is 'okay'. I know that's not the best report but when the framerate made the game unenjoyable just a week ago, I'm feeling pretty good about it. And on a decent computer, the framerate is smoking (often around 80 fps)!

There were a few changes that yielded some large improvements. The first was to 'batch' the processing of the vertices. All of the images of the trees, monsters, etc are created using two triangles stuck together (a 'quad'). While this is like sprites in most games, these quads are slightly more complicated. They are skinned to their vertices in a similar way to a full 3D model in other games; because of this I can't use the built-in SpriteBatch system in XNA. Before the optimization I was simply rendering each quad. With the batching, the quads with the same texture are grouped together in a bigger list. An interesting optimization point is that around 50 quads gives the best results, while a larger list of 200 quads was faster than no batching, but not as fast as 50 quads. There's probably a lot of reasons for this, but NProf suggests that it has to do with spending more time copying the larger vertex buffer needed in the 200 quad version. The framerate jumped to around 15% faster after the batching.

The second change that pushed the framerate even more was the use of DXT compression for the textures. In the Content Pipeline in XNA all textures have an option to use this compression. The interesting thing is the default is 'Color' not DXT (these are in the properties of the texture, under Content Processor, Texture format). I can't visibly tell a difference when using DXT compression, and the framerate increases by about 20% after this!

I found this entry in Shawn Hargreaves' blog very useful for GPU optimization.
The last change I made was to actually shrink the biggest textures used. At their biggest some textures were around 1000x1000. I've shrunk them down to more like 600x600. In my particular case I think it helped supplement the framerate with the previous changes in effect by reducing the texture fetching time.
Currently I'm running into CPU slowdown on the Xbox and am exploring custom shaders for faster drawing and multi-threading for the game object updates. Hopefully these get me the last boost for a great framerate on the Xbox!