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 »

One of the major design decisions for Vodka 2.0 has been how to handle the installation of all the software necessary to run a site. At first I favored a desktop application based install since it would allow me to write in normal .NET code without any problems or hurdles that the web presents. The problem with this idea is that a desktop based install isn’t feasible for most people, certainly not for those on shared hosting.

A client application based installation is what I call an Exploding Installation because it takes a package and pushes files out of it onto the file system. Thus it is exploding itself onto the computer. This works really well for most cases, especially basic software installs like games, office applications, et cetera.

Where such an explosion doesn’t work well is for web based installations, which is where Vodka 2.0 is headed (see screenshot below). This is due to the fact that in most cases the average user isn’t able to set up the server in a way to make it work, or doesn’t want to. Originally the installation procedure was going to be based on an explosion: the user would upload the files, put in the site information (see screenshot below) and then the installation would unpackage the files necessary to run the site based on the information. This would work very well, except it leaves the original install files at the root directory of the server. Instead of this approach, an Imploding Installation does the trick because it not only erases over the install files themselves (big security bonus), it doesn’t require any work to setup. The goal here is to have the user upload the files, run the install and get to work creating content.

So how is this done? To support an implosion of the software, or rather a rewrite of key points of it the software needs to be modular in such a way that programmatic writes can be done over content areas. In the case of the Vodka install the site’s navigation needs to be rewritten and because it is based on ASP.NET MVC has to handle the shutdown and/or removal of the installation controller and views. Right now this is done by removing a simple text file from the server, although in the future it can be done by changing a portion of the web.config file and/or removing an extra “Install” library from the bin directory.

The best part about the implosion is that it is 100% clean. After an installation is completed, there is no evidence left that it ever took place, and no possible way for a user to rerun the installation.

Here is a nice little PowerShell script I have created for copying my FGF libraries to the projects that use them. I also hot-keyed the PowerShell window which makes distributing new FGF builds really easy.

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

function fgfDist
{
    # An array of platforms that need to be copied
    $platforms = "x86","Xbox 360","Zune"
 
    if($args.count -ne 0){
        $platforms = $args
    }
 
    # An array of destinations for copying
    $destinations = "M:\Code\Games\Galactic Defense\trunk\Libraries\",
                    "M:\Code\AIR\trunk\Libraries\"
 
    $source = "M:\Code\FGF\trunk\Bin\"
    $sourceSuffix = "\Debug"
 
    # Loop through all the destinations and all the platforms
    # For each platform, copy some files.
    foreach($destination in $destinations)
    {
        write-host "Starting copy to"$destination
        foreach($platform in $platforms)
        {
            $tempSource = $source + $platform + $sourceSuffix
            $tempDestination = $destination + $platform
 
            # Test if the folder exists
            if( Test-Path $tempSource ){
                if( !(Test-Path $tempDestination) ){
                    write-host "Creating directory."
                    new-item -path $destination -name $platform -type directory
                }
            }
            else{
                write-host "Could not find the source files for"$platform
                continue
            }
 
            # Get a list of DLL files that contains thrust as well as the FocusedGames.dll file.
            $thrustLibs = get-childItem $tempSource -force | ? {$_.extension -eq ".dll"}|where {$_.name -match "Thrust"}
            $coreLibs = get-childItem $tempSource -force | ? {$_.extension -eq ".dll"}|where {$_.name -match "FocusedGames\.dll"}
 
            if($thrustLibs){
                foreach($dll in $thrustLibs){
                    if( $dll -ne ""){
                        copy-item $tempSource\$dll $tempDestination
                        write-host "  Copied"$platform\$dll
                    }
                }
            }
 
            if($coreLibs){
                foreach($dll in $coreLibs){
                    if( $dll -ne ""){
                        copy-item $tempSource\$dll $tempDestination
                        write-host "  Copied"$platform\$dll
                    }
                }
            }
        }
    }
}

With the upcoming release of FGF/Thrust comes the return of a more traditional GUI. One of the most problematic requirements of a large GUI system is the notion of focus. The question remains how do you efficiently determine who has focus and how do you pass focus between controls? On Windows this is incredibly easy because we have the mouse pointer. Focus is changed whenever your mouse acts on a control. What about on the Zune or the Xbox 360 though? On both of these systems their is no mouse (although Thrust supports a virtual mouse).

