One of the major themes present in the design of FGF is abstraction of functionality from its implementation. The major reason for this is because one of the major goals of FGF is to provide functionality without forcing developers into a corner. The idea is if the base of the framework is modular and open, the rest of the framework will fall into place very easily. So I begin the implementation of FGF by fixingimproving the XNA Framework’s Game class with an abstraction of its functionality. The reason for which will become apparent when the component classes are improved at a later time.

The important question to ask here is what can a game do? We can run a game, and exit a game but also add and remove components and services. Thus the IGame interface is born (within the FocusedGames.Xna project):

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

using Microsoft.Xna.Framework;
 
namespace FocusedGames.Xna
{
    public interface IGame
    {
        void Run();
        void Exit();
 
        Vector2 ObjectToScreen(Vector2 objectVector);
        Vector2 ScreenToObject(Vector2 screenVector);
 
        GraphicsDeviceManager DeviceManager { get; }
 
        DisplayOrientation DisplayOrientation { get; set; }
        Vector2 DisplaySize { get; set; }
 
        bool IsLoaded { get; }
 
        float TargetFrameRate { get; set; }
 
        ModuleCollection Modules { get; }
    }
}

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

Beware that when you call TouchPanel.GetState twice within the game loop, what touch locations had a Pressed state the first time will have a Moved state the second time. Consider the following lines of code.

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

TouchCollection touches = TouchPanel.GetState();
 
foreach (TouchLocation locale in touches)
{
    if (locale.State == TouchLocationState.Released && locale.Id == id1)
        id1 = -1;
    else if (locale.State == TouchLocationState.Pressed && id1 == -1)
        id1 = locale.Id;
    else if (locale.Id == id1)
        pos1 = locale.Position;
}
 
touches = TouchPanel.GetState();
 
foreach (TouchLocation locale in touches)
{
    // Can fail if the first time through it was Pressed.
    if (locale.Id == id1 && locale.State == TouchLocationState.Pressed)
    {
        // Do something important
    }
}

Note that it isn’t important that these are in the same file let alone the same method. You cannot rely on having access to the same state data everytime you call GetState within the game’s loop. So it will probably become important to put the touch code in a global location and store the states for the duration of the loop. For instance you can store the TouchCollection data in a static variable at the top of the Game’s Update method.

Rather than writing an actual letter, which would do no good, I have chosen to write this post with the idea that as an MVP I should lead and teach by example. One of the most important design principles that factor into designing a framework is that of dependency hierarchies. In less fancy terms it simply means what classes implement what interfaces and where these things are maintained in the framework. Recently I placed a suggestion on Connect to Move INotifyCollectionChanged to System.dll so that more projects that do not require WindowsBase.dll (WPF) could use the functionality. Fortunately for .NET developers everywhere the suggestion was taken (although I won’t claim sole responsibility) and the move is happening.

This post is about the reasons for such a move, and such reasons are incredibly basic to realize. Consider a platform other than Windows whether it be Linux, Windows Mobile, the Xbox 360 or even the Zune HD. Now think about how you would write a framework that supports some of (or all) these platforms and consider the problem of developing a class that implements something like INotifyCollectionChanged. The problem, of course, is that not all the platforms have access to WindowsBase.dll. Thus the developers come to a crossroads: either recreate the functionality for the platforms or don’t implement the functionality.

While that may not seem too unreasonable a dilemma, the problem is that Microsoft implemented functionality in a branched assembly that really has no dependency on any classes or interfaces within that assembly. Here the principle is simple: when possible, move functionality up the assembly hierarchy so as to reduce cross dependencies. In layman’s terms, by moving the INotifyCollectionChanged interface to System.dll, many more projects can take advantage of it without requiring any sort of platform dependent code. And here it is important to remember that one of the original goals of .NET was to enable true cross platform development.

To say that this case is the only one of its kind would be ignorant. The scary thing is that I don’t think anyone actually has a list of where these mistakes exist and what can be done about them. Even scarier than that is the fact that Microsoft is making these mistakes. Consider the following which further demonstrates this point.

While helping someone today with a few questions on the System.Reflection namespace, a point was made about how odd it is to compare generic types. When you have a generic class such as Nullable<T> you cannot do something as simple as if(foo is Nullable) because the generic parameter can make a difference. While this isn’t too much of a problem, Microsoft later also developed the System.Data assembly and included an interface called INullable within this assembly under the System.Data.SqlTypes namespace. This, like INotifyCollectionChanged, constricts the use of this interface to only assemblies that reference System.Data.dll. Furthermore, the interface contains a single boolean property and has not a single dependency on anything within the System.data assembly.

The problem and its solution should be obvious: move INullable to the System namespace in System.dll and make Nullable<T> implement it. This allows developers to easily check whether or not a type represents a nullable type while not creating a single problem in the entire framework’s design. Furthermore it would allow developers to treat System.Nullable and System.Data.SqlTypes.* as the same types which can come in handy.

Update: I added a suggestion on Connect for moving INullable to System.dll.

One of the first “games” I made for the Zune HD was a simple little application to test how accurate and quick the touch panel is. This How To gives you the code to get started with your own basic testing application.

After creating a Zune game with XNA 3.1, the first thing you need to do is define a basic particle struct to hold some data that we track as the user touches the screen. Specifically we need to track whether or not a particle is active (do we update it and draw it?), its position and its life (how long it has been there). I created this structure within the Game1 class but really it can go anywhere.

Read the rest of this entry »

