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.