Managing Focus Across Different Platforms

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

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.

Problems With Vodka

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.

Screenshot of the Day

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.

Senior Project

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?

The FGF Solution…

Here is a quick screen cap of FGF opened in Visual Studio 2008. Got to love all the projects, right?