It is important to note that we identify, generalize and abstract key functionality from each specific implementation to a specification (an interface in C#) to guarantee the plug-and-play architecture. Consider a site that has one or more backend storage devices for user credentials. We want to iterate through them when a user attempts to login but hardcoding them creates a strong dependency on their specific implementations. This can cause maintenance issues later on as one or more devices are added or removed. To keep the site agile, we can use the provider model to abstract the credential verification process. Consider the following provider specification.

1
2
3

public interface IAuthenticationProvider{
    bool CheckCredentials(string username, string password);
}

We can then implement this in many different ways, utilizing an SQL database, an Active Directory server or even a simple text check.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class SqlAuthenticationProvider : IAuthenticationProvider{
    public bool CheckCredentials(string username, string password){
        if(!IsValid(username, password)) return false;
 
        // Run some SQL statement - set result to a bool
        bool result = false;
 
        return result;
    }
}
 
public class TextAuthenticationProvider : IAuthenticationProvider{
    public bool CheckCredentials(string username, string password){
        return (username == "root" && password == "hello");
    }
}

The beauty of this pattern is that as business requirements or APIs change, the core code of your application can remain unchanged. Instead you can update a configuration file, removing the need for recompilation and possibly a full test.

1
2
3
4
5
6
7
8
9
10

public class LoginPage : Page{
    protected void Submit_Click(object sender, EventArgs e){
        foreach(IAuthenticationProvider provider in Configuration.AuthenticationProviders){
            if(provider.CheckCredentials(txtUsername.Text, txtPassword.Text)){
                // set some session variables or a cookie
                Response.Redirect("UserProfile.aspx");
            }
        }
    }
}

I can hear you asking how this applies to game development and specifically the XNA universe. If you take a closer look at the XNA Framework you will find that this pattern is frequently used because of how flexible it is. For instance, any instance of DrawableGameComponent or GameComponent is a provider that implements some base interfaces. Similarly, any component you add to the services collection acts as a provider for anyone that consumes it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

namespace Microsoft.Xna.Framework{
    public interface IGameComponent{
        void Initialize();
    }
 
    public interface IDrawable{
        event EventHandler DrawOrderChanged;
        event EventHandler VisibleChanged;
        void Draw(GameTime gameTime);
        int DrawOrder { get; }
        bool Visible { get; }
    }
 
    public interface IUpdateable{
        event EventHandler EnabledChanged;
        event EventHandler UpdateOrderChanged;
        void Update(GameTime gameTime);
        bool Enabled { get; }
        int UpdateOrder { get; }
    }
}

The above specifications are then implemented by child classes that you have probably run into and used before. Mainly GameComponent implements IUpdateable and IGameComponent while DrawableGameComponent inherits the former and implements the IDrawable interface. We can say here that the component classes provide functionality to the Game class through the IGameComponent, IUpdateable, and IDrawable interfaces.

1
2
3
4
5
6
7
8
9

namespace Microsoft.Xna.Framework{
    public class GameComponent : IGameComponent, IUpdateable, IDisposable{
        // ...
    }
 
    public class DrawableGameComponent : GameComponent, IDrawable{
        // ...
    }
}

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.

The next step is an obvious one: add the first project. The design of FGF is based on a hierarchy of libraries much like the .NET Framework. Whereas libraries depend on the System DLL and mscorlib, FGF libraries can all depend on the core project, FocusedGames. To enable some cross-platform awesomeness down the road, we make this project an XNA library and then remove the references to the XNA Framework. Remember that FGF is not just an XNA framework and should support situations where XNA is not installed. You can see the cleaned project in the below screenshot.

After creating some copy projects for the Zune and the Xbox 360, repeat the process for a new project, FocusedGames.Xna. At this point you may find it nice to move the platform specific projects into platform specific Solution Folders. This is one of the features of Visual Studio I wish was present in the Express Edition, but unfortunately it was left out. The really nice part of Solution Folders is that it does not physically move the project files. Rather it simply organizes them in a virtual fashion.

Regardless, the last step is to setup the output directory. Personally, I like having the projects all push to the same bin folder so I can copy them with a Powershell script very easily. To do this, go into each project’s properties and change the output directory to something like “..\Bin\whatever was here>” and remember to change it for both Debug and Release.

Finally we are ready to start coding!

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.

The next task is to load up the textures and create the render targets. Note: If you have issues with the render targets, you may have to change the create statement for your GPU. A better render target creation method will be added to this article at a later date.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

protected override void LoadContent()
{
    // Create a new SpriteBatch, which can be used to draw textures.
    spriteBatch = new SpriteBatch(GraphicsDevice);
 
    lightTexture = Content.Load<Texture2D>("Light");
    backgroundTexture = Content.Load<Texture2D>("Background");
    basicFogOfWarEffect = Content.Load<Effect>("Effects/BasicFogOfWar");
 
    mainTarget = CreateRenderTarget();
    lightTarget = CreateRenderTarget();
 
    base.LoadContent();
}
 
private RenderTarget2D CreateRenderTarget()
{
    return new RenderTarget2D(GraphicsDevice, GraphicsDevice.PresentationParameters.BackBufferWidth, GraphicsDevice.PresentationParameters.BackBufferHeight, 1, SurfaceFormat.Color);
}

Finally the drawing can begin. The process is incredibly simple and straight forward: draw the game, draw the lights, combine the two and draw to the screen. First the "game" is drawn to the mainTarget render target.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

private void DrawMain(GameTime gameTime)
{
    GraphicsDevice.SetRenderTarget(0, mainTarget);
    GraphicsDevice.Clear(Color.Black);
 
    // Draw the background
    spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState);
    spriteBatch.Draw(
        backgroundTexture,
        new Rectangle(0, 0, GraphicsDevice.PresentationParameters.BackBufferWidth, GraphicsDevice.PresentationParameters.BackBufferHeight),
        Color.White
    );
    spriteBatch.End();
 
    base.Draw(gameTime);
 
    GraphicsDevice.SetRenderTarget(0, null);
}

