As you have probably noticed, the site has been in disarray for quite some time now. The articles and projects have not been updated since Xna 3.0 and some even before that. Rest assured that I am working on a new release of the site and will update the current content in due time.

In the meantime you can stay up-to-date with news related to me and Focused Games over at jsedlak.com.

Thank you,
John Sedlak

As you already know, XNA 3.0 is out and you can now start submitting games to XBLCG for real. Well Nick has made a fantastic post about a feature of the new Xna site. In the post, May The Playtest Be With You, Nick discusses the importance of not clogging the review pipeline with a game that hasn’t been tested by others.

So if you are about to submit a game for review and have not had anyone look at it, be sure to use the playtest feature. If nothing else, give the game to a few friends to try out.

Before people start reporting problems with Thrust v1.1, let me say that version 1.2 is already on its way. I have caught a few bugs in the InputManager that are demanding a quick release. I will also be including some new GUI functionality.

In the meantime, catch up on the tutorials and samples about using the Focused Games Framework.

I have put up a new version of the Focused Games Framework for download. This release includes Thrust v1.1 and Vodka Alpha files. I have also released X86 and X64 installers for Folder Kill. Below is a more complete list of the changes made.

Thrust

• Created Content Pipeline Project
• Terrain Content
• Cleaned some StateObject & Menu code
• Added repeat states for GamePad
• Added Xbox 360 projects
• Added Camera components
• Added Console component
• Diagnostics
  • Added Stats component
  • Added Thumbstick Throttle Component

Vodka

• Created core Vodka project
• Added core interfaces
• Implemented a few providers
• Added Services project.

Finally, I urge you to keep an eye on FGDN as I continue to add to it over the next couple of months.

Ziggy of Ziggyware, as many of you know, has been hit really badly by the latest hurricanes and storms. Please consider taking the time to donate a few bucks to help keep his site and contests alive. If you do not care for donating, perhaps now would be a good time to buy an XNA book from Amazon through his site’s many book links. You can read more on his website.

For a little while now I have been working with James Silva on a book, Building Xna 2.0 Games. The book is an incredibly fast paced guide to developing a game like The Dishwasher as the artist, sound engineer, programmer, tester, designer and much more. We cover topics like HLSL effects, particle systems, network programming, tool creation and scripting. Also covered are non-programming topics like creating some custom sounds, generating characters and how to make sure that you do not fail by keeping checks on your goals and designs.

So if you want to help us out and learn lots in the process, buy the book!

Implemented the start of color maps today…

Just a note that I haven’t forgotten about my goal to publish my applications for X86 and X64. Here is a screenshot of the latest build of Key Manager. I am rebuilding it in WPF and will support importing keys from the old version.

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?

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;
}

One of the principals learned from designing my own Content Management Systems over the year was that deploying a CMS with a built in set of functionality is fine, but takes way too much work due to how different common functionality is. For instance, a forum is programmed quite differently from a poll or survey. In the last CMS I developed (FGCMS 2.0), I attempted to crack this problem by utilizing a hierarchial structure which could automatically be loaded from a database. What this mean was that I could extend a base class with new properties and functionality and store the new data in a new table. While this was wonderful from an extendability point of view, it was absolutely horrid from a consumer’s view.

Instead of having to program individual features, I had to program individual pages, static pages. This, of course, isn’t good because with every change to a class definition came a change to every associated page. The upkeep on this is terrible and what ended up happening was that I never got to implementing the pages for much of the backend functionality.

With Vodka, I am taking a step back and attempting to understand the problem from multiple perspectives. On one hand, XML based content is amazing for developing websites because XSL sheets can transform each piece of content into HTML without the need for static pages. On the other hand, having tangible .NET objects is priceless when it comes to code readability. Let’s face it, operating on XmlNode objects is not a fun procedure and is definately not maintainable. Furthermore, from a security stand point, I want to implement item live (and up) security that is customizable to the n^th degree. While this may not be possible, it will be possible for most common uses. This desire comes from working with SharePoint, where security is powerful, but hard to use. It is hard because there are only a predefined set of roles for each item and it isn’t easy to understand security in a grander scheme. You can’t grab a look at what rules are overriding others.

Here you can see that Vodka employs the very common three tier approach. The separation of data from logic from UI applications is clearcut. The reasons are fairly simple too:

• Simple to maintain
• Plug and Play behavior
• Common backend accross all applications
• Data format independency

But there is more to this than meets the eye. As shown above, the Business layer contains two sub layers: Simple Objects and Complex Objects. The goal of these is to provide a common ground of functionality with a split view of the data. On one side, the Simple Objects layer provides the Consumer layer with Xml based data. This makes developing websites, RSS feeds, and more incredibly simple. The other side is Complex Objects, which takes what I have learned from FGCMS 2.0 and bumps it up a notch. The core idea with the Complex Objects is that developers will want to and need to use tangible .NET objects with properties and methods. This fills that gap.

So how does this all work? Two words: Provider Model.

For now, let’s consider an implementation without security. The goal then is to represent data somewhere in memory, and be able to translate this data into other forms. Mainly the two forms in Vodka are Xml strings and .NET objects. Because data will be stored as an Xml string with attached metadata, it makes sense that the Simple Objects provider will always be a necessary step. The data provider model, then, takes data from some sort of memory (SQL Server, etc.) and translates it into a .NET object with metadata and an Xml string. A second step takes this object, and translates it into a Complex Object with properties, methods, et cetera.

The great thing about the provider model, of course, is that each provider is fully customizable. You are free to use built in providers or develop new ones as new needs/technologies arise. I plan to implement at least an SQL and Xml File Data Provider as well as a simple Xml deserializer / serializer Translation Provider for the first true release of Vodka.