Collision detection is probably one of the trickiest things in game development. A major problem associated with collision detection is that as the number of objects increases for which you need to check whether they collide or not, performance of the game drops. With a couple of sprites you may not even notice any performance issues, but when the number of sprites becomes relatively high (a machine gun is a good example) performance may seriously suffer. Things get worse when you need to detect collision between animated sprites.

The aim of this post is to give you a number of links where you can find how other folks implement collision detection. A general approach is a two-stage process. The first stage is to check for potential collisions using a bounding box. If the first stage reveals a potential collision, the next stage is to perform a pixel level collision detection.

Gary Kacmarcik has collision detection implemented in his XNAExtras. A good feature of Gary's method is that you can set if you need a pixel level detection or if the bounding box detection is enough. You can read more at http://blogs.msdn.com/garykac/archive/2006/09/24/769335.aspx.

Another destination that I can recommend is an article by Michael Morton, which can be found here: http://www.ziggyware.com/readarticle.php?article_id=48. I would also recommend reading another, more advanced article by Michael, where he expands his method to rotated sprites. It can be found here: http://www.ziggyware.com/readarticle.php?article_id=52

Chris Taylor's article is also very good and provides enough theory in a short but easy to understand manner: http://dotnetjunkies.com/WebLog/chris.taylor/archive/2006/09/30/148798.aspx.

Many industries (and I would dare to say, the whole history) develop in cycles. Game development is no exception. In the beginning (for some people this may be DOS era, for some even earlier, mainframe era) games were extremely simple and boring and were developed by individual programmers. Then games became more interesting with nicer animation and effect but still game development was more of a hobby. Gradually (and this has not happened overnight) game development became teamwork and ultimately the craft of companies which over time turned into large corporations.

Looking realistically, today it is (nearly) impossible for an individual to develop a successful commercial game. Yes true, you may come up with an excellent game concept but turning that into an actual game is virtually impossible. Even for small teams it is extremely difficult next to impossible to compete with large game development houses.

With the introduction of XNA, Microsoft is making an attempt to give individuals (but more realistically to small teams of 3-5 people) a chance to create games that may become commercially successful. This hypothesis is further strengthened by the fact that a game developed with XNA runs both on PC and on XBOX (and maybe on Linux in a near future).

But we should not forget that actual game development is just a starting point. Once a game is developed it needs marketing and distribution. This is especially true for games targeted to XBOX.

Anyhow, only time can show if time has comes for small teams and individuals to enter the commercial gaming market. Personally, I believe that a new strategic window is opening in the game development and this industry will see considerable change within 5 years from now.

As you develop your game in XNA, you may soon notice that the size of the game increases quickly. More precisely it is the XNB files that are taking up huge space. Usually this happens when you do not use compression for XNB files. This can easily be solved by changing Content Processor for your 2D art (textures) from Texture (Sprite 32bpp) to Texture (Model, DXT, mipmapped) - XNA Framework.

The size of the XNB files shall decrease significantly. For example, our backgrounds (1280x768) dropped from around 5 MB to 1.5 MB.

One thing must be noted though. In order to use DXT compression, the dimensions of a texture (both width and height) must be multiples of 4. Otherwise, Invalid texture error is guaranteed when you compile the project.

The screenshot below demonstrates how to do that.

In the first post I mentioned the infancy of XNA. One aspect where you can feel this is a lack of any text rendering capabilities. We do not have many alternatives here. Thus, we must resort to bitmap fonts which must be created (for this you need some kind of tool) and then used in the project (for this you need some classes too). To use this method, you may wish to check out the following link http://blogs.msdn.com/garykac/articles/732007.aspx.

However, there is a better and more elegant way - enter Nuclex Fonts. Nuclex Fonts is a Content Pipeline Importer that imports any TrueType Fonts in your XNA project at compile time. Further, you can use the font the same way as you use Textures, Models, etc.

I have recently downloaded Nuclex Fonts and it was extremely easy to use. The application was rendering texts in 5 minutes. I do not think you can devise any easier way to implement text rendering. So, if you are still reading this, just open up your browser and download Nuclex Fonts from http://www.nuclex.org/downloads/developers/kits/nuclex-fonts-1-1-0.

Please note that as of now Nuclex Fonts does not support importing UNICODE fonts but as the author mentions in his web site it will be coming up soon.

On a positive side, I would mention that the quality of rendered text is perfect (antialiasing is supported too), works both on PC and on XBOX and is extremely efficient and the best of all, the author provides source code. So nice!