A design pattern made famous in the .NET community by Microsoft’s ASP.NET, the provider model explains is a pattern that supplies the end-developer with a plug-and-play architecture. The provider model is most often used when you have a consumer object that is dependent on specific functionality that can be supplied by one or more underlying systems. The major benefit of which is an increase in manageability and reusability.
This series is devoted to the design and development of my framework, FGF (Focused Games Framework), and aims to cover topics like async content management, WCF services, and many more. In this first article, I cover how to setup Visual Studio 2008 for coding the framework. It is important to understand that I will be using Visual Studio Team System 2008 and thus may have features that are not available in the Express edition. It is possible to get around many of these or ignore them completely, however, so not having Team System does not mean developing FGF is impossible.
The first step is to open up the IDE and create our solution. When starting a large solution such as the one for FGF, I find it useful to create a Blank Solution so that the solution’s name can be different than that of the first project. Again, this can be worked around in Express as well as other versions of the editor.

This tutorial covers a basic way of implementing two dimensional fog of war for a game in XNA and assumes you (the reader) has basic knowledge of C# and the XNA Framework. To get things started, create an empty Windows game project. Two textures will be needed: one for the Light and one for the Background. After adding these to the Content Project, go ahead and add the following members to the game class.
1 2 3 4 5 6 7 | Texture2D lightTexture; Texture2D backgroundTexture; RenderTarget2D lightTarget; RenderTarget2D mainTarget; Effect basicFogOfWarEffect; |
While the use of the texture fields is obvious, the use of the render targets may not. The concept behind this fog of war implementation is to draw the light texture to the lightTarget render target and then use the produced texture as the alpha channel for the texture produced from the mainTarget render target.
Scott “Gu” (Guthrie) has started a series of posts about VS2010 and (more importantly) .NET 4.0, touting its new features that so far have been incredibly important for developers. It seems that Microsoft is finally “getting it” and listening to us about certain things.
While most of you have already heard about the ability to define Debug and Release web.config files, these two new features may put you over the edge in waiting for .NET 4.0 to release.
Finally Microsoft has realized that while having configuration files that are verbose enough to support wild customizations, most of us do not need to change the default sections in the web.config file. So it should come as no surprise that clean configuration files will now be a thing of the (recent) past. It is just a shame it took so long to get.
Hidden in this post about new project templates and what looks to be the ASP.NET WebForms version of the ASP.NET MVC template is a bit about client ids for controls.
All of the styles and content within the site are configured using CSS, and take advantage of some of the new features with Web Forms in ASP.NET 4 – including clean client-side “id” names (no more ctrl_ mangled names – ASP.NET 4 gives you complete control over the client id), and CSS based rendering instead of table based rendering for the built-in server controls.
This, again, should come as no surprise as the mangled names can present problems for developers looking to write some quick javascript as well as those looking to simply clean up their HTML. Here’s to hoping that Microsoft cleans up its HTML in other places as well (SharePoint anyone?).
Tackling the problem in the previous post I have decided to rely on providing more options than necessary. I have to remember that because Vodka is not client software, I have to write it as if the client software will be as simple as possible. The goal of Vodka is to give developers a way of setting up a software based CMS with great ease.
To do this, I have built in services that can be implemented and exposed via WCF as well as built in implementations of these services. If you had the binaries for Vodka, you could reference FocusedGames.Vodka.Services, create a class in a Service project and inherit from ContentService or MembershipService. After deploying the project, you can treat it like any other WCF service reference.
The original question dealt with translation services however, is it a client or server responsibility? You would generally make it client side because you may wish to get a different template for the content or change how translation is done. This is on par with most CMS software installs out there but there is a problem. Templates in the Vodka backend are treated as standard items of content. It then would require two calls to the service: one for the template and one for the content. You would also have to know how the template is extracted from the content item. This is a bad idea as it increases server load unecessarily.
The answer is simple: abstract it and keep it server side. The idea here is that the developers can plugin their own template provider into the service when setting it up. This will allow them to point to another service, a local directory or hardcoded templates. If no plugin is used, the service will continue on its standard course, grabbing the template from the standard content data store.
You may be asking why you would ever want to use a custom provider to point to a second service. Let’s say you have a ton of websites that you all want to look the same. For instance Microsoft may have microsoft.com, msdn.microsoft.com, creators.xna.com, xbox.com, et cetera and may want them to all use the same templates for items. They could use a provider to point to a single template service removing the need to change 5+ templates on 5+ servers.
This is a fundamental topic in C# and if you plan to do any development at all with the language you need to know this. Override is used for changing the behavior of the original type’s method or property. The new keyword, in this case, is used for scratching the existing behavior but only in the current type. To better explain this, consider the following code.
1 2 3 4 5 6 7 8 9 10 11 | public class Foo{ public virtual void Print(){ Console.WriteLine("I am a Foo!"); } } public class Bar : Foo{ public override void Print(){ Console.WriteLine("I am a Bar!"); } } |
If we declare a Bar and cast it to a Foo in the above code, we will still get “I am a Bar!” when we invoke the Print method. However, if we change the code to the following things will get messed up a bit.
1 2 3 4 5 6 7 8 9 10 11 | public class Foo{ public void Print(){ Console.WriteLine("I am a Foo!"); } } public class Bar : Foo{ public new void Print(){ Console.WriteLine("I am a Bar!"); } } |
If we instantiate a Bar, we will get the new functionality. However, if we cast that Bar object into a Foo, we will get the implementation provided by the Foo. So be sure of what you are using and why!
The provider model’s goal is to allow for the abstraction of implementation to the nth degree by allowing for the choice between separate implementations of the same functionality. This design pattern is incredibly common in Microsoft’s ASP.NET, especially in the realm of security. Developers can choose between different providers for membership, roles and authentication for a single site. The point is that the core functionality of the site does not change, only the implementation. Below is a quick snapshot of how such a model is used in Vodka.
The driving force behind the provider model is the abstraction of the implementation. This is done via an interface.
1 2 3 | public interface IAuthenticationProvider{ bool Authenticate(string username, string password); } |
What gives the provider model its meat and bones is the different implementations of the above interface. The two implementations below represent two authentication backends: an ActiveDirectory installation and an Sql database. Although the meat has been stripped from these two classes, it is clear that their implementations would differ enough to have the two separate classes. Read the rest of this entry »
I was pushing Galactic Defense to the Zune today to do some minor version testing (I develop on the PC and then push to Zune for platform specific tests) and ran into some major problems. The GC was collecting about once an update which was slowing the game down tremendously. So I dug in and started searching my code.
One of the best ways to figure out where you are creating garbage (when no tool can do it for you) is just to start commenting things out. For starters, I commented out the draw code for my map. This worked, but not enough. I ended up adding a line that removed the InputManager from the component collection (effectively commenting out its update code) and I had it: 0 allocations per update.
So I looked at the draw code again and realized (with the help from guys in #xna) that I was using an enumeration in a Dictionary. A big no no since the framework allocates every time you do a lookup. A quick switch to ints (cast all lookups to integers) fixed that problem. Now onto the InputManager.
To make a long story short, I followed the trail and cornered this line of code:
1 | if(!repeatKeys.Contains(button)) |
It is this line of code that actively makes sure that I have all the buttons in the repeatKey list so I can check and update the repeated keys later on. I removed this line of code and added the following:
1 2 3 4 5 6 7 8 9 10 11 12 | bool found = false; for (int i = 0; i < repeatKeys.Count; i++) { if (repeatKeys[i] == button) { found = true; break; } } if (!found) repeatKeys.Add(button); |
And now I am back to a normal amount of allocations (some for strings) per update. I wonder why Contains is causing an allocation. I am too lazy to figure that one out right now…
With the arrival of .NET 3.5 and consequently WPF applications, Microsoft has done away with the old Application WinForms class. No longer can you call Application.LocalUserAppDataPath to get where the user’s files are stored. To restore this functionality as well as add a bit more, I have tapped into an uncommon resource: extension methods. Let’s dig a little deeper, shall we?
In this fourth [page, second post] installment of the MGS: Pong article series, I am going to cover how to draw a background for the game. Before I start, I should tell you that there will be two more articles: one for creating the menu system and one for pulling all the classes together. Okay, let’s begin! The background class (Background.cs) is incredibly easy to create. First we need some private members to draw the background.