In the meantime you can stay up-to-date with news related to me and Focused Games over at jsedlak.com.

Thank you,
John Sedlak

Right now I am testing a few features being built into Thrust for the next release including the ability to log and share data between people playing a game on Live. The goal is to abstract the idea of a high scores sharing component to be able to share anything. The next release of Thrust will come with two things to share: high scores and error reports. While high scores will be a liberal thing to hand out, error reports will be setup in a client / server manner where only one server exists and is only connected to when a) it is up and running and b) the client wants to or can (ie the game detects he/she is idle in the menus).

• Versionator Vista X64 Setup (355) - 731.74 KB
• Versionator Vista X86 Setup (364) - 731.7 KB
• Versionator Source (358) - 183.54 KB

You can download the paper here: Vodka (Final Paper) (427) - 742.94 KB

Vodka is a service based Content Management System / Platform designed with one thing in mind: make a powerful content system that is easy to use.

One common misconception is that an AI character must be scripted, that they have to know what to do in every single case. While this is fantastic for those that know every possible case and want to know every possible outcome, it does nothing for emergent gameplay. Consider the possibilities if the AI didn’t know what they were doing the first time they did it. Hopefully you have arrived at the conclusion that an AI character starts to think and act like a human player with one giant flaw: the AI simply does not have the brain of a human. If you thought of this, you are right. However, what if we were to give the AI the ability to learn and thus be able to create a brain? Excited yet? Let’s start building us a framework.

Figure 1: Creating the Solution

To start us off I am going to create an empty solution in Visual Studio 2008 as shown in Figure 1. If you are unable to do this, create an Xna 3.0 Windows Game Library instead, calling it IntelligenceFramework. I start with an empty solution because it allows me to have more control over the projects created. The next step is just adding a Game Library called IntelligenceFramework. And to finish off with the creation stage, I will go ahead and remove the content project and the default Class1.cs file.

When we consider a human on a basic level, a conclusion can be drawn that humans can do a few generic things: use something, consume something, wear something, and release something. We can use these abstractions to create some interfaces. The first thing we will need is what represents the character, or human. For now, this IActor interface will have two methods with which we can add and remove objects that follow one of the above actions.

1
2
3
4
5
6
7
8

namespace IntelligenceFramework
{
    public interface IActor
    {
        void Add(IUseable useable);
        void Remove(IUseable useable);
    }
}

Clearly we need to create the IUseable interface now. This interface will serve as the basis for many other interfaces. We need to abstract all of them (IConsumable, IWearable, IReleaseable, et al) to a common level of functionality so the actor classes can deal with them in a single manor. The two operations needed are Deploy and Retract for the simple reason that the Actor class needs to be able to use (Deploy) the item and then [possibly] get rid of it (Retract).

1
2
3
4
5
6
7
8

namespace IntelligenceFramework
{
    public interface IUseable
    {
        void Deploy(IActor actor);
        void Retract();
    }
}

This is probably getting more and more abstract and thus it is time to throw it into a real world situation! Let’s add a class to the project and call it Actor. The Actor class will implement that IActor interface we created before. If you are asking yourself why I have taken the route of using interfaces instead of just creating the Actor class itself, it is because I don’t want to limit users to my idea of how the implementation should be. For instance, you will see in the following code that I do not Deploy or Retract the item when it is added or removed. This is, of course, a possibility depending on what kind of IUseable classes you are creating.

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

public class Actor : IActor
{
    List<IUseable> inventory = new List<IUseable>();
 
    public void Add(IUseable useable)
    {
        if (useable == null) return;
 
        for (int i = 0; i < inventory.Count; i++)
            if (inventory[i] == useable) return;
 
        inventory.Add(useable);
    }
 
    public void Remove(IUseable useable)
    {
        if (useable == null) return;
 
        inventory.Remove(useable);
    }
 
    protected IUseable[] Inventory { get { return inventory.ToArray(); } }
}

Now that we have a base class, create a new project so we can test it out! I am going to create a Console Application and call it RpgDriver for reasons you will soon find out. I am using a Console Application so as not to overload you with other things that would have to be done. The point of this project is to test out our framework easily and quickly. After referencing the IntelligenceFramework project, add a class to RpgDriver called Character. The Character class will inherit Actor and implement some new functionality.

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