The answer is to look at what Thrust currently supports. What built in system supports all three systems seamlessly? (~ means some support, X means full support)

The problem is we can’t rely on each individual hardware controller being present and useable. For example we can’t rely on a keyboard being a focusing mechanism on the Xbox 360 because it isn’t a guarantee it exists. Likewise, we cannot rely on the GamePad on the Zune because of the lack of buttons.

To get to the point, the UniversalButton system was meant as a virtualization of the various hardware supported for each platform. It turns GamePad, Mouse, and Keyboard events into simple events like Up, Left, Down, Right, Select and Cancel. Because of this we can rely on it and implement a few more events.

• TabPreviousLocal
• TabNextLocal
• TabPreviousGlobal
• TabNextGlobal

You can consider local tabbing to be much like you would on a Windows form: hitting the tab key (or shift-tab) will move you from one control to another based on some order and only in the context of the global focus point (you never tab to a control in another window). The global tabbing can be considered like an Alt-Tab (or shift-alt-tab) where you can switch between windows.

So how do we implement this? We need a managing class (sorry Bjoern) to produce a bottleneck for the input events. As events are channeled through this class, it massages the data and figures out what to do. For instance if a global tab next event is received it has to switch focus to the next window in the system on the same level as the current window. If it receives a local tab event it will pass a message to the current focal point to tab to the next control.

What does this do for us? For one, it unifies the approach to focusing across all the UI subsystems. This means that a Window/Form implementation will focus in much the same way a simple screen will. Unfortunately it also means a complexity requirement for implementation developers. The age of the simple StateManager class is coming to an end. Elements on the screen now need to have a basic state for animation as well as a state for focus (or lack thereof). While it may still be possible to simply unload an element through the StateManager, the reality is that UI elements will have to do a little more management under the hood. Whether this is exposed to the user / developer is still to be decided.

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.

The Vodka Content Management System is a service based, multitier setup with the clients getting access to all content and member information via services. In turn, the services communicate with each other as well as their respective data stores. One of the goals of designing Vodka is to implement objects in a way that is easily extendable. To accomplish this, all content is managed in terms of the text data (XML) and its meta data (title, author, date stamps, et al).

The problem is how this data is transformed into its two main uses: HTML and .NET Objects. The question is where these transformations take place. In order to transform an XML file into HTML, the code needs access to an XSL file. The problem with this is that it too, is treated as a piece of content. It is regulated in exactly the same way with the same level of security. Thus it can be seen that this service should remain on the server. This is where it currently sits, so what is the problem?

The problem remains that it shouldn’t be a server side operation! That is slow! It requires more implementations than necessary and furthermore it builds a bad dependency on the server for specific implementation.

This is from the most recent build of FGF:

Yes, it is my own implementation of the Aero style of windows done in XNA. What does this mean? Well I have decided that although the simple way of doing a menu system in games is fine for simple situations, I want something more powerful and prettier to look at. Thus I have started working on a new UI library for Thrust that is based on Aero and similar interfaces. I am doing it in a fully customizable but lightweight manner and working on Xbox 360 compatibility.

My senior project involves the study of highly extendible systems for the internet, mainly content management systems/solutions. I am building mine in ASP.NET 3.5 on WS2008, SQL2008 and .NET 3.5 (which includes WCF). The goal is to build a system that has plug-and-play services and is both quick and easy to use. Today I got the very first part of this system up and running and can be reached at jsedlak.homedns.org.

There is a lot of work to be done, but the base code (being built into FGF) is coming along very nicely. Once I can figure out security, the project should simply expand exponentially provided I have the time (ugh!). The two main [sub]projects here are FGDN (Focused Games Developer Network) and a simple CMS similar to that of WordPress, SharePoint, et al. The first is designed to allow users to submit bugs, feature requests, etc. easily much like Microsoft’s Connect. The latter is pretty self explanatory.

Because I am building this all as one interconnected solution, I have also started working on the idea that users that exist in Vodka [may] have access to many other parts of Focused Games. Primarily this means FGDN but also the SVN repositories. A user (you) can apply for access to one or more of the repositories I currently use for my source code. Once you are accepted, you are also connected to any other Vodka service I create. Pretty nifty, eh?