Delta Engine

Delta Engine Blog

All about multiplatform and game development

XNA Shooter Game

I developed a little Shoot'n'up game in the last couple of days. It is actually quite fun to play. It is just one level and is kind of a prototype. The game will be released together with my XNA Professional Game Development book in a few months (it will be freely available from my website shortly after that). My book features many other games too, it is not just about one game, there are many arcade, action and other games in the book (about 8 games or so) and they will be described as I explain all the important aspects of Game Programming and the XNA Framework.

For now I can only give you a little video about XNA Shooter. I hope you like it.

A "little" 1920x1200 screenshot:

These days there are a lot of discussions about XNA, especially in the GameDev.net boards and of course in the official XNA forum by Microsoft.
http://www.gamedev.net/community/forums/topic.asp?topic_id=430119
http://forums.microsoft.com/msdn/showforum.aspx?forumid=846

I also want to mention a great article by the .NET Compact Framework team about the .NET performance on the Xbox 360 with the XNA Framework. The main issue here is the Garbage Collector, which is not generational and theirfore can only collect all the objects in the GC at once and not in 3 levels like in the normal .NET Framework, which can handle a lot more dead objects and more complicated situations.

Here are the links to the .NET Compact Framework on XNA article:
http://blogs.msdn.com/netcfteam/archive/2006/12/22/
managed-code-performance-on-xbox-360-for-the-xna-framework-1-0.aspx

http://blogs.msdn.com/netcfteam/archive/2006/12/22/
managed-code-performance-on-xbox-360-for-xna-part-2-gc-and-tools.aspx

From my experience there are a couple of things you have to remember when developing XNA games on the Xbox 360. All of these issue are not a big deal on the PC, but they can cost some extra time until you get them right. One of the main problems is that if you develop your game on the PC only and then test it on the Xbox 360 only at the end a lot of things may go wrong (bad performance on the .NET Compact Framework, UI elements at the border of the screen, which are just not visible on some TVs, bad Xbox 360 controller support, which is the main input device for Xbox 360s, etc.).

  • Test test test. This is the most important tip. Write unit tests and constantly test them on your PC AND your Xbox 360. I keep 2 projects open at the same time (both of them use the same files, but I only develop the PC solution and use the Xbox 360 solution for deploying and testing only). Almost all of my classes have unit tests and I constantly test them until they are completed.
  • Don't use foreach loops, especially not in tight render loops. This may sound a little crazy since it does not matter on a PC game and todays CPUs are fast enough to handle the creation and deletion of many thousand objects each frame, which most games don't even need. But on the compact framework you will spam the memory even with things like foreach loops because a new enumerator instance is created everytime you start a foreach loop. After a while there will be a lot of dead objects, which have to be collected. This can take some time and slow your game down immensely. The PC version might run at over 200 frames, but your Xbox 360 version is stuck at something like 30-40 frames. Avoiding creation of new data each frame and avoiding foreach loops (just replace them with normal for loops, it is mostly just 1 line of extra code) can improve your performance by a factor of 100% or more.
  • In Arena Wars I never created any data during the game. All objects were created at the beginning of each mission and they were reused (which was no big deal since the game principle did not allow an infinite number of units, it always stayed around the same because you get your money back from dead units to build new units). In later project I did not care so much about creating new objects and I coded just the easy way because unit tests drive you into a direction to quickly develop solutions, which work and are tested, but may not be the best in other situations like for the Xbox 360 .NET Compact Framework. That is ok because we can now use the unit tests to check if other solutions work just they way we expect them to work. For XNA Shooter and XNA Racer (and a couple of other new game projects) I now make sure that most of the game data is created at the beginning of each level and not dynamically during the game.
  • Save-Regions on TVs can be a pain in the ass. Just google for Xbox 360 screenshots and you will notice that the GUI (graphical user interface) looks a lot different from most PC games. PC games have often UI at the screen border showing you tips, little buttons and other not so important things. If you do that in your Xbox 360 game all of these UI elements may be cut of on a regular TV. For the XNA Shooter I had to rework all the UI elements because they just did not fit on a TV screen and it was not practical to put them in a bar (like the windows task bar) because it looks so different on the PC and certain TV monitors. Instead I put all UI elements in floating bars, which will be adjusted depending on the screen the user is looking at.
    These are some of the Save-Regions I have encountered:
    • PC: 100% visible
    • Xbox 360 connected through a VGA cable: 100% (or close to 100%) visible.
    • Xbox 360 connected to an old style monitor with SCART: around 92% visible.
    • Xbox 360 connected through Component cables to my new Dell 24" Monitor (yeah HDTV): around 93-95% visible (depends on the resolution).
    • Some old TV sets (according to the XNA docs and tips on the web) have a save region of 80-90%, but I never saw the 80% case, that is probably the worst case scenario.
    The important thing is to keep the important UI element in this inner 90% (or 93% if you want to be close to the edges) rectangle. This means instead of using a full 1920x1080 pixel resolution you only use 90% of it (1728x945). Or just start rendering UI elements at about 5% of the screen (x coordinate: 96, y coordinate: 54). This pixel locations obviously depend on the screen resolution, just calculate them in your main class and use them whenever you render UI.
  • There are probably a lot more tips I can give, but I'm to lazy right now. Maybe more in a little while :)

