While many have had the chance to play the N.A.M.E game, some creative seeds have been sewn.  I'm getting several questions coming through about how to create a Zune game. To build your own Zune game, there are several points of optimization unique to developing for the Zune device itself (limited screen space etc) as well as using C# and XNA Game Studio Express 3.0 CTP.  Through the course of making his first Zune game Paul Oliver of Legendary Studios came up with some useful tips and tricks to help all you aspiring Zune game developers to create your own:

Worms like game on the Zune     Free XNA Zune Game Download 


Zune Programming Hints:

1) Do not use strings or ToString(). Our game uses a large number of hash tables and by moving from a string based hash table to an Enum based hash table we were able to increase performance substantially. We also used to use strings to represent team names and in a few other areas of the code base. String based comparison is expensive, and ToString() is even more expensive. The only thing we currently use strings for is our animation system and we hope to move away from that soon.

2) Do not try and retrieve or set data from the graphics device. We were previously doing per-pixel collision with deformable terrain. When you fired an exploding weapon the "explosion" sprite was subtracted from the ground to create a "new" ground that had a hole in it. This calculation took more than 1second to do and resulted in a large lag spike.

3) No render targets. In a quick hacky attempt to get the game rendering horizontally instead of vertically we did a render of the whole game to a screen sized render target, and then rotated it to fit it to the screen. This dropped our frame rate from between 23 and 30fps to between 5 and 8.

4) Watch your Iterators. How many times do you loop through your game objects? If its more than 1x for Update and 1x for Draw your probably doing too much for the zune, in addition you should think about your logic a bit more - perhaps a sorted structure would be better to store your game objects in, or a tree of some sort? We were looping through our game objects 4x in Update [we and post, postpost, and postpostpst updates] and 3x in Draw [we had a pre and post draw]. It turns out these were not actually needed since we stored everythin in order. The original purpose of them had been lost when we converted the main game-object data structure into a List from a hash table. The pre and post draw where for using render targets and applying shaders, things that you shouldn't do on the zune anyway.

6) Sprite Batches - Use only 1. If you need to store your drawable objects in a sorted structure to make this possible then do it, the performance will pay off on the zune.

7) Remember a 10% speed improvement is a HUGE boost to fps!

8) Doing anything too much is a bad idea. We were previously doing per-pixel collision of objects against the terrain, and objects against eachother. The performance for this was acceptable on both the xbox360 and on Windows however for the zune we have tossed it out becuase it involves a very large number of checks [even after optimizations].

9) Use power of 2 sized textures. http://en.wikipedia.org/wiki/Anti-aliasing Antialaising is a problem for rotated textures on the zune, especially if your textures are not of a size that is power of 2 - 2,4,8,16,32,64,128,256,512,ect... You spent a good deal of time on these graphics spend a few extra minutes and make sure that the texture is in a correctly sized image.

10) Preload all your textures. Use a custom resource manager, there is one in the previously uploaded code. Loading a texture from the zune had drive is very expensive in terms of time, while simply passing around a reference to it is practically free.

11) Cut out any code that access input devices the zune doesn't have. These calls to gamepads that doen't exist, or even buttons that doen't exist are very very expensive.


Use these tips for good - we want to provide as many free zune games for download as possible!