Step two is to draw the lights. For now drawing based on where the mouse will do nicely for a test.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

private void DrawLights(GameTime gameTime)
{
    GraphicsDevice.SetRenderTarget(0, lightTarget);
    GraphicsDevice.Clear(Color.Black);
 
    MouseState mouseState = Mouse.GetState();
 
    spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState);
    spriteBatch.Draw(
        lightTexture,
        new Vector2(mouseState.X, mouseState.Y),
        null,
        Color.White,
        0f,
        new Vector2(16, 16),
        Vector2.One * 16,
        SpriteEffects.None,
        1.0f
    );
    spriteBatch.End();
 
    GraphicsDevice.SetRenderTarget(0, null);
}

And finally these methods are put together and the final is drawn with the effect.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

protected override void Draw(GameTime gameTime)
{
    DrawMain(gameTime);
 
    DrawLights(gameTime);
 
    GraphicsDevice.Clear(Color.Black);
 
    Texture2D mainTex = mainTarget.GetTexture();
    Texture2D lightTex = lightTarget.GetTexture();
 
    basicFogOfWarEffect.Parameters["LightsTexture"].SetValue(lightTex);
 
    spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState);
 
    basicFogOfWarEffect.Begin();
    basicFogOfWarEffect.CurrentTechnique.Passes[0].Begin();
 
    spriteBatch.Draw(
        mainTex,
        new Rectangle(0, 0, GraphicsDevice.PresentationParameters.BackBufferWidth, GraphicsDevice.PresentationParameters.BackBufferHeight),
        Color.White
    );
    spriteBatch.End();
 
    basicFogOfWarEffect.CurrentTechnique.Passes[0].End();
    basicFogOfWarEffect.End();
}

The effect itself is incredibly simple. Combine the two textures but use a channel from the “light” texture as the alpha for the color (screen facing) texture.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

texture LightsTexture;
 
sampler  ColorSampler  : register(s0);
 
sampler LightsSampler = sampler_state{
	Texture = <LightsTexture>;
};
 
struct VertexShaderOutput
{
    float4 Position : POSITION0;
    float2 TexCoord : TEXCOORD0;
};
 
float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0
{
	float2 tex = input.TexCoord;
 
    float4 color = tex2D(ColorSampler, tex);
    float4 alpha = tex2D(LightsSampler, tex);
 
    return float4(color.r, color.g, color.b, alpha.r);
}
 
technique Technique1
{
    pass Pass1
    {
        PixelShader = compile ps_2_0 PixelShaderFunction();
    }
}

Download: Fog Of War Sample (278)

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.

• Clean Web.Config Files

  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.

• Control over Client Ids

  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?).

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.

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 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.

1
2
3
4
5
6
7
8
9
10
11
12
13

public class ActiveDirectoryAuthenticationProvider : IAuthenticationProvider{
	public bool Authenticate(string username, string password){
		// Attempt to log user into AD.
		return authTest;
	}
}
 
public class SqlAuthenticationProvider : IAuthenticationProvider{
	public bool Authenticate(string username, string password){
		// Validate credentials against the Sql DB.
		return authTest;
	}
}

Now that the implementation is abstracted from the functionality requirements, the provider model requires only a driver to use differing implementations. Below is a sample driver that simply uses each provider to authenticate a user. It is important to note that there is no code to be changed based on what backend (provider) is being used due to the use of the common interface.

1
2
3
4
5
6
7
8
9
10
11

public class Driver {
	public Driver(IAuthenticationProvider provider){
		if(provider.Authenticate(“jsedlak”, “hello”))
			Console.WriteLine(“You are authenticated!”);
	}
 
	public static void Main(){
		Driver d1 = new Driver(new SqlAuthenticationProvider());
		Driver d2 = new Driver(new ActiveDirectoryAuthenticationProvider());
	}
}

The above example is a simplified version of the provider models used in Vodka where Membership, Authentication and Roles have all been squeezed into one provider. The reason for this is to remove an unnecessary code complexity requirement of three different security providers. More often than not, the three are commonly found together in the backend anyways.

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…