Btw: I currently also do a lot of OpenGL development again and I have to say I have totally forgotten about the way you can program OpenGL. It is often a lot easier, it only gets hard if something does not work the way you expect it to be (but thats hard in DirectX too). Well, the most annoying part is of course that you have to wrap all OpenGL methods through PInvoke and that just costs time. On the other hand if you already have a robust framework (like I have with Arena Wars, hehe), it is relatively easy to plug in new features. It also took not long to learn the differences between glsl and hlsl. I do currently also test out the FX Composer 2.0 (alpha), which has a great idea behind it, but it is too much like Render Monkey and that is never a good thing. Render Monkey by ATI is just overcomplicated and hard to use (and was not updated for 2 years, which shows that no one even uses it anymore). The great thing about FX Composer 1 was the fact it was so easy to use and it did only support a very limited feature set. It is not the best tool ever, but it was certainly a lot easier to use than FX Composer 2.0, which will hopefully be improved before NVidia release it.
I have confidence that NVidia will deliver a great tool as always, but they have lost a lot of fans in the last months because of the lack of drivers for Vista, especially for the Geforce 8800, which does not work at all in Vista, but it is the only card on the market that even supports Direct3D 10 (and the new cool unified shader technology in DirectX). The only way you can currently use the new graphic card features is to program them yourself natively with OpenGL ... but my 8800 is in repair anyway, else I would have tried out some of the new features by now.

Your Christmas Present: Rocket Commander XNA


ArenaWars Reloaded - Coming Soon
Hey now!

Before you read on (I guess this is going to be a long post) please also check out www.exDream.com. We made some pictures from our new office and we recently announced ArenaWars Reloaded (see image on the right), a new game with a new graphic engine and many new cool features based on the original Arena Wars idea (the game play and levels will be similar, but look much better).

My little Christmas present for you is the new port of Rocket Commander to the XNA Framework. It allows you to play the popular Rocket Commander (113 000 played games already can't be wrong) on your Xbox 360 for the first time. You just need an Xbox 360 and have XNA on there. Here are the downloads, the file sizes are are little bit bigger than the original game (my comments are below):

  • Rocket Commander XNA on Windows (16 MB): Includes Setup, that will automatically install DirectX Dec 2006 and the XNA Framework if you don't have it yet!
  • Rocket Commander XNA on the Xbox 360 cannot be redistributed. You currently have to download the source code and run it in XNA Game Studio Express to even get it on your Xbox. Once you have Rocket Commander XNA deployed with help of the XNA Launcher you can start it anytime you want to without having your PC on or having to redeploy it.
  • Full Rocket Commander XNA source code (53 MB): All Content, Sound and Music files are included in this download, this is all you need to compile and run the game on Windows and Xbox 360. The music files are almost 50MB (5MB as mp3, which is not supported in XNA).
  • Rocket Commander XNA source code only (213 KB). No content files (models, textures, sounds, etc.) in here, just the .cs, .csproj, .sln and .fx files.
Update: 2007-01-03: Fixed some Bugs with the Input, PostScreenGlow and when device loses focus. Works now more stable. Also cleaned up some of the source code.

Note: Use RocketCommanderXna.sln to compile and run the game on Windows and RocketCommanderXnaXbox360.sln to compile and deploy it to your Xbox 360. For additional details please read the XNA documentation.

The game runs at a very good performance on the Xbox 360, you still got over 60 fps in HDTV 1920x1050 (1080p) with full AA enabled.

Check out some of the new screenshots. Warning, all of them are big, HDTV 1080p resolution. Actually I could not capture any images from the Xbox 360 directly, which runs at 60fps on 1920x1050 and uses fullscreen Antialiasing and using the highest settings. These screenshots are from my PC hooked up to my new 1920x1200 monitor, also nice :)

