Pompi Pompi – A Gamers and Developers blog for indie games

I have implemented the menu skeleton as I mentioned in the check list. You can download the source code of revision 13 here.

Finite State Machine is a sort of design pattern that can be very useful. I learned it from a book about AI called “Programming Game AI by Example”. There is no one way to implement a Finite State Machine(FSM) and the one in the book is in C++, but I will show you how I implemented it in BJBK with C#.
What is a FSM? FSM is a directed graph, in which only one state(or vertex of the graph) is active and the active state can change to other states to which it is connected to with edges. You can think of it as a world map with cities and roads. The active state is the city in which your party or characters are currently at. The party can travel only on the roads connecting the cities in order to travel to another city(changing the active state). The main difference is that in a FSM, some roads can be one way roads.
Let’s see the code in FiniteStateMachine.cs:


    interface State<T>
    {
        void Enter(T e);
        void Execute(T e);
        void Exit(T e);
    }
    class FiniteStateMachine<T>
    {
        public FiniteStateMachine(T e)
        {
            Entity = e;
        }
        public void Update()
        {
            if (CurrentState == null)
                return;
            CurrentState.Execute(Entity);
        }
        public void ChangeState(State<T> s)
        {
            if (CurrentState != null)
                CurrentState.Exit(Entity);
            if (s!=null)
            {
                CurrentState = s;
                CurrentState.Enter (Entity);
            }
        }
        private State<T> CurrentState;
        private T Entity;
    }
Let us observe the interface State first. This interface is generic, that means it gets a class type as a parameter. It is also an interface, which mean it lacks implementation. As the name imply, this interface represent the actual state or vertices of the graph. In order to create different states, we only need to implement this interface.
When the characters goes to a new city or the FSM change the active state, the new active state’s method Enter will be called once. With some class as a parameter. From this point, the Execute method will be called once every frame until the active state will change again. When the active state will change again, the current active state’s method Exit will be called.
What is the class passed as parameter? The parameter is a class of a generic type, this will allow the states have a common class to use. This class will usually create all the related states in the first place. In BJBK the generic class is Menu and it’s states are the different menus available. These can be MainMenu, Options, Video, Sound and etc. However, the same FSM could be used for AI or other things.
The class FiniteStateMachine simply implements what I have said about the states. It is generic and points to the generic class that will be passed to every state when their methods are called. Update should be called each frame, or each time you want the FSM to execute the curent active state. ChangeState will change to a new active state.

That’s it, that is the FSM implementation. However, you might feel something is missing. There is no class or interface to represent the edges of the graph?
The reason is that by calling ChangeState you virtually create the edge. The edges are not “precalculated”, but they are rather implied by the calls to ChangeState on run time. The same goes with the graph structure. There is no explicit graph structure. You can create new vertexes at run time and change the graph structure during run time. This is all done programmatically. Although, in the case of the BJBK menu, the graph is static and does not change during run time.

The source code of revision 10 can be found here. Notice the disclaimer\agreement on the download page.