class Character : Actor
{
    public Character()
    {
        Health = 25;
        MaxHealth = 100;
    }
 
    public void Use(Type typeOfUseable)
    {
        for (int i = 0; i < Inventory.Length; i++)
        {
            IUseable item = Inventory[i];
 
            if (item.GetType() == typeOfUseable)
            {
                item.Deploy(this);
                break;
            }
        }
    }
 
    public int Health { get; set; }
    public int MaxHealth { get; set; }
}

Here we are adding a function, named Use, that allows us to deploy a single instance of a certain type of item. We are also giving the character some health, however notice we are not filling the health to the max. The next step is to create our item: the health potion! Add a new class, called HealthPotion, to the project that implements the IUseable interface.

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

class HealthPotion : IUseable
{
    public void Deploy(IActor actor)
    {
        Actor = actor;
 
        Character character = Actor as Character;
 
        if (character != null)
        {
 
            character.Health += 50;
            if (character.Health > character.MaxHealth) character.Health = character.MaxHealth;
        }
 
        Actor.Remove(this);
        Retract();
    }
 
    public void Retract()
    {
        Actor = null;
    }
 
    private IActor Actor { get; set; } 
}

Fortunately the implementation is rather simple. On Deploy being called, the HealthPotion attempts to up the characters health by up to 50 points and then removes itself from the Actor’s inventory. The last thing to do with our test project is to write some test code! In Program.cs, type in the following:

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

class Program
{
    static void Main(string[] args)
    {
        Character myChar = new Character();
 
        myChar.Add(new HealthPotion());
        myChar.Add(new HealthPotion());
        myChar.Add(new HealthPotion());
        myChar.Add(new HealthPotion());
 
        Console.WriteLine("{0:000}/{1:000}", myChar.Health, myChar.MaxHealth);
 
        myChar.Use(typeof(HealthPotion));
 
        Console.WriteLine("{0:000}/{1:000}", myChar.Health, myChar.MaxHealth);
 
        myChar.Use(typeof(HealthPotion));
 
        Console.WriteLine("{0:000}/{1:000}", myChar.Health, myChar.MaxHealth);
    }
}

Now run it! You will see the health of the character move up and hit a max of 100 as the inventory length drops as potions are used.

1
2
3
4

025/100
075/100
100/100
Press any key to continue . . .

What is important to take away from all of this is that the Actor and Character classes do not know what they are actually using. All they know is that they can use the item and it may or may not have an effect on their properties. In this case we added a simple HealthPotion class that ups the health of the Character class and used the item manually. In the next part of this series I will cover how we can extend the base interface[s] to allow a health potion to be automatically used as well as used in certain situations. Further down the line we will cover how we can use genetics to get an AI to pick up items, use them and learn whether they are good or bad for the future.

So if you are about to submit a game for review and have not had anyone look at it, be sure to use the playtest feature. If nothing else, give the game to a few friends to try out.

1. A License
   

   FGF will be released under an official license. The license will remain fairly loose with a few restrictions put on distribution. For example, you can redistribute the libraries with your game/software but cannot redistribute the libraries as a standalone piece of software.

2. Refined State Management
   

   A lot of work has been going into getting all the kinks out of the state system because it is a very large part of Thrust. I am streamlining the Load code to give the end-developer more control over what is happening. I will be releasing some samples that cover this system in detail as well.

3. Return of the Control
   

   I have made the decision to start going back to GUI Controls. Although menus have done me well in the past, controls will allow me to truely delegate responsibility. I will be including some basic controls that implement much of the same functionality you see in the GUI library today. The menu system will state in tact, but look for it to be removed in a later release.

4. Gamer Profiles
   

   I have spent some time learning about the gamer profile APIs and will be including some classes that help manage user specific data. This will include helper classes for gamer profiles, storage, signing users in and out, et cetera.

5. A Better XmlProvider
   

   One of the best unused features of FGF is the XmlProvider class. It is an incredibly powerful and useful Xml serializer / deserializer. I have rebuilt it from the ground up to be even better. Not only that, I have ported it to the Zune and Xbox 360 platforms.

