According to the XNA team at Microsoft, we will see an update of XNA Game Studio Express somewhere in April of this year. Looks like the members of the XNA team have seriously taken into consideration the feedback coming from XNA Game Studio Express users. I assume that there are quite many improvements. From the most important improvements (at least from my perspective), I would mention the following:

1. Full support for Windows Vista. (Cool, I can now upgrade to Vista as I was reluctant to do so because of XNA Game Studio Express).

2. Bitmap font support (at the moment, as you might be aware XNA does not support bitmap fonts, so we have to resort to our own implementation or third party solutions like Nuclex fonts).

3. Math API improvements. No specifics on what is improved but...

4. BasicEffect will support per-pixel lighting, which is fantastic.

5. Support for volume textures (Texture3D).

6. Ability to read Vertex and Index buffers from Model types.

7. Sharing games with other developers will be extremely easy. It will be possible to package games in a single file (which can be downloaded or sent via e-mail).

Well, this list is not complete. You may wish to check out the post at the XNA Team Blog for a more detailed list, though I believe even that list does not fully describe all the updates that we will see shortly.

Here comes an updated version of XNASlots.

As you can see from the screen-shot, the game now displays stake, winning and balance information.

It is now possible to specify stake and selected lines and when the slot is spun, correct amount is deducted from the user balance.

You can hit 1, 3, 5, 7, 9 keys on the keyboard to select lines and the Spacebar is used to increase bet.

Maximum bet is $10. This is defined in a new constant named MAX_STAKE.

I use Nuclex fonts to display texts in the game. You can find more information about Nuclex fonts in one of my previous posts.

There are a couple of cosmetic changes to the code. For example, the keyboard input is moved to a new method UpdateInput.

We now deduct user balance after each spin and the Spin method has been amended to reflect this as well.

SelectLines and IncreaseStake are two new functions. As you may guess from the names, the former method select lines and the later increases user stake.

The Draw method has been updated to draw texts on the screen.

The LoadGraphicsContent has been changed to load a font.

The background image has been changed as well. I decided to put the stake, winning, balance panel on the main background.

In the next part, we will add the winning table and more cool stuff.

Download the Source Code

Download Compiled Version

While looking at my blog's statistics, I noticed that I get many visitors searching for slot game implemented in XNA. I decided to dedicate a number of posts to building a simple slot game in Microsoft XNA. I will start from a very simple demo game and ultimately grow the project to a full-featured slot game.

We will be developing a multi-line video slots game. More specifically, our slot game will have 5 columns and 3 visible lines as shown on the game screen-shot.

In this type of slots, there are 9 playing lines and a user can choose which lines he/she wants to play.

The heart of the game is a class, which I have named Reel. This class is in charge of rendering and animating the slot symbols on the screen.

In the image on the left, you can see the texture that we will be using for our slot game. The actual texture is a 800 x 1920 pixel image, which contains 12 rows and 5 columns. Each column corresponds to a single reel and each row corresponds to a stop or position (i.e. the symbol) on the reel. The texture width and height are multiples of 4 and thus we can use the XNA compression to reduce the file size of the texture. The nice looking symbols are taken from Microsoft's Office Clips Online web site.

Our reel will be using a virtual stop table. I will be describing the virtual table in an upcoming part but for now let's concentrate on the visual side of the game.

Each symbol corresponds to a stop on the reel. Let's agree that we call Stop 1 such a position of the reel when the lowest symbol on a column is located at the bottom line.

For example, if we take the first column, its Stop 1 corresponds to a position where the bottom 3 symbols (pineapple, coconut, berry) are visible on the screen. Stop 2 is when watermelon, pineapple and coconut are visible and so on. Thus, Stop 12 will be when the coconut, berry and cherry are visible on the screen. Please look at the illustration below to make sure that you have a correct understanding. 

You can download the source code and play with it. I have also put a compiled version for you to test. Run the application and hit the S key on the keyboard to spin.

Our Reel class is extremely flexible. If you wanted to make a single line slots game, all you had to do is to change the REEL_LINES constant value from 3 to 1.

In the next part we will add some labels on the screen so that we display different information (lines selected, balance, winnings) to the user.

Download the Source Code

Download Compiled Version

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!

In the previous post I have mentioned the modular gaming framework. Well, in this post I will show you why and when you might need this.

Suppose you are building a casino game. Usually it will contain many games like BlackJack, Video Poker, Slots, Keno, Roulette, etc. Every time you add a new game, you need to compile the application and then your users have to download the updated software. Of course you can integrate some sort of updating functionality in the software but again this is not very comfortable.

Now imagine you have a MAINGAME.EXE executable (with all the rest of the necessary DLLs which are referenced in the project). And then you have one more DLL, say GAMES.DLL, which is NOT referenced in the project. In other words, the MAINGAME.EXE will load this module and use whatever games we have in it.

So here we have the first strong side of the modular approach - easy maintenance and upgrades.

Now we can move to a more serious example where the modular approach is not only desirable but is almost absolutely required.

Suppose you have a distributed, client/server based gaming application. A typical example would be a slot machine software where each slot machine is connected to a centralized server via TCP/IP network. Now imagine that these client terminals should be able to support such different games as slots, roulette, keno, etc. To make things even worse, imagine that you have hundreds of such gaming terminals scattered throughout a city or maybe even the whole country and what is the most important, imagine that the terminals have different owners/operators. If you release new games (and this is necessary to keep players happy) imagine how much effort (time, money, energy) will be associated with upgrading software on each terminal.

Again, you could introduce some sort of upgrade mechanism where the software downloads new files and so on and so on but compare this to the beauty of downloading the game only modules (and content by the way). In our scheme you would not even need to re-start the software. In other words, we can achieve upgrade with no downtime.

As we progress, I will provide additional scenarios where the above suggested approach is the way to go.

You should realize that this approach is quite specialized and not every (I would say not many) games will need it. However, again, there will be certain situations where you might need to use the suggested approach.

I am frequently asked to start my own blog. Unfortunately, due to the lack of time I've never managed to start one. However, I finally decided to devote some of my "free" time to sharing my experience with the rest of the world. So, here we go. 

As you might have concluded from the title of the blog, much of the focus will be on the Microsoft XNA programming and game development. However, from time to time, I will introduce you to interesting and useful tricks of general programming and especially programming under .NET and C#.

 

Please keep in mind that XNA is a relatively new (but really interesting) framework. So, I would dare to say that all of us are new to it. Because of this, sometimes even experienced developers may not find the best solution for implementing a particular functionality. This is why the blog is open for everyone and feel free to post your comments and suggestions.

 

While the (XNA) framework is still in its infancy, there are already many web sites dedicated to XNA development and programming. So, it is good to see that the development community is embracing the technology. While I will devote many posts to general XNA programming, the primary focus of the blog will be on building a modular gaming framework. Modular what... you may ask. This will be clear in a moment.

 

Suppose you would like to develop a gaming software where it is possible to plug in games that are not available at compile time. In other words, you have a main program and the actual games are in a separate (or in multiple) DLLs. The idea is that you do not have a DLL at the compilation time. Well you get the idea. It is something like an add-on or plug-in (call it as you prefer) framework for our XNA games. The idea has been around for ages and almost every serious software package (and sometimes event simple applications) supports some sort of extending through plug-ins or add-ons. So, we will apply the same philosophy for building our games under XNA. If you still do not have a clear picture, please bear with me as in the next posts everything will be clear.