Files overview
The code has several .cs(C# source code), each one is dealing with another aspects of the game.
Game1.cs is a file that was created by visual C# when I was selecting the Windows Game project. It is the “game” file, in which all updates to the game logic and all drawings of the graphics will be called from.
Program.cs contains the main of the program, and it will create and run the game class that was defined in Game1.cs. 
Object.cs define objects class. Objects could be anything, but in this case these objects are the ground, the banana, the player and in the future also the barrel. I think we can say these are physical objects, because the base object class contains all the physics calculations. In this game, every physical object contains the physics, the logic update and the drawing call, all in one object. In Labyrinthicathings are not as simple as that, but maybe I should try thinking of doing it as such in bigger projects as well. I am not sure it is easy to do so though. You can try and study the hirarechy of objects inside Object.cs to get a sense of how inheritance can be used in this case.
Camera.cs contains a camera class. A camera in a 2D game is also 2D, the camera points where the center of the screen would be in the virtual 2D world. The camera class also have functionality to tell if an object is visible or not. In this game the camera class also moves to the right in a constant speed.
Section.cs contains a class with a functionality to check if two rectangle physical objects intersect with each other.
Input.cs contain classes to deal with input from the player. I defined an interface called PlayerControl. This interface describe the possible commands for the player to send the game. However, it doesn’t have any implementation and it doesn’t limit which input device will be used to send these commands. KeyboardInput implements PlayerControl and allows the player to use the keyboard to send these commands. In the future I could add other input devices, such as an XBOX360 gamepad, to send these commands by simply implementing the PlayerControl interface.
The last file is Level.cs. This file contain classes to manage groups of objects and help create them.

Patterns level design
Patterns level design is about design decisions regarding a small group of classes that relate to each other. It’s a lower level than a high level, concept level overview of the game. But it’s higher than a single function or a single class. These kind of design decisions are useful for almost any project and are not project specific. They may be used for project specific classes, but the concept can be used for other projects as well.
I have already talked about the interface ControlPanel, but it’s an example of how you separate the concept of a game control from a specific game device that implement the ControlPanel interface.
The classes PlayerObject and PlayerKicker from Objects.cs are related to each other. The player in this game can run, jump or kick. When in kick state, the player actually change it’s collision rectangle dimensions and change it’s color. These two classes inherit from a base class that has an update logic and draw virtual functions. For the normal state in which the player run and jump, we could use PlayerObject. For the state of kicking we could use PlayerKicker. But we need an object that contain both states! What I have done to solve this is called delegating. Delegate is when a class with certain virtual methods, is using another class with the same virtual methods. It is as if the class outsource part of it’s method. This is not an accurate description, but for lack of better description I will use it.
I have made PlayerObject create and keep a reference to a PlayerKicker object. In the update method of PlayerObject, I have set the PlayerKicker position to be the same as the updated PlayerKicker position. In the draw method, if the player is in normal state, I will draw it normally. If the player is in kick state, I will call the draw method of PlayerKicker instead.

Spartan programming
Spartan programming are several metrics that should be attempted to minimize simultaneously. Minimizing these metrics suppose to help you create a more readable code and make better use of the terms available to name classes, methods and functions. It is supposedly regarding the function level, but it affects the structure of the whole program, in a sense. I didn’t invest a lot of effort to “spartanize” BJBK, but I will give one simple example of how spartan programming might be useful. Take a look at the following method:

virtual public void Update(float t, Camera c)
{
Vector2 a = new Vector2(0, PixelsPerMeter*9.8f);
Velocity = Velocity + a * t;
Position = Position + Velocity * t; // Like n*(n-1)/2
Position.Y = MathHelper.Min(FloorY, Position.Y);
Velocity.Y = (Position.Y==0.0)?MathHelper.Min(0, Velocity.Y):Velocity.Y;
}

In this method you can see variables and parameters such as ‘a’, ‘t’ and ‘c’. If you would use these as global variables, it would minimize the amount of names(specifically those 3 letters) you can use in a smaller scope. Since this method is pretty small(one of the spartan metrics) it is also possible to use short names(another spartan metric) for these specific variables and parameters that exist only inside the method’s scope. Other names such as ‘Velocity’ and ‘Position’ are longer, perhaps because they are class members and are used in a bigger scope. I have used the ‘Term?a:b’ idiom instead of an if. Ifs are basically very bad for readability. In many cases it make sense to use this idiom instead of an if. Notice all the lines of code are at a reasonable length.
There isn’t a lot more I can tell about this function right now, but I hope you got a feeling of how spartan programming can help.

Movement equation
As you can see in the previous section, each frame I recalculate the velocity and position of every physical object in the game. The position equals integration of velocity over time, which equals integration of acceleration over time. If t is the time variable, a1 is a constant acceleration, v1 is a constant velocity and x1 is a constant position, then:
a = a1
v = v1 + a1*t
x = x1 + v1*t + a1*t*t/2
We could use the last equation to calculate the position. We could get along with this in BJBK, but if the velocity or acceleration are not constant and do not behave so nicely, then the integration would be more difficult. Instead every frame I make the following calculation:
v = v + a*t
x = x + v*t
Notice these are assignments and not equations! But where did the 1/2disappear? Lets check if it make sense. Lets say we have n frames of a constant T each frame. Lets say x1=0 and v1=0. Then at time n*T the first equation will give us: x = a1*n*n*T*T/2
In the second case, we need to iterate the assignments n times until we get the result at time n*T. v is initialized to v1(0), which means v at frame i out of n will be equal to a1*i*T.
That means x at frame n will be equal to: Sum (i=0 to n) of a1*i*T*T. The result of this sum is actually a1*n*(n-1)*T*T/2.
As you can see, the result is almost the same and we can also have non constant acceleration and velocity if we want to.

Feedback
What are your thoughts about this code review? Is it too long? Too difficult? Did you like it? Should I separate it into several articles?