6. Samples
   

   I understand that many developers need samples. If you haven’t yet, check out the currently available samples. I will be adding to this list as time goes on.

7. Clear Error Messages
   

   One of the things I do worst is trap errors. It is a bad habit that I am attempting to change. Starting with Vodka, FGF will be getting clear cut exceptions, a numbering scheme and an online database of these errors with explanations and possible solutions. Check out FGDN for more.

8. A Faster Framework
   

   Last but certainly not least, I have made great strides in the performance of some of the core components of Thrust. This is especially true on the Zune where garbage collections were causing a big problem. I have taken extensive looks at the memory useage and garbage generation on the Zune with Thrust and have solved many of the issues.

If you are still with me, you are wondering what is bringing on most of these changes. As I gear up to release more games that are better (overall) and better suited for Xbox Live Community Games, I need to make sure that my core code works well. The biggest driving factor to most of the new changes is the newest version of Galactic Wars. The following video of Galactic Wars shows the smooth transitions between different UI states. This build of the game is using a post 1.2 build of FGF which makes it a lot easier to support a lot of what you see. My favorite part is how easy it is to handle when all gamers have signed out.

I have decided to model my system after Halo 3, making a few assumptions along the way:

1. Abstract Game from Player Specifics
   

   By removing the use of any specific PlayerIndex in the code, I can build a game that supports any player on the system so long as they are signed in.

2. Force Sign-In
   

   I am only going to worry about players that are signed in to GamerServices (online or not). When a user signs off, the system makes sure it is not the last player. If it was the last player, it raises event with which I use to go back to the start screen.

3. One NetworkSession to Rule Them All
   

   By utilizing the built-in Network Session code, I will force all gameplay to go through a standardized lobby which will work for any type of gameplay whether it be campaign, local multiplayer, coop, deathmatch or whatever I decide to add to the game. This is very similar to Halo 3’s system and is done to ease the development of the UI code.

Let’s take a look at the code. I first declare the class which includes a list of profiles, an event and two event handlers.

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

using Microsoft.Xna.Framework.GamerServices;
 
namespace FocusedGames.GalacticWars.Data
{
    class ProfileManager
    {
        private List<Profile> activeProfiles = new List<Profile>();
 
        public event EventHandler LostAllGamers;
 
        public ProfileManager()
        {
            SignedInGamer.SignedIn += OnGamerSignedIn;
            SignedInGamer.SignedOut += OnGamerSignedOut;
        }

Next we need to handle when a gamer signs out. If the profile exists in our system, we need to remove them and make sure we still have gamers left.

1
2
3
4
5
6
7
8
9
10
11

        protected virtual void OnGamerSignedOut(object sender, SignedOutEventArgs e)
        {
            Profile usedProfile = GetProfile(e.Gamer);
 
            if (usedProfile != null)
            {
                activeProfiles.Remove(usedProfile);
 
                CheckForGamer();
            }
        }

Similarly, when a gamer signs in we need to make sure that it isn’t already in the system for some reason. If it isn’t, we create / load it and add it.

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

        protected virtual void OnGamerSignedIn(object sender, SignedInEventArgs e)
        {
            Profile newProfile = GetProfile(e.Gamer);
 
            // If the profile isn't in our system, we need
            // to load it!
            if (newProfile == null)
            {
                newProfile = Profile.FromGamer(e.Gamer);
 
                if(newProfile != null)
                    activeProfiles.Add(newProfile);
            }
        }

Finally, the two helper methods:

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

        public Profile GetProfile(SignedInGamer gamer)
        {
            for (int i = 0; i < activeProfiles.Count; i++)
                if (activeProfiles[i].Gamer == gamer)
                    return activeProfiles[i];
 
            return null;
        }
 
        public void CheckForGamer()
        {
            // If no profiles are here, we need to 
            // grab one!
            if (activeProfiles.Count == 0)
            {
                // Delegate the responsibility. Listener can move to a specific screen.
                if (LostAllGamers != null) LostAllGamers.Invoke(this, EventArgs.Empty);
            }
        }
 
        public Profile[] ActiveProfiles { get { return activeProfiles.ToArray(); } }
}

On the next page we will cover exactly what the Profile class is and what it does!