David Inclán Blanco

Este articulo va dirigido a personas que tengan conocimientos básicos de programación orientada a objetos.

Como todos sabéis los juegos normalmente siempre tienen una presentación, una parte donde se juega, tabla de puntuaciones, etc. a nivel de programación debemos de separar estas partes en algo que se llaman estados de aplicación, un estado de aplicación es llamándolo de forma muy directa un objeto que recibe eventos de otro objeto que conoce como funciona un estado. El principal motivo de separar las partes de un juego es crear el código estrictamente necesario para ese momento del juego, además con esto se gana velocidad y limpieza.

Comenzare con definir como es un estado, lo haré en lenguaje C++, pero es aplicable para otros lenguajes, al final del articulo mostrare la implementación en mas lenguajes.

class State
{
public:
	// Evento al seleccionar el estado
	virtual bool OnSelect() = 0;
	
	// Evento al deseleccionar el estado
	virtual bool OnUnSelect() = 0;
	
	// Mas eventos y/u otras cosas
	...
}

Ahora pasaremos a definir la clase que trabajara con los estados.

class StateMachine
{
public:
	// Constructor
	StateMachine()
	{
		this->state = this->newState = NULL;
	}
	
	// Destructor
	~StateMachine()
	{
		this->SetState( NULL );
		this->UpdateStateMachine();
	}

	// Cambiar de estado
	void SetState( State *state )
	{
		this->newState = state;
	}
	
	// Obtener el estado actual
	State *GetState()
	{
		return this->state;
	}

	// Mirar si se debe de cambiar de estado en este ciclo
	void UpdateStateMachine()
	{
		if( this->state != this->newState )
		{
			if( this->state != NULL )
			{
				this->state->OnUnSelect();
				delete this->state;
			}
			this->state = this->newState;
			if( this->state != NULL )
			{
				this->state->OnSelect();
			}
		}
	}

private:
	// Estado actual
	State *state;
	
	// Nuevo estado
	State *newState;
}

Como se vera en el código se hace algo extraño y es que cuando queremos cambiar de estado no se hace inmediatamente, el motivo es dar la posibilidad de definir un estado en cualquier parte del estado actual sin que se ocasionen problemas, es decir, si cambiáramos de estado inmediatamente y luego se ejecutara algo de código la aplicación daría un error ya que ese estado a dejado de existir y de estar seleccionado, la función "UpdateStateMachine" permite definir en que parte del código queremos que se produzca este cambio, normalmente esta clase se llamara desde el núcleo de un motor o el bucle principal de la aplicación con lo que esta función debe de ser llamada en una parte en el que el código sea seguro, por ejemplo:

int main()
{
	...
	while( !exit )
	{
		// actualizar
		...
		// renderizar
		...
		
		// Cambiar de estado si es necesario
		machine->UpdateStateMachine();
	}

Como se ve la función "UpdateStateMachine" se ejecuta al final del bucle principal, gracias a esto tenemos la certeza de que el cambio de estado no producirá ningún caso extraño que cuelgue nuestro juego o aplicación.

Una vez definidas estas dos clases ya podemos separar nuestro juego en partes bien definidas con solo derivar la clase State, pero en C++ existe un pequeño problema y es que un estado puede llamar a otro, es decir, A puede llamar a B, pero B puede llamar a A, y es imposible poner los includes en A y B, con lo que la solución son los templates, mejor veis el código:

class StateMachine
{
	...
	
	// Cambiar de estado
	template <class STATE> void SetState()
	{
		this->newState = new STATE;
	}
	
	...
}

// staterun.h
class StateGame;
class StateRun : public State
{
	void OnSelect()
	{
		// Como la aplicación solo puede tener
		//  un estado lo correcto es hacer una 
		//  maquina de estados global
		gMachine.SetState<StateGame>();
	}
	
	...
}

// stategame.h
class StateRun;
class StateGame : public State
{
	void OnSelect()
	{
		gMachine.SetState<StateRun>();
	}
	
	...
}

Como se ve en el código con pre declarar la clase StateGame encima de StateRun el código funcionara correctamente y lo mismo sucede con StateRun, el principal motivo de usar aquí un template es que muchos estados  pueden ser templates y que no tengan un archivo .cpp.

Como prometí aquí esta el código para java:

// Clase base para los estados
public abstract class State
{
    // Se activo este estado
    public abstract void onSelect();
    
    // Se desactivo este estado
    public abstract void onUnSelect();
    
    // ...
}

// Maquina de estados
public class StateMachine
{
	// Cambiar de estado
	public void setState( State state )
	{
		this.newState = state;
	}
	
	// Obtener el estado
	public State getState()
	{
		return this.state;
	}
	
	// Cambiar de estado si es necesario
	public void updateStateMachine()
	{
		if( this.state != this.newState )
		{
			if( this.state != null )
			{
				this.state.onUnSelect();
			}
			this.state = this.newState;
			if( this.state != null )
			{
				this.state.onSelect();
			}
			// Limpiar el recolector de basura 
			//  (no es necesario, pero esta bien hacerlo)
			System.gc();
		}
	}
	
	// Estado actual
	private State state;
	
	// Futuro estado
	private State newState;
}

Para java no hace falta nada de templates ni trucos de este tipo ya que las clases estando en un mismo paquete se conocen y si no se pueden importar sin problemas, además debemos de notar que el evento onUnSelect será rara vez usado ya que los objetos se liberan de forma inmediata al asignar el this.state a this.newState.

En este articulo intentare hacer que los programadores vean su código compilado en la cabeza según lo están escribiendo, al principio les puede parecer complicado pero después de algún tiempo haciéndolo no lo es en absoluto. Para ello vamos a deducir como un compilador trata las secuencias if y como debemos de hacerlo correctamente para ganar velocidad. Tenemos este código:

struct Elemento
{
    void *dato;
};

Elemento *Mete( void *dato )
{
    if( dato == NULL )
    {
        return NULL;
    }
    Elemento *nuevo = new Elemento;
    if( nuevo == NULL )
    {
        return NULL;
    }
    nuevo->dato = dato;
    return nuevo;
}

struct Elemento
{
    void *dato;
};

Elemento *Mete( void *dato )
{
    if( dato != NULL )
    {
        Elemento *nuevo = new Elemento;
        If( nuevo != NULL )
        {
            nuevo->dato = dato;
            return nuevo;
        }
    }
    return NULL;
}

comparar dato con NULL
es diferente?
{
    … código dentro de las llaves
}
… código que va después

bool CrearMalla( int numVertices, int numIndices, char *fileShader )
{
    VertexBuffer *vertices = new VertexBuffer( numVertices );
    if( vertices != NULL )
    {
        IndexBuffer *indices = new IndexBuffer( numIndices );
        if( indices != NULL )
        {
            Shader *shader = new Shader( fileShader );
            if( shader != NULL )
            {
                return true;
            }
            delete indices;
        }
        delete vertices;
    }
    return false;
}

La mayoría de las veces la gente cuando se pone a programar juegos 2d o 3d se centran exactamente en el numero de dimensiones que tendrá ese juego, esto en mi humilde opinión es una forma de pensar totalmente incorrecta, el problema de pensar en 2d o 3d es que creamos funciones para este tipo de dimensiones y no pensamos en la verdadera optimización de pensar en n-dimensiones. ¿Que es pensar en n-dimensiones? Pensar en n-dimensiones es tener claro el concepto de que es una dimensión, para explicar lo que es una dimensión lo haré de la forma mas sencilla que conozco, una dimensión no es mas que un espacio comprendido entre dos puntos que se llaman -infinito y +infinito, en un ordenador lamentablemente infinito no existe (salvo en bucles), la mayoría de las veces las dimensiones son tratadas de -float +float, es decir, de 1.17549e-38 hasta 3.40282e+38, teniendo claro esto, podemos decir que todas las dimensiones se comportan de la misma manera ya que solo definen la posición en un espacio (algunos lo entenderéis mejor si lo llamara vector). Un ejemplo practico de como pensar en n-dimensiones es la clásica función para comprobar si un cubo definido por dos puntos (mínimo y máximo) esta dentro de otro o por lo menos esta parcialmente dentro de otro, la mayoría de las personas harán la clásica rutina de mirar si uno de los dos puntos del cubo A esta dentro de los puntos del cubo B, esto en mi opinión es un error muy gordo ya que solo se ha pensado en 3d y no en n-dimensiones, partimos de que tenemos las siguientes estructuras:

struct Vector
{
    float x, y, z;
}
struct Caja
{
    Vector min, max;
}

bool Colision3D( Caja& caja1, Caja& caja2 )
{
    if( PuntoDentro3D(caja1, caja2.min) || PuntoDentro(caja1, caja2.max) )
    {
        return true;
    }
    return false;
}
bool PuntoDentro3D( Caja& caja1, Vector& punto )
{
    if( punto.x > caja1.min.x && punto.x < caja1.max.x &&
        punto.y > caja1.min.y && punto.y < caja1.max.y &&
        punto.z > caja1.min.z && punto.z < caja1.max.z )
    {
        return true;
    }
    return false;
}

if( valor > 10 && valor < 20 ) return true;

if( max > 10 && min < 20 ) return true;

if( min > 20 || max < 10 ) return false;

bool ColisionNDimensiones( Caja& caja, Caja& caja2 )
{
    if( caja1.min.x < caja2.max.x && caja1.max.x > caja2.min.x && 
        caja1.min.y < caja2.max.y && caja1.max.y > caja2.min.y &&
        caja1.min.z < caja2.max.z && caja1.max.z > caja2.min.z )
    {
        return true;
    }
    return false;
}

bool ColisionNDimensiones( Caja& caja, Caja& caja2 )
{
    if( caja1.min.x < caja2.max.x && caja1.max.x > caja2.min.x && 
        caja1.min.y < caja2.max.y && caja1.max.y > caja2.min.y &&
        caja1.min.z < caja2.max.z && caja1.max.z > caja2.min.y &&
        caja1.min.a < caja2.max.a && caja1.max.a > caja2.min.a &&
        caja1.min.b < caja2.max.b && caja1.max.b > caja2.min.b)
    {
        return true;
    }
    return false;
}