New to the input engine within the Focused Games Framework is the gesture recognition capabilities, housed in the GestureTracker class. The gesture recognition class currently supports a small subset of the gestures I plan on supporting, but all are useful none-the-less. The included gestures are press, two fingered press, swipe, two fingered swipe, zoom and pinch. To use the gesture recognition, instantiate a GestureTracker object, add it to the IGame.Modules list and then listen to its GestureTracked even. You will also need an instance of the InputManager class added to the list of modules.

The following is a small sample taken from one of my games that handles some simple menu swiping (a full sample is on the way).

If you do happen to use FGF, I would love to hear what you think! Drop me a line via the Contact form or leave a comment here.

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

private void OnGestureTracked(object sender, GestureArgs args)
{
    // If it wasn't a swipe, we don't care!
    if (args.Gesture != Gesture.Swipe) return;
 
    // Get the direction of the swipe to determine what way
    // the menus should move
    if (args.Direction.X < 0)
    {
        // If we are capped at the right side of the menus, return
        if (current == menus.Length - 1) return;
 
        // Transition the menus
        menus[current].Transition(Menu.MoveDir.OffToLeft);
 
        current++;
 
        menus[current].Transition(Menu.MoveDir.OnFromRight);
    }
    else
    {
        if (current == 0) return;
 
        menus[current].Transition(Menu.MoveDir.OffToRight);
 
        current--;
 
        menus[current].Transition(Menu.MoveDir.OnFromLeft);
    }
}

 Download FGF 0.1.2.0 Bin

Read the rest of this entry »

During the last semester I was taking a class on ASP.NET where we formed teams to write a website from scratch. The website was a “project manager” that would help users maintain projects, employees and customers. Given my experience with ASP.NET prior to the class, my team hit the ground in a full on sprint. We hit a wall when it came time to bind the site’s controls to the data behind it, in this case a Microsoft SQL database. The problems weren’t associated with a lack of knowledge but rather the gross disconnect between interfaces and the data with which they associate. It is easy to think that a textbox on a page can represent a name, but how that name is actually filled in can be the most complicated process.

This is just one instance of running into issues with data. How many times have you used a converter of some sort to scrub data or used a validator to make sure it can be stored? How many times have you written the same try-catch block for the SqlConnection class? How many times have you written a statement with “XmlDocument” or an instance somewhere in the middle? I have come to realize that there within the .NET Framework, there are many classes to get all the work done, but they aren’t really put together in a unified way. When you look at all the data-oriented classes (e.g. System.Xml.*, System.Data.*) you will find that there is no grand picture. For some reason the framework architects didn’t take a step back and see a possibility to unify the approach to reaching, converting, validating and consuming data.

So what is DMS? In short, the Data Management System prototype is a look into how possible it is to unify the approach to using data and whether or not it can make a developer’s life easier. The first step is to consider open architectures that are highly extensible and configurable. The current version of the DMS Prototype is focusing on just that by experimenting with converting runtime objects to and from XML. The important part isn’t the conversion; XML serialization has been done to death before. The important part to take away is that the serialization is being done in an abstracted manner. It is trying to gain as much information as possible from as little information as possible. The fewer attributes a developer has to use and the more generic they are, the easier life will be.

Read the rest of this entry »

As you no doubt saw in the writing of the Application class, FGF implements its own version of the XNA Framework’s component classes. The first major reason for doing so is that the builtin component classes require you to pass in a (Framework) Game object through the constructor. While this dependency can be circumvented by implementing the interfaces directly and supplying a manual workaround, the attempt is exactly that: a workaround. The second major reason for my implementation is that by controlling the interfaces and base classes, I can easily support more advanced situations such as the separation between initialization and content loading/unloading. You will see more of this later on when I modify the classes to support asynchronous content loading.

For now, the focus is being put on building a robust base for developers to start working with my framework. Because the goal is to fix the XNA Framework’s implementation, we begin with a simplification of the IGameComponent, IUpdateable and IDrawable interfaces. We combine these three into a single, multi-purpose interface, IModule.

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

public interface IModule
{
    event EventHandler DrawOrderChanged;
    event EventHandler UpdateOrderChanged;
 
    void Initialize(IGame game);
 
    void Draw(GameTime gameTime);
    void Update(GameTime gameTime);
 
    int DrawOrder { get; }
    int UpdateOrder { get; }
 
    bool IsVisible { get; set; }
    bool IsEnabled { get; set; }
    bool IsInitialized { get; set; }
 
    IModule Parent { get; set; }
    ModuleCollection Modules { get; }
}