Note: You should not rely on this for accessing local data stores. Microsoft has done away with this method for a reason and relying on it in the future can cause problems.

The first thing we need to do is be able to get the Company Name from the assembly. Inside of a blank static class, add the following functions. I have named my class ApplicationExtensions.

Fortunately the company name is kept in an attribute:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public static string GetCompanyName(this Assembly assembly)
{
    string name = string.Empty;
 
    object[] attributes = assembly.GetCustomAttributes(typeof(AssemblyCompanyAttribute), true);
 
    if (attributes != null && attributes.Length > 0)
    {
        AssemblyCompanyAttribute aca = attributes[0] as AssemblyCompanyAttribute;
 
        if (aca != null)
        {
            name = aca.Company;
        }
    }
 
    return name;
}

Note my lack of any formal error handling. I will leave this up to you to handle. For now, returning an empty string will do. Next up, we need to be able to format the version number:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public static string GetFormattedVersion(this Assembly assembly)
{
    string version = string.Empty;
 
    try{
        Version assemblyVersion = assembly.GetName().Version;
 
        version = string.Format("{0}.{1}.{2}.{3}",
            assemblyVersion.Major,
            assemblyVersion.Minor,
            assemblyVersion.Build,
            assemblyVersion.Revision);
    }
    catch{}
 
    return version;
}

And finally, the LocalUserDataPath:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public static string GetLocalUserAppDataPath(this Application application)
{
    string path = string.Empty;
 
    Assembly assembly = Assembly.GetEntryAssembly();
 
    if (assembly != null)
    {
        path = Path.Combine(
            Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
            Path.Combine(
                Path.Combine(
                    assembly.GetCompanyName(),
                    assembly.GetName().Name),
                assembly.GetFormattedVersion()
                )
            );
    }
 
    return path;
}

1
2
3
4
5
6
7
8
9

public class Background : Microsoft.Xna.Framework.DrawableGameComponent
{
    #region Private Members
    private SpriteBatch m_spriteBatch;
    private ContentManager m_conManager;
 
    private Texture2D m_bgTexture;
    private string m_texSource;
    #endregion

The next thing we need to do is handling how to load and unload content. This is nothing new, so no explanation is required.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

#region Constructor
public Background (Game game)
    : base ( game )
{
    // Instantiates a new Content Manager. The CM class
    // is a lightweight object that allows us to load and
    // process XNA content.
    m_conManager = new ContentManager ( game.Services );
}
#endregion
 
#region Load / Unload Content
protected override void LoadGraphicsContent (bool loadAllContent)
{
    base.LoadGraphicsContent ( loadAllContent );
 
    // Load All Content is true when the Device is created
    // or goes through a hard reset. This happens when the
    // window is created and sometimes when moved to 
    // another monitor.
    if ( loadAllContent )
    {
        // Instantiates a new SpriteBatch object.
        m_spriteBatch = new SpriteBatch ( GraphicsDevice );
 
        // Checks if the texture file exists, and if so
        // loads the texture.
        if ( File.Exists ( m_texSource + ".xnb" ) )
            m_bgTexture = m_conManager.Load<Texture2D> ( m_texSource );
    }
}
 
protected override void UnloadGraphicsContent (bool unloadAllContent)
{
    base.UnloadGraphicsContent ( unloadAllContent );
 
    // Much like loadAllContent, the value of unloadAllContent
    // is true when the device is created or goes through a hard
    // reset. This occurs before a LoadGraphicsContent(...) in
    // the latter cases.
    if ( unloadAllContent )
    {
        // Unloads all the data.
        m_conManager.Unload ();
 
        // Dispose of unmanaged memory and
        // set the paddle texture to null
        if ( m_bgTexture != null )
        {
            m_bgTexture.Dispose ();
            m_bgTexture = null;
        }
 
        // Dispose of the spritebatch
        // and set it to null.
        if ( m_spriteBatch != null )
        {
            m_spriteBatch.Dispose ();
            m_spriteBatch = null;
        }
    }
}
#endregion

Next we handle drawing! Again, this is nothing new so I will just let you see the code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#region Drawing
public override void Draw (GameTime gameTime)
{
    base.Draw ( gameTime );
 
    // If the texture doesn't exist, we can't draw!
    if ( m_bgTexture == null )
        return;
 
    // Start drawing.
    m_spriteBatch.Begin ( SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState );
 
    // Draw the paddle.
    m_spriteBatch.Draw ( m_bgTexture, Vector2.Zero, Color.White );
 
    // End drawing.
    m_spriteBatch.End ();
}
#endregion

Finally we have a property so that we can set the texture source from outside of the class. As said before, the next article will cover the menu system.

1
2
3
4
5
6
7
8
9
10

#region Properties
/// <summary>
/// Gets or Sets the source of the paddle's texture.
/// </summary>
public string TextureSource
{
    get { return m_texSource; }
    set { m_texSource = value; }
}
#endregion