So the new idea is to keep it sleak and simple. On the PC/360 version the menus will drill down a little differently but the idea is the same.

1. References
   
   The first problem (the reason for the creation of XmlProvider) was that the built-in classes could not handle references. Every object had to be serialized straight through from top to bottom. Thus if you had an object with two properties that referenced the same object (in memory), the object would be serialized twice.
2. Inheritance
   
   The new problem is that with XmlProvider, deserialization was based on the information given by property attributes in your code. This is limiting because you may not know at compile time what exact type of object your property will be holding a reference to. In Galactic Wars 3 this is a problem when I am saving the profile of the user and want to save his specific ship.

So what is the solution? Start from scratch of course and solve these two problems at once! The first one is easy: provide a mechanism with which to uniquely identify any objects in memory and in Xml. We can then build a cache which we can reference from as we find objects with references. The solution to the second problem is also simple: rely on the type name in the Xml rather than the type on the property’s attributes.

To start us off, we will need an attribute with which we can decorate our classes. We will call this class XmlNodeAttribute since anything utilizing it will become an XmlNode. The code is fairly straight forward as shown below. We need a simple enumeration to define what type of Xml node to create because objects with properties need to be treated differently than simple types like boolean, string, int, et cetera.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class XmlNodeAttribute : Attribute{
    public XmlNodeAttribute(string name, XmlNodeType nodeType)
    {
        Name = name;
        NodeType = nodeType;
    }
 
    public XmlNodeType NodeType { get; set; }
    public string Name { get; set; }
}
 
public enum XmlNodeType{
    Complex,
    Simple
}

Next we can setup our XmlProvider class…

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

In the StateObject class, let’s add a private queue to the list of private fields.

1

private Queue<State> statesToTransition = new Queue<State>();

Next up, we need to fix the Transition function to take into consideration the queue. Instead of beginning the transition immediately, we need to add it to the queue and then check if we can use it.

1
2
3
4
5
6

public virtual void Transition(State newState)
{
    statesToTransition.Enqueue(newState);
 
    CheckForNewTransition();
}

Note that we have removed the transitioning code and put it inside a new function that we need to create.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

protected virtual void CheckForNewTransition()
{
    if (CurrentState == States.Transitioning)
        return;
 
    if (statesToTransition.Count > 0)
    {
        CurrentState = States.Transitioning;
        NextState = statesToTransition.Dequeue();
 
        transitionTime = NextState.Time;
        currentTime = 0.0f;
    }
}

This function checks to make sure that the object isn’t already transitioning because if it is, we can’t start a new transition. It then checks the queue for a new state to transition to and if so, starts that transition. Because we do not want it to transition only when we add a new state on the queue, we need to add a call to this function in the Update method.

1
2
3
4
5
6

public virtual void Update(GameTime gameTime)
{
    CheckForNewTransition();
 
    UpdateTransition(gameTime);
}

This, unfortunately, is just not good enough! No, we need to add a function so we can adjust the transition time for each state change. This allows us to avoid creating new states just to change their timing. To do this, we simply add an overload to the Transition function.

1
2
3
4
5
6

public virtual void Transition(State newState, float time)
{
    newState.Time = time;
 
    Transition(newState);
}

Now that we can do some fancy transitioning, we also want to make sure we handle when the state changes. We will modify a method in our StateObject, OnStateChanged, which will handle when this situation occurs. What we want to handle is when a special state comes to pass, the RemoveReady state.

1
2
3
4
5

protected virtual void OnStateChanged()
{
    if(CurrentState == States.RemoveReady)
        StateManager.Remove(this);
}

Now we need to adjust StateManager to make sure each state object is given a reference to the manager so this is possible. To do this, we will modify the Load method as follows.

1
2
3
4
5
6
7

public void Load(params IStateObject[] objectsToLoad)
{
    for (int i = 0; i < objectsToLoad.Length; i++)
        objectsToLoad[i].StateManager = this;
 
    currentObjects.AddRange(objectsToLoad);
}

And there you have it. You can download the updated source code below.

ATS: Part 2 (20) - 115.95 KB

1. Easy to use
   

   The system needs to be abstract enough that developers can easily integrate it with their current code. It should be transparent and simple in its most basic form. This means that the idea of an object having a state should require no special implementation code for the developer introducing states to his or her objects.

2. Easy to extend
   

   What base layer we build has to be open enough that new states can be defined on the fly or hardcoded. This implies that no constants should be used (Enumerations) and the base layer should understand new states.

3. Powerful
   

   This is a very general term, but the point is clear. The state system must be able to have some guaranteed affect on the code we introduce it to. The state system must introduce some way of controlling the objects.

These three guiding rules will help us understand exactly how to design the system. As we understand the implications of each, we need to make some specific assumptions about the platform we are writing for and what each state or object needs to have.

1. Support for interfaces, structs and classes
   

   In this case we are using C# and the XNA Framework, but this state system can be applied elsewhere. Thus we need to make the assumption that the platform (and language) we are implementing the system in is Object Oriented and has support for interfaces, structs, classes, inheritance and more.

2. Each object will know how to control itself
   

   In Thrust I made the assumption that each object knows how to control itself. This simple means that an object that has a state knows what to do with that state. To understand this better, let’s apply it to humans. A human can be considered to have many states, among them “Asleep” and “Awake”. When a human being is sleeping, it knows to dream, to rest, et cetera. We do not have some outside source telling us to dream. In a similar manor, objects that have state must know what to do in each state.

3. Each object has some known functionality
   

   Because we are applying this to XNA, we are going to assume that each object’s known functionality is to be drawn and to be updated. Knowing this functionality will help the state system to understand what to do with each object. You can ignore this assumption in order to implement it in a dynamic manor, but we will save that for a future article.

Now that we understand the goals of the system and what assumptions we need to make, we can start designing the system itself. I will, unfortunately, catch a lot of flak for saying this, but I believe that manager classes do have a place in modern game development. In the situation this article presents, we can utilize a manager class to help objects transition between states. Each object, according to goal number one and two, must be generic in some way. Thus we introduce an interface to define the common functionality.

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.

Galactic Wars 3 (2431) - 7.46 MB