The main menu. Not much happend here.

The ingame HUD and general user experience has changed a bit. There is also a new object for the goal since creating a sphere dynamically is not that easy in XNA.

Rocket Commander is still fast and it pumps up your adrenaline even more in combination with a big monitor :)

Another screenshot from the last level. Please note that you can see more asteroids at the same time than in the original game. You can also look a lot farther and see more items from great distances.

The explosion is unchanged. It still looks the same crappy way, but the AnimationTexture class had to be reimplemented to work with XNA textures now.


Initially I thought "Hey, this is easy, let's port Rocket Commander to XNA.". The initial port attempt was pretty good, it took only 3-4 days to port the 25 000+ lines of code used in Rocket Commander. I could remove some classes and I also simplified some classes, the total number of lines got smaller (~20 000 lines), but after adding some new features and some new unit tests and some testing code for multithreading it is about 22 000 lines of code, still less than the original. XNA is definately the future, MDX was great, but it was not updated for a long time and if you start something new, go with the fresh XNA Framework!

Here are some of my experiences from the process of writing Rocket Commander XNA. Please note that some of these comments were written while I was developing and kinda sleep deprived. Beware of the harsh tone, in the end all worked out great :)
++ means this topic was great and better than MDX.
+ means it was good and nice to work with.
- means I did not like that feature or it was easier in MDX.
-- means this was really annoying and should be improved in the future.

By the way: I did Rocket Commander XNA just for fun, but it also proves how great XNA performs on the Xbox 360. Try to find any other game with this many polygons and effects running in 1080p (1920x1080) with AA enabled on the Xbox 360 ^^ It does not look as good as Gears of War or Halo 3, but it took only 1 man and a short time to develop and it still pushes up to 80-100mio polys each second to the GPU (in some early unit tests, the game runs fine with 20-30 mio polys per second most of the time, check out the model class and its unit tests for more details).

I also use the Rocket Commander XNA engine for 2 other smaller projects because I like the fact that I can test and play these games on the Xbox 360 too and having a complete engine up and running is always a great plus, even if you know how to do a game. It is just easier if you got all the basics covered.

Topic Rating Comments
Sound ++ Very easy to use, 1 short class instead of 2 complex ones I had in MDX. Once you get used to XAct you learn that it is a good tool for sound effects, at least if they don't have to be loaded dynamically. The porting process was very simple for sound effect files, they just had to be dragged to XACT and then the project had to be saved, that's it.
Music -- A lot of converting, different formats, hard to handle, a lot to test, bad documentation. The music from RC was below 5 MB, now it is over 50 MB, which just blows up the source code. Even the compressed take up 13 MB on the PC (ADPCM) and 9 MB on the Xbox 360 (XMA), both in a quality below the original. The rest of the game content (5MB compressed textures, models, effects, sound, etc.) stayed almost the same and could be reused for the most parts.
Unit Testing - Harder to use on the Xbox 360, no edit and continue support in the compact .NET framework. There are also no unit testing tools available and all you can do is to call static unit tests from the program class, which is still useful, but harder to do. I still prefer to test on windows. One great thing about the Xbox 360 is the fact that you get multimonitor debugging for free if you have a TV screen and your PC screen. Debug and step through code on your PC and see the result on the TV screen :)
Window handling ++ No extra code required, I could remove several classes and even the helper classes that are still in Rocket Commander Xna are not required for the most parts. Except for some of the game component classes and the design that is not really useful (more about that below) the Game class is really easy to use and simplifies the process to create a new game in a few minutes.
Shaders ++ Everything in XNA is shader based. The original Rocket Commander runs on fixed pipeline only hardware too, but it was a lot of work to handle 2 ways to render everything. With XNA you just have to write the shaders once and just use them. They work perfectly on the PC (Shader Model 1.1 up to 3.0) and on the Xbox 360, all fx files compiled without any problems.

Some shaders had to be adjusted to be right-handed now instead of left-handed like in MDX, but that did just take a few minutes to change and all the rest of the shader code could be reused. In the last few months of XNA development I never had once a problem with shaders in XNA, thats really great :)

IDE Features - MDX is much older and was never made popular by Microsoft. XNA is new, fresh and great, but it is missing some serious features like Animations for Models. You can implement it yourself, but why even bother with the content pipeline, do it all yourself. It will be much easier and you can extend it in any way you need in the future.

XNA development is currently also only avialable with XNA Game Studio Express, which is painful if you are a pure Visual Studio 2005 Professional developer and have lots of plugins you rely on every day (source code management, code rush, testdriven, slickedit, explorer, and many more). This will change in the future and XNA will grow up and dominate the whole world one day :)