After developing with the Sitecore CMS for a couple of months I have seen what XSLT can offer in terms of a powerful web technology. I decided early on, before using Sitecore, that Vodka 2.0 would have to support XSL transforms since the content is stored as XML. The following is a sample of how to work with XML and XSLT in the second version of the Focused Games Framework (FGF 2.0).

While the XSLT code can go pretty much anywhere in the ASP.NET pipeline, for now I have put it in my main Controller. Note that this code is not final, I will be looking into a better way to streamline the content retrieval process.

1
2
3
4
5
6

public class ContentController : Controller
{
    public ActionResult Get(string uri)
    {
        Content content = GetContent(uri, -1);
        Content template = GetContent(content.TemplateId, -1);

Next the XslTransformer class is instantiated and a test extension is added. Extensions can be simple or complext .NET classes. Again I plan to streamline this process and support loading from the web.config file.

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

        XslTransformer transformer = new XslTransformer(GetDocument);
        transformer.AddExtension(
            new XsltExtension
            {
                Namespace = "http://focusedgames.com/vodka",
                Provider = new VodkaXslExtensions()
            }
        );
 
        ViewData["Content"] = transformer.Transform(uri, template.Meta.Uri);
 
        return View("Get", "~/Themes/FGDN/Theme.master");
    }

When the Transform method is invoked, the transformer attempts to load documents through a callback. This process will definitely be streamlined so that the re-implementation of the following method isn’t required. The callback method loads the content straight from the database through an SqlContentProvider object. Not much has really changed here since Vodka 1.0 except for the addition of support for both languages and versioning.

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

    public Content GetContent(string uri, int parent)
    {
        SqlContentProvider scp = new SqlContentProvider();
 
        NameValueCollection parameters = new NameValueCollection();
        parameters.Add(SqlContentProvider.ConnectionStringParameterName, connectionString);
 
        scp.Initialize(parameters);
 
        Content content = scp.GetContent(uri.ToLower());
 
        return content;
    }
 
    private XPathDocument GetDocument(Uri uri)
    {
        Content content = GetContent(uri.OriginalString, -1);
 
        XPathDocument document = new XPathDocument(new StringReader(content.Xml));
 
        return document;
    }
}

And finally the simple extension object:

1
2
3
4
5
6
7

public class VodkaXslExtensions
{
    public string GetDate()
    {
        return DateTime.Now.ToString();
    }
}

So what does this produce exactly? Well it takes the following XML…

1
2
3
4
5
6
7
8
9

<?xml version="1.0"?>
<content>
    <title>Home</title>
    <description>
        <p>This website is still under construction, please check back soon.</p>
        <p>Thank you,</p>
        <p><a href="http://jsedlak.com">John Sedlak</a></p>
    </description>
</content>

And uses the following XSLT file (stored in the Vodka Database)…

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

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:test="http://focusedgames.com/vodka" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl test"
>
    <xsl:output method="xml" indent="yes"/>
 
    <xsl:template match="@* | node()">
      <h2>
        <xsl:value-of select="title"/>
      </h2>
        <div class="Description">
            <xsl:value-of select="description"/>
        </div>
        <p><xsl:value-of select="test:GetDate()"/></p>
    </xsl:template>
</xsl:stylesheet>

And produces the following HTML…

1
2
3

<h2>Home</h2> 
<div class="Description">This website is still under construction, please check back soon.Thank you,John Sedlak</div> 
<p>9/21/2009 5:23:04 PM</p>

One of the requirements of the framework I am building (FGF) is cross platform support. For my XNA games this means support for not only Windows but also the Zune and the Xbox 360. For my Windows based projects I often find that X64 can be used (and in the case of IIS in 2008 R2, encouraged) so I also support X64 versions.

The problem is that when using an XNA project template to build a library for the simple fact that XNA projects can automatically synchronized (across platforms), Visual Studio blocks the creation of an X64 build target. Rather you are stuck with X86, Zune or Xbox 360.

The good news is that you can get around this! Open up the Windows project file (csproj) in a suitable text editor and copy the sections for both “Debug|x86″ and “Release|x86″ and paste them right after.

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

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>..\Bin\x86\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x86</PlatformTarget>
  <XnaCompressContent>false</XnaCompressContent>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>..\Bin\x86\Release\</OutputPath>
  <DefineConstants>TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x86</PlatformTarget>
  <XnaCompressContent>true</XnaCompressContent>
</PropertyGroup>

Next you simply replace the instances of x86 with x64 and change anything else you need.

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

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>..\Bin\x64\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x64</PlatformTarget>
  <XnaCompressContent>false</XnaCompressContent>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>..\Bin\x64\Release\</OutputPath>
  <DefineConstants>TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x64</PlatformTarget>
  <XnaCompressContent>true</XnaCompressContent>
</PropertyGroup>

One warning – this should only be used for projects that don’t require references to the XNA framework. At this time Microsoft has no support for x64 XNA references.

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.

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

Pro-tip for today: When attempting to create a website (I am using ASP.NET MVC 1.0) with IIS7 that allows anonymous users under an Active Directory domain it is imperative that you remember to give anonymous users read rights to the web directory on the system’s physical file system. Otherwise you could end up with pages that do not load the CSS correctly.

Furthermore, if you are running into assembly load problems when running on Windows Server 2008 R2 remember that everything is running in X64 and that you need to enable 32-bit compatibility in your Application Pools. To do this select the App Pool and click “Advanced Settings” and set “Enable 32-Bit Applications” to true.