I have taken a quick look at the data gathered by my XBLCG Report Tool and have compiled some of the more basic stats. This is based on 17 reports, 3 of which have incomplete data.

Total Downloads: 100 890
Total Purchases: 9 366

Average Downloads: 5 935
Average Purchases: 551
Average Conversion Rate: 9.28%
Average Cost: 263 MS Points

Total Gross: $25 418.10
Total Net: $17 792.64

Average Gross: $1 495.18
Average Net: $1 046.63

Microsoft
Total Net: $7 625.42
Average Net: $448.55

Thanks to all the creators who submitted reports! As I get more data I will be able to produce better views including the all important price analysis we are all wanting to see.

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.

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.

During the last part of this little article series I mentioned how I used a queue in each state object to allow for continuous transitioning to occur. The reason for this is to allow for complex transitioning to occur. One example for this is a logo screen where it needs to fade in, stay on screen and then fade out again. Rather than relying on managing the states manually, we can add states on to a queue so they occur automatically.

Read the rest of this entry »

There comes a time when simple state management just will not cut it anymore. I found this out while building up the code base for Thrust’s GUI library. As the objects on the screen became more complex, so did their states. This article covers a new way of thinking about an object’s state, a design that has been proven in Thrust (v1.x). The goals of this state system include the following:

Read the rest of this entry »

I was pushing Galactic Defense to the Zune today to do some minor version testing (I develop on the PC and then push to Zune for platform specific tests) and ran into some major problems. The GC was collecting about once an update which was slowing the game down tremendously. So I dug in and started searching my code.

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…

I co-authored a book (Building Xna 2.0 Games) with James Silva. It is totally FTW and you should buy it. It is about creating a game with Microsoft XNA as a one man team. It essentially guides the reader through the process of creating a game similar to James Silva’s award winning Dishwasher.

In this fourth [page, second post] installment of the MGS: Pong article series, I am going to cover how to draw a background for the game. Before I start, I should tell you that there will be two more articles: one for creating the menu system and one for pulling all the classes together. Okay, let’s begin! The background class (Background.cs) is incredibly easy to create. First we need some private members to draw the background.

Read the rest of this entry »

In part one of the mini game article series, I am going to show you how to create a very simple Pong game from scratch. The tools you will need include Photoshop (or any other painting program such as Paint.NET or even MSPaint), Visual C# 2005 Express, and of course the Xna framework.

First we need to create our project, to give us a home base for all of our work. Go ahead and fire up C# Express and create an empty windows project. I am going to call mine MGSPong for lack of any imagination or any better title. Once the project has been created, add a folder called “Content” and then another underneath that called “Textures.” This is where we will store out art, no matter how bad it may be!

Read the rest of this entry »

Hardware Instancing is an interesting topic that has quite a few uses. The idea of instancing is to use the hardware to generate transformed vertices to reduce draw call overhead. Now I know that sounded like a bunch of senseless technical jargon, and it was. In plain English, sometimes it is faster to let the GPU do all the work for us so the CPU can go off and do other work; and this is what Hardware Instancing does. This article covers how to setup a simple program that uses instancing to render a few rotating squares.

Read the rest of this entry »