Content -- Sorry, I just don't like the content pipeline (and I have been using it for several months now)! It is bad for dynamically loading textures or shaders or reloadindg them after changes (just not possible with compile-time generated content). On the windows platform you can still load textures and shaders the normal way, which is good, but loading .x file models is just not possible, you have to use the content pipeline. And the content pipeline sucks feature-wise, you have to implement all of stuff yourself.

This is my main problem, why should I re-implement generating tangents, shader technique indices, fixing other x file problems, etc. all by myself in a custom content processor, which is not easy to write IMO (bad docu again). By the time I did all that I would have implemented a much more flexible and vesatile custom importer like from .collada files, which are very popular these days ...

Performance + The overall performance especially when just doing some benchmarks and performance tests is absolutely perfect on both Windows and the Xbox 360. The GPU is pushed to its limits and there is no reason why you should be afraid of managed code. Windows performance is especially great, all my programs and games are completely GPU bound even in low resolutions and even when they only have one thread.

On the Xbox 360 the performance is much worse and you have to take many things into consideration, which is hard because there is again not much documentation around. For example the worst thing you can do on the Xbox 360 is to generate new data each frame, even if you just create an enumerator by executing a foreach loop, it will affect your performance. The good thing is that you have 3 cores (and 6 hardware threads) at your fingertips, which allow you to optimize performance. It was possible for the Rocket Commander game to optimize the game loop a lot because the physics and update threads eat up almost 50% of the CPU time. On the PC it does not matter much because my GPU is slowing everything down (see image below), but on the Xbox 360 I was able to almost double the framerate using multiple threads, nice :)


Click Image for to maximize it.

Usability - It gets a little easier though all the game helper classes, but the game component class is pretty useless, you can implement something like that in 5 minutes yourself. There is also a DrawableGameComponent class, but you have to call Draw yourself, whats the point here? My classes have some Draw or Render method anyway, I don't need to derive them from GameComponent, I can implement my own interfaces and implement exactly the features I need. Often it is easier to give the Render method a few parameters or even call it several times with different parameters, all that is not possible with DrawableGameComponent.

Next there is the content pipeline, which is just a pain in the ass for 3d models. This makes the usability very bad, especially if you develop on Visual Studio 2005 (not Express), which does not support the content pipeline. Also if you are a Vista-Developer XNA Game Studio Express will also not run as expected and my intern hates now both Vista and XNA. It should not happen that someone can get so angry about such great pieces of software, just because they don't work together ^^

Porting + If you have written a XNA game or have some XNA code flying around (like the Rocket Commander XNA source code) it is very easy to port existing MDX code to XNA. If you do it from the scratch it is a lot more work and testing until everything works out the way you expect it, but overall it is easy to port from MDX to XNA. Thats very cool, thank the main MDX man Tom Miller for that, who architected parts of XNA too. Porting is easy, but getting the game to work the way you want on the Xbox 360 is not that easy. First of all you got that annoying content pipeline again (I keep repeating myself, maybe I'm too angry ^^), then you have to make sure that you don't render important User Interface on the none-visible area of a monitor that is plugged into a Xbox 360. For example Rocket Commander was only designed for 1 resolution to look good, it had a very small font for some texts on the screen, which is unreadable on TV monitors. Rocket Commander did also not scale well on Widescreen monitors and it rendered a lot of UI elements at the screen borders, which were cut off on TV monitors.

The porting took maybe 3-4 days, but I spend at least 4 more days for fixing UI elments and improving the code on the Xbox 360, optimizing asteroid rendering, physics and multithreading. I did not expect that it would take that long and I had only some time in the evenings to even get some XNA work done.

Most annoying Porting left-handed models, matrices and other complicated math functions over to the right handed system that XNA uses. Maybe it would be easier to use left handed matrices like in the original Rocket Commander for XNA too, but XNA does not provide them and I did think getting it to work with a right handed system would be easier. Then there is of course the problem getting the models into the content pipeline. I used a special content processor, which is also included in the Rocket Commander source code and it can be used for other projects too (I use it for everything I do with XNA).

Another annoying thing is the re-deploying of existing game content to the Xbox 360. If you just have 5 files it will not matter to you, but if you got over 50 (Rocket Commander) or even several hundert content files and sometimes due some crazy bug all these files get re-compiled or re-deployed over and over again, it gets really annoying. It takes 30-60 seconds and is not fun ... good think it does not happen that often, but it is still annoying me. Maybe the main reason for regenerating the content on my PC is the fact that I often switch between the Xbox 360 and Windows platforms to test if everything is working the same way on both systems.

Missing features The XNA version does have all the features from the original Rocket Commander game, including all levels, sub menus and the whole game play. It does not have animated models however because it is not supported out of the box in XNA and I did not have time to reimplement this feature. It does also not support polygon based collision checking for asteroids, which can sometimes be annoying if you fly near asteroids or if you want to fly through the donut asteroid. The problem here is that the mesh intersection methods are missing, all you can do is render models, not much else. Last but not least XNA does not support any network code. On the windows platform it would be possible to still use the Webservice to upload and get highscores, but for compatibility with the Xbox 360 the code is currently commented out. If you want to play with online highscores, just play the original Rocket Commander game.

There are also some smaller issues like getting the bitmap data of a texture on the Xbox 360. There is method called GetData in the texture class, but it is not supported on the Xbox 360. There is also no bitmap class in XNA because you would need the System.Windows.Forms namespace, which is not included in the .NET compact framework. I ended up saving the level data into a custom file (.level) and then loading it again with help of standard IO methods (byte by byte, but the loading process is still fast, less than 1 second for all textures, levels, models and sounds).

The Rocket Commander Mods are also not supported yet, but porting them should be easy with the existing Rocket Commander XNA source code.

Improvements The controls, especially for the Xbox 360 Controller have been improved. It is now much easier to fly the rocket, the speed was increased and you can look at up to 4 times as much asteroids thanks to several optimizations and the great performance gain of using multiple threads on the Xbox 360. There are also many smaller improvements to the UI, the structure and some classes in the game, but the game looks still very similar (see screenshots above).

Maybe I will write a little more next week. I should get some sleep now, in a few hours it is christmas time and I have not packed any presents yet.

Now have fun with Rocket Commander XNA and have a nice christmas of course ;-)