Read the rest of this entry »

For most purposes, the builtin collection classes supplied by the .NET Framework are terrific. They are simple and straight forward implementations that do exactly as you expect. But for our purposes, a collection class that fires events when the collection is changed is simply better and in some cases, necessary. For this class, we make the jump over to the FocusedGames.Collections namespace, maintained in the FocusedGames library.

Before writing the collection class itself, we need a delegate that can define how our events will work. Enter the CollectionChangedHandler delegate.

1

public delegate void CollectionChangedHandler(object sender, CollectionChangedEventArgs args);

As you can see, we need to define the CollectionChangedEventArgs class itself. This is a simple class that has two properties. The two properties help listeners of the events to understand how the collection was changed.

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

public class CollectionChangedEventArgs : EventArgs
{
    public CollectionChangedEventArgs()
    {
    }
 
    public CollectionChangedEventArgs(object item)
    {
        Item = item;
    }
 
    public CollectionChangedEventArgs(object item, int index)
        : this(item)
    {
        Index = index;
    }
 
    public object Item { get; set; }
    public int Index { get; set; }
}

Read the rest of this entry »

One piece of functionality I consistently find myself writing and rewriting is the implementation of the INotifyPropertyChanged interface. This class, located in the main FGF library, makes that rewriting unnecessary by implementing it in an open way.

1
2
3
4
5

public class NotifyPropertyChangedBase : INotifyPropertyChanged
{
    private bool isDirty = false;
 
    public event PropertyChangedEventHandler PropertyChanged;

Read the rest of this entry »

After you’ve read about the Display Orientation features of FGF, a natural question to ask is “How do I draw and take input with a rotated display?” Fortunately FGF has some methods to help in this department that sit alongside the rotation methods and properties in the Application class.

Application.OrientedDisplaySize

If you need to draw something relative to the size of the screen, use the OrientedDisplaySize property of the Application class. This property differs from DisplaySize, which is used to change the actual size of the display, in that OrientatedDisplaySize reacts to the selected rotation of the display, set with the DisplayOrientation property.

1
2
3
4

DisplaySize = new Vector2(272, 480);
DisplayOrientation = DisplayOrientation.Rotated;
 
Console.WriteLine(OrientedDisplaySize.ToString());

Because the display is set to be rotated (landscape on the Zune HD), the above code will actually print out a display size of (480, 272) rather than the standard (272, 480) size.

Read the rest of this entry »

New in the Focused Games Framework is the support for rotating and resizing the display on the fly. The main reason for this functionality is for mobile platforms like the Zune HD that support games in a landscape mode as well as a portrait mode. Supporting either in your game is made easy with FGF-you just need to know the right properties. In the standard display mode, the Zune HD has a display resolution of 272 pixels by 480 pixels. In landscape mode those two measurements are switched: 480 pixels by 272 pixels. While it is important to know the standard resolution, mucking about with a render target and backbuffer size is no longer necessary.

The one hitch? Your game class needs to inherit from FocusedGames.Xna.Application instead of Microsoft’s Game class. The following code block sets a Zune HD game up for landscape rendering.

1
2
3
4
5
6
7
8
9
10
11

public class Game1 : Application
{
    public Game1()
    {
        // Set the display size and the rotation
        DisplaySize = new Vector2(272, 480);
        DisplayOrientation = DisplayOrientation.Rotated;
    }
 
    // ...
}

Note that to keep the device in portrait mode, you don’t need to change the value of DisplayOrientation but setting the DisplaySize property to the standard value is a good idea. Happy landscaping!

Before I begin this post, big thanks to Eibx and David over at the Community Forums for helping me find these methods. I have modified the CheckTexture method a bit, but its purpose remains unchanged.

As of the last FGF article, the Application class was implementing the IGame interface but was missing the ability to create a render target object on the PC and Xbox 360. For PC games this can be a troubling problem since different hardware can obviously require different formats and dimensions of render target. Rather than bake this functionality into the Application class itself, it is moved to a static helper class so that all developers can make good use of its functionality at any point in time.

To start off, a simple default creation method is included to give the basic functionality an easy access point.

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

using System;
 
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
 
namespace FocusedGames.Xna.Graphics
{
    public static class GraphicsHelper
    {
        public static RenderTarget2D CreateRenderTarget(GraphicsDevice device)
        {
            return CreateRenderTarget(
                device, 
                device.PresentationParameters.BackBufferWidth, 
                device.PresentationParameters.BackBufferHeight, 
                1, 
                device.PresentationParameters.BackBufferFormat
            );
        }

Read the rest of this entry »

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 »