Prototyping and Rough Design

With the DBP contest over it's time to get back to core development. That means finishing the game on time! There are a number of new levels blocked out and I've separated them into two groups. One group is to be finished by November 1st, the second group is additional levels to be finished mid-way through November. Why would we have two finish dates? Because unfortunately Microsoft hasn't released exactly when Xbox Live Community Games will be launched and we want to be ready for launch. From various internet rumors, it seems likely it will be some time in November, but we're not certain when.

Originally I was planning on the game releasing in December, but having the potential release date of the game pushed closer in time does wonders for figuring out design priorities. It was clear what levels we should include in order to finish by November 1st. Originally there were over 40 levels outlined (I was completely delusional at the time) and close to 60 monsters from small to gigantic. There will be more like 9-12 levels in the game, but these will definitely be the most action-packed and distinct levels from those originally envisioned.

Recently, I've somehow managed to convince Jack Mayer to help design some of the levels. Jack brings many years experience with him along with Xbox 1 development time! In order to make the most efficient use of two people (myself and Jack), we decided early on to rapidly prototype the enemies and the new levels. Jack is roughing in the level as I am prototyping the enemies. The rough art consists of building a skeleton for an enemy, and just using colored blocks on the bones. I do animate them but in a much less detailed manner. The programming for the enemy is created, but again not near to the same quality the final version will reach. The amount of polish for the prototype itself is a balancing act. The more polished you make it the more problems you may uncover early, but the more work it takes away from the final pass on the enemy or level.

Here's a test level with a prototyped enemy:
And for contrast here's a finished level with completed assets:


The benefit of all this early work is now the level designer can get the gameplay (enemies, hazards, vehicles) in place, more accurate, and more fun than without using prototypes and just jumping straight to polished assets. In addition we can find level art needs previously unknown, new enemy art needs, and generally new ideas can be figured out early on, rather than trying to shoehorn them into the finished assets. For the current level and enemies prototypes we identified the need for: new hazards on a climbable enemy, new attack abilities to balance an enemy's attacks better, and new environmental hazards to be used throughout the level to vary level pacing.

Without this early work we either would have never made these improvements, or we would have wanted to make them but at the cost of much more rework down the road.

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!

Taking out the trash

Weapon of Choice is programmed using Microsoft's .NET framework and is programmed in C#. This means unlike the C programming language, in which memory is deallocated manually, 'garbage collection' takes care of cleaning up memory. The difficult thing about it is while it's nice to have something handle this automatically, the Xbox 360 version of this garbage collection is really slow compared to the PC.

Last week I finally got Weapon of Choice running on the 360 only to find that it played really slowly and stuttered about. The good news is that I finally have the stuttering under control. It turns out the garbage collection was to blame. For every 1MB I was allocating and leaving to the collector to deal with, it would stall for almost a quarter of a second to clean up. Right now, during a full level, I basically allocate no new memory. It's very nice to see it moving fairly smoothly. For reference I used the CLR Profiler. If you're using XNA, don't use this one.

The bad news is, the game is still slow! Consistently slow, it's true, but still pretty slow. With XNA I have no good performance profiling tools on the Xbox, but I'd guess it's around 10-15 frames a second. That is where the game stands today. Thus I'm currently looking at ways to improve the framerate.
On game sites there's a lot of talk about 60 frames a second. I agree, that's really smooth. I have the game running at a little over 30 frames a second on the PC and it's still smooth and extremely fun. If I can get the game up to 30 fps on the Xbox I'm going to be thrilled. The game would be extremely playable and fun at that framerate.

Weapon of Choice runs on the Xbox 360!

It's official! I finally have the game successfully running on the Xbox 360. It's amazing to see it playing on the TV instead of my computer monitor. Knowing it's running on the console and seeing it on my shabby, standard def TV just makes it feel very 'official'. Once it ran I was able to bask in the victorious glow and enjoy that achievement for about 400 milliseconds.

Why about half a second? Because that's how long the horrible frame stutters lasted as the game chugged along on the Xbox! It was like the beginning of ABC's Wide World of Sports, but instead I got to feel both the thrill of victory and the agony of defeat in the same moment.

Yes, it was crushing to see the game barely limping along at about 5 frames a second. It actually stutters at about 10-15 fps down to nothing, so it's hard to estimate. Fortunately, I've been doing some reading and it seems like this slowdown conversion is common. There are many differences between the Xbox 360 and the PC architecture, and now I get to find out all about them! Or at least as many things as I can discover. I do have hope that I will get the game running fast enough for fun and hopefully to a point that it could even be considered smooth!

Here's a photo of the game running on the Xbox on a real TV.
That alone will keep me smiling for days (I won't let needing to optimize the game get me down)!

The Conversion is in progress.

Weapon of Choice has several levels running right now on the PC. Unfortunately, it needs to run on the XBox 360, since that's the real platform for which it's designed. The game is a high-action arcade style side-scroller that can be played with the keyboard and mouse but is best played with a game controller. The good news is, converting it to the 360 will be easier than usual since the game is built upon XNA. The bad news is, until now I've eschewed the 'Content Pipeline' part of XNA. I'm now in the process of getting the game to use that system.

I really enjoy gameplay design, gameplay implementation, and art. I don't generally enjoy engine or tools programming. I do it because it's necessary, and it's the right thing to do. This conversion is very painful for me, but I've managed to find a good amount of help on the XNA forums. When a full level is running on the 360, I'll post the exciting proof. As it stands now, here's my current test situation: a tree that draws off the top of the screen. It's not exciting yet, but I'm really happy to see that tree drawing right now!

Look at that! It's on the TV--not the computer monitor! It's very exciting!

Yes, that's a standard definition TV. Although I can see how the game will render on a HDTV since the computer monitor is pretty similar, I also like to see how the game will show up on the standard definition TV. I believe a significant portion of game players still have this type of TV--this includes myself.