Welcome to the first series of articles on Managed World. This first installment will be short and sweet (the exact opposite of me, some might say (hopefully that doesn't include my wife!)). We will simply discuss the plan for the articles and what you might expect from where the articles are going.

Why These Articles?

The first thing you might ask is "why are you writing these articles, o' wise one?" (okay, I admit, the "o' wise one" was creative license I took since I am the author here after all). Well, I'm hoping that these articles can fill a void that is currently unaccounted for in the community of game development with Managed DirectX (and to a lesser extent, unaccounted for in the hobbyist game development community as a whole, irregardless of technology). What is this void? Well, the biggest part of the void deals with software architecture.

As an aspiring software engineer, I find that talks/articles about software architecture in the game development community are solely lacking. One need only look at the different game development books to see that this is true. I can find potentially hundreds of books that have been written about game development. However, the majority of these books are about the implementation of the technology, not about the higher question of "how do I architect a game". There are only a handful of good books (and perhaps even less than that) on the market currently that talk about how to architect the software behind a game. And that saddens me. 

When an aspiring game developer asks how to structure a certain part of his game software, the usual response from the community is "just do it, you'll learn eventually". And while I agree that learning through doing is largely a good thing, one need only look at the success of design patterns, refactoring, and other academic endeavors to realize that there is much that can be taught to young developers. Not only does this aid in teaching, but ultimately I believe this leads to higher quality software. And when it comes to games, this is an area that drastically needs to be improved upon.

On the surface, it would be easy to come to the conclusion that these articles are about game development in Managed DirectX. And while that is certainly true, it is only superficially true. You see, the purpose of these articles isn't so much about developing games. As I discussed, my true love is software architecture. In that vein, these articles are written in a similar approach to Andre LaMothe's XGameStation. The goal of these articles are largely to teach best practices of software design and architecture using game development as merely a context to guide our discussions.

Don't be discouraged though. We will discuss a lot about game development, and we will write a lot of game code. Software architecture can be viewed merely as a subtext of these articles, if you wish. Heck, if you are here simply to learn how to write a game, and you don't care about software architecture, that is fine with me also (although I hope that I can show you the benefits of software architecture by the end of the series).

A Word About Best Practices

As mentioned above, I will be encouraging and teaching best practices throughout this series. Some of these best practices are merely personal taste. Others are best practices that are discussed and preached about in such books as Code Complete, by Steven McConnell. When applicable, I will do my best to point you other resources like books to help you further your craft.

As an example, I wish to quickly discuss the idea of best practices when it comes to writing code. In my personal code, I have adopted a slightly modified version of the coding standards used by development teams internal to Microsoft. The first resource I would recommend is the .NET Framework Design Guidelines. This is an excellent resource released by Microsoft describing best practices when it comes to the structure of ones code in .NET.

Also, I use FxCop as much as I can against my own code to validate that I am meeting this best practices. This is a very good habit to get into. It will help you fight the urge to write "quick and dirty" code and help you keep your code in the best shape possible.

Other best practices will be discussed as we come across them in our articles.

The Plan

Okay, enough of this beating around the bush. Let's get to the chase. What is the plan for the articles? Well, it is pretty simple really. We will start out at a slow pace in order to get the ball rolling. Probably the first five articles or so will be dealing with higher architectural issues and higher abstraction coding. After that, we will start diving into the meat of the series.

The goal is to have a couple breaks in between articles every now and then in order to code up a simple game using the existing code base we have at that time. According to the current plan, we will be on an adventure of about fifteen or so articles until we get to our first sample game. These first fifteen articles will be laying the core foundation that all our games will be built upon. Fifteen articles may sound like a lot, but it's really not. I want to keep the articles in bite-sized shapes so that they are easily digestible but, at the same time, don't sacrifice content. There is nothing that bothers me more that finding articles that sound really cool, but contain no real content, just fluff. \

After our first sample game, there will be five or so more articles before our second sample game. After the second sample game, there will be four or so more articles before we dive into the final destination of this article: a simple 2d platformer/sidescroller. The final game will probably take at least a couple of articles to cover. One thing is for sure, we have a long and fun road ahead of us :).

As for source code, source code for articles will be posted periodically in the series when applicable. The source code will be released under the CPL and meets the Open Source Definition. Feel free to do anything you want with this code, as long as it meets the CPL, that is.

In Closing

I know what you're thinking. This article was basically a bunch of fluff. You're right. However, I want to set the right tone for the series and let you know where I wish to go with the series. Other articles will follow soon. With the current plan that I have, it looks as though the entire series might be 25+ articles. That's quite a bit of writing and I hope I have it in me. So, please enjoy the articles. I only hope they help at least a single person out there wanting to get into game development!

Until then, take it easy! If you have any questions, feel free to contact me :D.