Progress on the Main Game UI

A really brief update on the UI that will be used in the gameplay screen. Nothing very special to report, I am working my way through XNA and I must admit that while some stuff is extra cool, some bits are getting a bit annoying like trying to use the SpriteBatch class with custom effect. This is more complex than it should be and although you can find some way around the issues and it is rather documented on te web, you just get the feeling that it could be easier than that. It is woth mentionning that I am still using XNA 3.1 and maybe these issues are fixed in 4.0. I'll upgrate to the latest version a some point in time but so far I am glad to be able tu keep using VS 2008 as I am really used to it (XNA 4.0 doesn't install on pre VS2010 to my knowledge).
Also, I am getting a bit worried by the performances, mainly because of the gaussian blur shader that I use in a few places. I could repalce that by a Poisson disk blur filter which I may do after the game is implemented. The way I use the SpriteBatch also seems really inefficient so hopefully there will be plenty of room for optimization without struggling that much.

Here is a video of how it looks so far:

-m

More work on the UI

Some visual improvements, plus another, more complex UI page.
This is all coming along very well and I am uite pleased and excited :)

-m

First version of the Game UI

I have been working on the UI system for my XNA game since most of the added value will be a neat presentation layer. I came up with a fairly simple UI system that builds up on my state machine class I talked about last time. The whole thing is rather straightworward to use. Here is a quick video of it in action:

One of the interesting thing about this UI framework is the ability for any widget to specify its neighours, so when the focus moves, the UI page can figure out who should recieve the focus. Here is a snippet from the UIWidget class which is base for all widgets:

   public class UIWidget : StateMachine
   {
       ...
       public UIWidget LeftNeighbour
      {
           get;
           set;
       }
      public UIWidget RightNeighbour
       {
           get;
           set;
       }
       public UIWidget UpNeighbour
       {
           get;
           set;
       }
       public UIWidget DownNeighbour
       {
           get;
           set;
       }
       ...
   }

Widgets are laid out on UIPage objects. A UIPage keeps track of the focussed widget and processes pad inputs. When recieving a pad message, it picks the right neibour from the focussed widget and transfers focus to it. Note that multiple controls can have the same neighbour for a particular direction, so you can create rather complex layouts with a bit of work.

That's all for today!

C# State Machine class

For my little XNA game that I am developping at the moment, the main thing I needed was a simple Finite State Machine class that I could use as the basis for prtty much any game object, especially for all the GUI and GameState logic.

I didn't want to spend too much time on a framework or grab one of the many libraries available here and there and then spend some time learning how to use it. Instead, I had the feeling that using the reflection capabilities of C#, I could easily and quickly come up with a simple piece of code that would fulfill my needs for this project. Functionnality-wise, my inspiration was Steve Rabin's article about a set of C++ macros for writing simple state machines. I used them quite a lot in the past and liked the fact the simple feature set, perfectly suited for small scale projects.

Basically, a State Machine can be in a certain number of differnt states and transition from one to another. Each state has:

• an Enter() function callled when this state becomes active. This is the perfect place to do per-state setups
• an Update() function that should be called once per frame
• an Exit() function, called when leaving a state for another one. This is the perfect place to do some cleanup before leaving the state

State and handlers are defined via a simple naming convention that applies everywhere:
   StateName__Handler(...)


As a quick example to make that obvius, let's have a look at the Default state (which does nothing at all):
   public virtual void Default__Enter(string _OldState){}
   public virtual void Default__Exit(string _NewState){}
   public virtual void Default__Update(GameTime _GameTime){}


On top of that, each state can define message handlers for any message it wants to support. Message are defined by a simple string. For instance, the handler for a message called TakeDamage in the Default state and parametrized with an amount of damage points would imply the following bits:

   public virtual void Default__TakeDamage(int _Damage)
   {
      Health -= _Damage;
   }

And game code would send the message like this:
   Target.ProcessMessage( "TakeDamage", 10 );

As you can see this is all really simple. But here comes the goodness :)

• You can have handlers that handle the same message differently per state:

   public virtual void Default__TakeDamage(int _Damage)
   {
      Health -= _Damage;

   }

   public virtual void Invincible__TakeDamage(int _Damage)
   {
   }

• You can derive a state machine class from an existing class and override handlers so they do different things:

   class Soldier : StateMachine
   {
      public virtual void Default__TakeDamage(int _Damage)
      {
         Health -= _Damage;

      }
   }

   class SoldierFragile : Soldier
   {
      public virtual void Default__TakeDamage(int _Damage)
      {
         Health -= _Damage * 5;

      }
   }

The implementation might be rather simple and compact but it'still quite powerfull as you can see.

However, nothing is perfect in this world and I am sure some design choices are arguable ... but they suit my needs so I'm fine with it. I think the major concerns would be:

• Weak state referencing as it is all done by strings and naming convention. So if you write typos or rename stuff around, this is likely to break. More error handling could be added but ultimately, this is just a string and this is rather fragile.
• State specific variables will live at instance scope, not state scope. This is because I want to be able to acces the state machine members from anystate (this reduces the nb of accessors and stuff you need to write)

If you are interested in giving it a try or looking how it is done, you can find the source code with a stupid test case here. Note that I personally use it with XNA but this is rather generic and could be used without XNA. In fact, the provided implementation doesn't use XNA although it is straightforward to adapt it. In XNA, the State machine class should derive fron GameComponent.

Feedback welcome !

-m

Another project !

I've been thinking quite a lot about what's motivationg me in writing code and games at home, as this is also what I do for a living (lucky me!). More specifically I tried to analyze why I statrt lots of projects and rarely finish any of them. Long story short, I think it all boils down to me being more interested in writing nice code and developping a nice tech that creating a fully finished game with it as the ratio of time spent on thinking about tech vs game is probably 20:1 ... All that is great and I've learnet and keep learning a lot from this "R&D" but this doesn't provide the rewarding feeling of having completed something entirely (which is a really really nice one - I've expereienced it twice recently when finishing the development of Enslaved - Odyssey to the West and its DLC)

So to break that cycle, I want to start working on a project that has the opposite characteristics of my usual projects:

• Not technically challenging, so there is no opportunity to get sidetracked/lured by interesting problems to solve
• Design is simple, achievable end well established, so again there is not a lot of fiddling around with tons of ideas before getting a grasp of what thet game I want to make is all about
• Added value is in the final product being neat and polished
• Not attached to its codebase. This is a weird one but over the years, I realized that if I write a C++ engine for a game, I get really attached to the codebase and want to make it as neat and well architectured as can be - certainly because I have this long term project of coming up with some tech that is full-featured enough for XBLA-scope projects. On the other hand, I tend to consider code written in any other language as some discardable one-off thing where I wont bother spend ages polishing code to death. Consequently, I'll write this new project in C# / XNA so I can get it done quickly, because the language is inherently efficient and because I won't be too bothered to hack things around when needed. (Moreover, I think there are a lot of lessons to learn from the XNA architecture that I could apply in my C++ engine)
• A 1 person project. I don't want to depend on anyone nor have people depending on me for this project. No that peaolpe I have been working with on other stuff are a problem - I love them and they are skilled/reliable/etc ... but I just want to try something different this time. This mean almost no art/anim etc as I can do basic stuff but that's it :) I am also looking forward to the music/sound bit as this will bridge my passion for code/games and playing music :)

I have my mind set on what this project will be and the best way to sum that up is: "a remake of Picross with a neat interface a-la PS3's crossmedia bar" ... More details in my next post.

In the meantime, take care !

-m