PS: I know my blog has currently some problems (posting and comments do not work as they should), I will fix that in a week or two, have currently not much time to investigate this issue.

German developer price: Deutscher Entwicklerpreis 2006 - Pics

Yesterday was the german developer price 2006 event (Deutscher Entwicklerpreis 2006) in Essen (Germany).

The Lichtburg (light castle) in Essen.

Miriam Pielhau (known from german TV, well at least if you watch german TV, I don't) moderated the event together with the usual hosts (Aruba, politicians, other guys from the german game developer scene).

Martin Kesici (Sat1, Superstars star or something, never saw him before either) did make some music in a short break. Was neither great nor bad.

After about 10 prices were given to the developers almost 2 hours have passed and the rest of the 30 prices had to be given out. In a IMO unprofessional manner everyone just had to come on the stage and get his price. In a matter of minutes the rest of the prices were given out.

Then everyone left to the after-show party with more food, drinks and some games.

And Pong (actually it is called Plong) on the Xbox 360. It really shows how to use the GPU correctly and have all 3 cores at full CPU load. The game looks actually a lot worse, my bad camera just made it more beautiful because I always have a blur, glow and motion blur effect on all my pics :)

Some angle girls dancing around. Reminded me of the song: Rammstein - Engel

And finally a little in-house fireworks show at the end. Always fun to watch.

All in all it was a nice and enjoyful event and it was nice to meet all the usual faces again. If you want more photos check out: www.deutscher-entwicklerpreis.de

XNA Game Studio 1.0 released



Microsoft released their XNA Framework 1.0 and XNA Game Studio Express today, which allow you to build games for Windows and the Xbox 360. To compile and play your XNA games on the Xbox 360 you will need to join the "XNA Creators Club" (for $49 per 4 months or $99 anually). There you will have access to additional starter kits, features, etc.

I ported the Rocket Commander game to XNA, just for fun .. and it runs great. It is optimized to run on all 3 cores of the Xbox 360 and I will finetune it a bit in the next few days to run perfectly on the XNA 1.0 release. The performance is really good, the current build has over 800 fps in PAL on the Xbox 360, in very high resolutions (have only 1600x1200 monitor, but I will test it on 1920x1080 too later this week) it still runs good with more than enough frames.

Here is a little preview picture, it shows about 8 times more asteroids and runs at over 200 fps here. I will try to post some of the porting problems in the next few days, for example all the network and internet code had to be ripped out from the Xbox 360 build and the sound features are a little stripped down in XNA (no 3d listener support, not easy or not even possible to do any stereo or surround sound, looks like playback is all mono :-( ).

Early alpha screenshot of Rocket Commander XNA: