La STL es una colección de estructuras de datos y algoritmos de uso común. Esta basada en plantillas utilizando programación genérica. Está diseñada para ser eficiente, evita el uso de funciones virtuales en favor de las plantillas evitando operaciones en tiempo de ejecución.

La STL se podría dividir en tres grandes partes: Contenedores (plantillas de estructuras de datos populares), iteradores y algoritmos.

Introducción a los contenedores

Los contenedores de la STL son estructuras de datos capaces de contener casi cualquier tipo de objeto (hay algunas restricciones). Existen 3 tipos de clases contenedoras: contenedores de primera clase, adaptadores y casi-contenedores.

También podemos catalogar a los contenedores por el tipo. Existen 3 tipos de contenedores: Contenedores de secuencia, Contenedores asociativos y Adaptadores de contenedores. Vamos a ver una tabla con los tipos de contenedores que hay.

Las contenedores de secuencia representan estructuras de datos lineales tales come vectores y listas enlazadas. Los contenedores asociativos representan estructuras de datos no lineales que por lo general pueden localizar elementos almacenados en ellos rápidamente. Dichos elementos pueden almacenar conjuntos de valores, o pares clave/valor. Los contenedores de secuencia y los contenedores asociativos son los contenedores de primera clase. Las pilas (stack), las colas (queue) y las colas priorizadas (priority queue) son en realidad versiones restringidas de los contenedores de secuencia. Por esta razón la STL los implementa como adaptadores de contenedores que permiten a un programa ver un contenedor de secuencia de manera restringida.

Existen otro tipo de contenedores los conocidos como casi-contenedores que son los arreglos basados en punteros tipo C,  los contenedores bitset para mantener conjuntos de valores de bandera y contenedores valarray para llevar a cabo operaciones vectoriales matemáticas de alta velocidad (esta última clase esta optimizada para un buen rendimiento del compilador y no es tan flexible como los contenedores de primera clase). Se les consideran casi-contenedores porque guardan similitud con los contenedores, pero no soportan todas sus capacidades. El tipo string de la STL, por ejemplo, soporta la misma funcionalidad que un contenedor de secuencia, pero sólo almacena datos de tipo carácter.

Funciones comunes de los contenedores

La mayoría de contenedores de la STL proporcionan una funcionalidad similar. Hay muchas operaciones genéricas, como el método size, que se aplica a todos los contenedores. La siguiente tabla muestra los métodos comunes en todos los contenedores

Archivos de encabezado de la STL

En la siguiente tabla se muestran los archivos de encabezado necesarios para los distintos contenedores. Todo el contenido de estos archivos de encabezado está dentro del namespace std

Definiciones typedef comunes de los contenedores de primera clase

En la siguiente tabla se muestran los elementos typedef (para crear sinónimos o alias de tipos extensos) comunes que se encuentran en los contenedores de primera clase. Estos elementos typedef se utilizan en declaraciones genéricas de variables, parámetros a funciones y valores de retorno de las funciones. Por ejemplo, value_type en contenedor es siempre un typedef que representa el tipo de valor almacenado en el contenedor.

Al utilizar contenedores de la STL, es importante asegurar que el tipo de elemento que vaya a almacenarse en el contenedor soporte un conjunto mínimo de funcionalidad. Al insertar un elemento en un contenedor, se crea una copia de ese elemento. Por esta razón el tipo de elemento debe proporcionar su propio constructor copia y operador de asignación (esto solo se requiere si la copia y la asignación predeterminada a nivel de miembro no se realizan operaciones apropiadas de copia y asignación para el tipo de elemento). Además, los contenedores asociativos y muchos algoritmos requieren de la comparación de elementos. Por esta razón, el tipo del elemento debe proporcionar un operador de igualdad == y un operador menor que <.

Hemos visto una introducción a los contenedores los tipos que hay las funciones miembros comunes a ellos, sus archivos de encabezado y los typedef comunes. En el siguiente artículo haremos una introducción a los iteradores y en los sucesivos empezaremos a ver específicamente cada contenedor y usarlos en la práctica.

• IA en videojuegos – Persiguiendo y evadiendo II
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• SFML – Manejando eventos
• SFML – Abriendo una ventana

Si me preguntaran sobre cual es el mejor lenguaje para programar videojuegos, diría que depende. Depende del próposito, plataforma, tipo de juego y un sin fin de detalles más. Pero si me dijeran que dijera el más general, el más usado, el más potente y en el que estén hechos la mayoría de las superproducciones de las grandes compañías diría C++ sin pensármelo dos veces. C++ es el lenguaje por excelencia en el mundo de los videojuegos debido a que combina el bajo nivel y la eficiencia que da C con la programación orientada a objetos que es casi imprescindible en la programación de videojuegos.

El problema es que para los recién llegados al mundo de la programación empiezan a investigar y mucha gente les mete miedo diciendo que C++ es muy complejo y que no es un buen lenguaje para comenzar, esto es una verdad a medias, es cierto que hay lenguajes de más alto nivel que simplifican ciertas cosas a cambio de sacrificar control y eficiencia, pero por lo menos en mi caso eso es mucho peor para aprender. Me explico, cuando uno está aprendiendo tienen que entender el porqué de las cosas, cual es la finalidad de esto o lo otro, porque mejor usar este tipo de dato o este otro. Eso con lenguajes de alto nivel se pierde, te abstraen tanto del hardware y el bajo nivel que no comprendes porque se usan ciertas cosas. Se aprende “porque sí” y no se está aprendiendo realmente como funcionan las cosas. Con C++ tienes que comprender que es lo que está haciendo el ordenador y porque las cosas se hacen así. Yo sinceramente aprendo mejor las cosas cuando entiendo el porqué que cuando de me dicen: “simplemente es así”. Así que animo a todos los nuevos programadores a no tener miedo y a empezar a programar con C++ y a entender las cosas. Muchas veces nos dicen que son complejas, pero no es cierto al fin y al cabo la programación es sencilla, se complica cuando se empieza a abstraer y abstraer, pero de eso ya habrá tiempo.

Otro de los grandes escollos una vez se decide empezar con C++ es el temido “¿Por dónde empezar” muchos potenciales programadores se desaniman al poco tiempo porque no encuentran algo que les enseñe desde cero o se desmotivan viendo que tienen simples programas de consola, ¡Ellos quería programar videojuegos, no letras blancas sobre un fondo negro! Sobre esto último no puedo ayudar mucho, es la única forma de empezar, es muy difícil aprender conceptos básicos con aplicaciones gráficas. Sobre lo primero voy a intentar ayudar sobre el cámino que yo seguiría.

En la red hay mucha documentación para aprender a programar videojuegos, la mayoría como sabrás, en inglés (es lo que hay) de todas maneras en esta comunidad tratamos de generar y recomendar contenido en español y voy a intentar que así sea en esta pequeña guía de como aprender a programar videojuegos con C++.

1. Aprende C++

Parece obvio, pero a veces no lo es tanto. Para empezar basta con usar un editor de texto con el que generar los ficheros fuentes y un complidador, yo recomiendo el compilador gnu gcc (g++ para C++) y el IDE Codelite. Pero eso es cuestión de cada uno, hay muchos IDE y compiladores C++.

Una ves tengas eso necesitas un manual/curso/tutorial de C++ que te enseñe desde el principio. Puedes comprar un libro (hay muchos y muy buenos) buscar alguno en ingés en google (también los hay muy buenos), pero como dijimos antes vamos a tratar de darte una opción en español. Yo te recomiendo el curso de ConClase es muy popular y de los mas visitados en la red, un curso completo de C++ en español y gratuito.

• http://c.conclase.net/curso/

A la vez que aprendes C++ te recomiendo que busques y leas mucho acerca de Algoritmos, métodos de programación y estructuras de datos. Lee y lee mucho pues es la única forma de aprender.

Una web que debería tener a mano todo programador de C++ es la siguiente, contiene toda la referencia de las bibliotecas estándar de C++, es bueno tenerla a mano siempre.

• http://www.cplusplus.com/reference/ (inglés)

2. La STL

Una vez te defiendas con C++ a un nivel básico te darás cuenta que hacer ciertas cosas es algo tedioso, existe una colección de Bibliotecas que son un Standard de C++ y que la mayoría de los compiladores actuales trae llamada STL, La STL es casi fundamental para no volverte loco cuando los programas se vuelven complejos y necesitas tipos de datos avanzados. Descubrirás que contiene plantillas que facilitan el uso de tipos de datos avanzados como cadenas, vectores, diccionarios y un largo etcétera de utilidades.

A continuación dejo algunos documentos muy útiles para aprender a usar la STL.

• http://geneura.ugr.es/~gustavo/stl/stl.html
• http://decsai.ugr.es/~jfv/ed1/c++/cdrom4/paginaWeb/stl.htm
• http://www.zator.com/Cpp/E5.htm
• http://gabarro.org/wiki/STL_vector
• http://mictlan.utm.mx/arreglos.html

3. Vamos a por los juegos

Aunque espero que durante las etapas anteriores hayas tenido imaginación y empezaras a crear tus propios juegos en modo consola tales como ahorcados, adivina el número, hundir la flota, etc. Ha llegado la parte de empezar con aplicaciones gráficas. Aquí uno debe elegir que camino tomar. Para los videojuegos el camino sería aprender a usar una biblioteca 2D. Muchos se desilusionan en este punto nueva mente porque ellos quieren hacer super juegos 3D que compitan con el último juego de moda, pero primero se debe aprender a caminar para después correr. Aprender como se trabaja en un proyecto de videojuego y con bibliotecas externas, aprender a usar imágenes y conceptos de programación gráfica.

Existen varias bibliotecas gráficas con las que empezar, pero mi recomendación es SDL, tiene bastante reputación en el mundo de los videojuegos 2D, es simple y existe mucha documentación. En este apartado es cuando es más difícil encontrar documentación en español, pero existe un gran trabajo en español en forma de wiki perfecto para comenzar en este maravilloso mundo.

• http://softwarelibre.uca.es/wikijuegos/

Esto estupendo tutorial no se limita a mostrat y explicar las características de SDL, sino que trata de explicar el buen uso de la misma y finalmente tiene el desarrollo de un videojuego paso a paso. Totalmente recomendada para iniciarse con gráficos.

4. Sigue aprendiendo

A estas alturas ya habrás aprendido una base y sabrás que camino debes seguir, que cosas debes aprender y como tienes que moverte. En todo momento tienes que estar leyendo, documentándote y aprendiendo es la única forma de poder entrar en este mundo del desarrollo de videojuegos que está avanzando cada día. Para eso te recomiendo un par de webs sobre programación de videojuegos, desgraciadamente, la mayoría en inglés.

• http://gpwiki.org/ – Impresindible tenerla en favoritos para todo programador de videojuegos. La wiki por excelencia del desarrollo de videojuegos.
• http://www.gamedev.net/ – Otra muy importante, comunidad muy activa, te enterarás de las últimas novedades y en los foros siempre hay alguien dispuesto ayudar, siempre que sepas inglés.
• http://www.gamasutra.com/ – A tener muy encuenta, ofertas de trabajo, grandes artículos… Añadela a tu lista de webs a  mirar cada día.
• http://www.stratos-ad.com/ – La comunidad más grande de desarrollo en español. Puedes encontrar muy buenas cosas en los foros.
• http://www.google.com/ – No no es coña, está es la más importante de todas. Lo de arriba es una guía para comenzar, pero te surgirán miles de dudas a cada paso que des. Google es tu amigo, lo sabe casi todo y lo resuelve casi todo si sabes buscar bien. Aprende si no sabes a usar todos los trucos de google. Un programador y más uno de videojuegos debe ser autodidacta y aprender a buscarse la vida en este competitivo y apasionante mundo.

Espero que te sirva de algo esta pequeña guía si quieres adentrarte en el mundo de la programación de videojuegos y no sabias como hacerlo.

• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• [BGE] La clase App
• [BGE] La clase SceneManager
• [BGE] La clase Scene

Muchos de los que me siguen en twitter ya lo habrán visto, pero para todo los demás comunicar que estoy desarrollando un Framework básico para juegos 2D en C++ basado en SFML y otras bibliotecas libres multiplataforma.

La idea no es nueva es la continuación del Basic Game Engine que estaba desarrollando, pero ahora con un enfoque algo más amplio y con esperanza que sea un proyecto de comunidad. Paso a comentar el poryecto.

Objetivo del proyecto

El objetivo es crear un Framework que facilite la programación de videojuegos encargandose de las tareas más típicas y repetitivas, dejando al programador solo la lógica y mecánica del juego.

¿Otro Framework? Ya hay muchos y mejores

No se trata de competir con Frameworks profesionales o con una gran comunidad detrás, véase Cocos2D, que tienen soporte para dispositivos móviles, Sistemas Operativos, etc. La idea de este proyecto es el aprendizaje, enfrentarse a los problemas reales de la programación de videojuegos y poder comentarla en el blog.

¿Qué es exactamente?

Consiste en facilitar las rutinas típicas del desarrollo de videojuegos como control de escenas, gestor de recursos, dibujado de sprites, animaciones, detección de colisiones, dibujado de mapas basados en tiles, física, Scroll Parallax, algoritmos de inteteligencia artificial como PathFinding, etc.

No trata de reinventar la rueda. Usamos herramientas ya hechas y consolidadas. Usamos SFML para la gestión multimedia: ventana, dispositivos de entrada, gráficos, audio y network. PugiXML para el parser de documentos XML, Box2D para tratamiento de física, Tiled Map Editor para realizar mapas basados en tiles. No tratamos de revolucionar estas herramientas sino de crear un marco de trabajo para unirlas y usarlas fácilmente.

Mola, ¿Puedo ayudar?

La idea es que sea un proyecto comunitario que hagan más fácil el trabajo. Que los participantes escriban acerca de lo que hacen y porqué lo hacen así para poder compartirlo con los demás y ganar experiencia. También puedes colaborar usando el Framework para realizar juegos de ejemplos, si te estás iniciando en la programación de videojuegos es la herramienta perfecta pues te ayudará a dar tus primeros pasos en este mundo sin muchas complicaciones.

Si quieres más información puedes entrar en la web del proyecto: http://razonartificial.com/GGE/

• SFML – Instalación y configuración
• Introducción a PySFML
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico

Tileset isométrico de gran calidad para exteriores que combina con los publicados anteriormente, otra vez obra de los chicos del proyecto Flare, un rpg libre que está haciendo estos gráficos de calidad y poniendolos a disposición de todos. Está creado por pfunked y tiene licencia GPL 3.0.

Estos tilesets están pesados para ser usado con el Tiled Map Editor, pero se puede adaptar a cualquier herramienta de cración de mapas.

• Descargar tileset

• Tileset isométrico de gran calidad
• Otro tileset isométrico muy bueno – Cavernas
• Crear tiles isométricos 2D con Blender
• Gráficos para prototipos de juegos
• Pack de gráficos para juegos

Nuestro primer juego

Nuestro primer juego es el típico programa que muestra por consola el mensaje “Hola Mundo” de todos los cursos de programación, pero como esto es un curso de programación de videojuegos vamos a cambiar el mensaje por “Game Over!”.

Pues venga, manos a la obra, abrimos nuestro editor y creamos un archivo llamado main.cpp en realidad puede llamarse como queramos pero es algo establecido que el archivo de entrada a todo programa escrito en C++ se llame main, el .cpp es la estención de los archivos de código de C++.

Dentro del archivo escribimos el siguiente código, es tan corto nuestro juego que lo vamos a copiar del tirón y luego lo explicamos.

#include <iostream>

/*
 * Esta es la función principal del programa.
 * Todo programa escrito en C++ debe de tener una función main.
 */

int main()
{
	// Muestra el mensaje "Game Over!" en la consola
	std::cout << "Game Over!" << std::endl;
	return 0;
}

Antes de explicarlo vamos a compilar y ejecutar. Para el que sea muy nuevo en esto decir que compilar es el proceso de coger un programa escrito en un lenguaje de programación y convertirlo en lenguaje máquina para acontinuación crear un ejecutable, si andas un poco perdido en todo esto te sugiero que busque por internet en cursos básicos, pues se sale del objetivo de este curso.

Como ya dije, yo explicaré como compilar y ejecutar en Linux, si estás en Windows o Mac (en mac es igual que en Linuz al ser un Unix) simplemente busca como se hace en tu Sistema Operativo en cualquier curso o en Google.

En Linux abrimos una consola (en mi caso ya habéis visto que la tengo empotrada en el editor y no necesito cambiar de ventana) y nos situamos en el directorio de nuestro juego que ya debe contener un archivo main.cpp que contiene nuestro código. A continuación pasamos a compilar con g++. Si nunca has compilado por consola no te preocupes, no tiene mucha ciencia y te explicaremos lo necesario.

$ g++ main.cpp -o GameOver

Como vemos simplemente es escribir el comando g++ seguido de los archivos .cpp que se quieren compilar, en este caso main.cpp, opcionalmente tenemos el argumento -o (es la vocal O en minúscula no un 0) mas un texto que será el nombre que tendrá el ejecutable, en este caso lo llamamos GameOver. Ahora simplemente hay que ejecutarlo:

$ ./GameOver
Game Over!

Perfecto, hace justo lo que esperabamos, imprimir por consola el mensaje “Game Over!” ahora vamos a explicar el código.

#include <iostream>

La primera línea utiliza la directiva de preprocesador #include, se que si eres nuevo esto te habrá sonado a chino. Una directiva de preprocesador son unos comandos que están el en código que comienzan por una almoadilla # y que sirven para que el compilador haga ciertas tareas antes de compilar el programa (pasarlo a lenguaje máquina) en este caso la directiva #include sirve para incluir otro archivo dentro del actual, en este caso el archivo iostream que es una bibliteca estándar de C++, La biblioteca estándar de C++ es una coleeción de archivos útiles que contiene código ya escrito de uso muy común como entrada y salida de texto, operaciones matemáticas complejas, etc. En este caso utilizamos la biblioteca iostream que contiene la salida y entrada estándar por consola que no son otras que el monitor y el teclado.

En este caso nosotros la usaremos para utilizar cout que es la salida estandar en C++ y poder imprimir nuestro mensaje de Game Over!.

La segunda linea y la séptima son simplemente líneas en blanco, solo sirven para separar el código estéticamente ya que el compilador pasa de ellas.

La línea 3 a la 6 es un comentario estilo C. Los comentarios estilo C se escriben entre /* y  */  todo lo que haya entre esos dos símbolos el compilador lo ignora. Los comentarios sirven para los humanos podamos entender que hace cierto código. Cuando digo comentarios estilo C es porque como sabréis C++ es un lenguaje evolucionado de C por tanto todo programa escrito en C se podría compilar en C++ y los comentarios de este estilo son los de este lenguaje, en C++ se han incorporado otro tipo que ahora veremos.

La linea 8 es la función main que todo programa en C++ debe tener, cuando el programa se crea esta es la primera linea que se va a ejecutar, podemodemos verla como la puerta de entrada a C++. Las funciones en C++ tienen este aspecto:

tipo nombre(tipo arg1, tipo arg2, ...)
{
    // Cuerpo de la función
    return tipo;
}

Una función es un trozo de código que hace una acción determinada y devuelve un resultado, muy parecido al concepto de función matemática, a las que tu les pasabas un valor y después de operar obetenias un resultado.

En C++ una función se escribe como arriba, primeri el tipo que se refiere al tipo de dato que devuelve, aún no hemos visto los que hay ya los veremos. A continuación el nombre de la función y entre paréntesis una lista de argumentos que ya veremos en mayor profundidad. Luego entre dos llaves va el cuerpo de la función y por último hay que devolver con la sentencia return el resultado que debe ser del tipo que especificamos arriba en la función, a menos que el tipo definido sea void, es decir, vacío que no habría que tener sentencia return.

Si os ha sonado todo esto un poco a chino no os preocupéis de momento, veremos las funciones más en detalle llegado el momento por ahora quedaos con que nos hace falta esas lineas para empezar un programa en C++.

// Muestra el mensaje "Game Over!" en la consola

Este es el otro tipo de comentarios que encontraréis en C++, comienzan con dos barras // todo lo que este a la derecha de esas dos barras es ignorado por el compilador hasta la siguiente línea. Pueden estar junto a una linea de código:

int x = 5; // Asignamos el valor 5 a la variable entera x

Vamos a la siguente línea de código.

std::cout << "Game Over!" << std::endl;

Aquí vemos muchas cosas, lo primero es el uso de cout que como ya dijimos no es una palabra clave de C++ sino que se encuentra dentro de la biblioteca estándar de C++ y se utiliza para sacar mensajes por con sola, el std:: que le precede antes es el espacio de nombre al que pertenece. En este caso el de la biblioteca estándar es std, ya hablaremos de los espacios de nombre más adelante.

Veréis por ahi mucho esa línea así:

cout << "Game Over!\n";

y esta línea añadida en la parte superior del código.

using namespace std;

Es otra forma de hacerlo, quiere decir que vamos a usar el espacio de nombre std y no hace falta estar invocando a sus funciones y/o clases por medio de std:: yo lo desaconsejo totalmente pues al principio puede parecer una manera mucho más fácil, pero cuando te veas trabajando con varios espacios de nombres de varias bibliotecas a la vez será un caos porque llegara un momento en el que no sepas a que espacio de nombre pertenece que y lo mas complicado, puede haber dos bibliotecas con dos clases que se llamen igual. Por ahora no os preocupéis y hacedme caso.

seguimos explicando la línea, la potencia del control de flujos de C++ es algo que se sale de este tutorial, pero explicaremos lo básico que vayamos necesitando. En C++ la salida y entrada de datos se le llama flujo, pues los datos fluyen hacia el programa o hacia fuera, en C++ se usa << para la salida de flujo y el >> para la entrada de flujo, en este caso cout quiere decir que fluya hacia la salida estándar lo que venga a continuación, es este caso es una cadena de carácteres: “Game Over!” las cadenas de caracteres, son eso, sucesiones de letras numero o símbolos puestos entre comillas.

hay una algunos caracteres especiales que se escriben con la barra invertida como son el salto de línea “\n” el tabulador “\t” o las mismas comillas “\”" ya que si quisieramos añadirlas a una cadena sin esta llamada “secuencia de escape” lo que haríamos sería terminar la cadena y daría error. Lo mismo para usar la barra invertida y que no se crea el compilador que es una secuencia de escape.

a continuación de la cadena, queremos añadir mas flujo por lo que volvemos a escribir << y añadimos el siguiente flujo std::endl esto no es mas que el carácter de salto de fin de línea, hace la misma función que el \n, pero es mejor ponerlo así, ya veremos más adelante porque.

return 0;

Por ultimo el return, como dijimos una función debe devolver un valor del tipo pasado, en esta ocasión escribimos int main() por lo que debe ser de tipo int el valor devuelto. Aún no hemos dado los tipos. El tipo int representa a un entero en C++ como puede ser el 1, 100, 4, -5, etc.. todos los números enteros. Por convención se suele hacer que un programa en C++ que termina correctamente debe devolver 0. Por eso hacemos que la función main devuelva 0.

Ya hemos termiando nuestro primer programa, se que muchas cosas se han quedado un poco en el límbo para los más novatos, pero poco a poco iréis comprendiendo mejor.

Ahora podemos coger nuestro juego y modificarlo para aprender a usar el cout y las secuencias de escape, haced algunas pruebas como las siguientes.

#include <iostream>

/*
 * Esta es la función principal del programa.
 * Todo programa escrito en C++ debe de tener una función main.
 */

int main()
{
	// Muestra el mensaje "Game Over!" en la consola
	std::cout << "Game\nOver!" << std::endl; // Con un salto de linea
	std::cout << "\tGame Over!" << std::endl; // Tabulado
	std::cout << "\t\tGame Over!" << std::endl; // Dos tabulaciones
	std::cout << "Game" << " " << "Over!" << std::endl; // Imprime la misma que el original
	std::cout << "\"Game Over!\"" << std::endl; // Entrecomillado
	std::cout << "\\Game Over!\\" << std::endl; // Entre barras invertidas
	std::cout << "Hola Mundooooo!!!" << std::endl; // Otro mensaje

	return 0;
}

Compilarlo, ejecutad y mirar el resultado. Haced todas las pruebas que queráis para aprender a usar el cout que es la salida estándar.

Una última cosa que no he mencionado es que todas las sentencias en C++ deben acabar en punto y como como os habréis fijado. En este caso solo hay dos sentencias que son el cout y el retuen ya que los comentarios y las directivas de preprocesador no cuentan como sentencias. Al igual que los bloques de código que tienen cuerpo (que tienen {}) esto no es del todo cierto pues las clases si que tienen, pero ya veremos las clases a su debido tiempo.

• Curso de Videojuegos en C++ – Presentación
• SFML – Manejando eventos
• SFML – Abriendo una ventana
• SFML – Instalación y configuración
• Una introducción a la STL I – Introducción a los contenedores

Bienvenidos a un nuevo colección de artículos, curso, guía o como lo queráis llamar de Razón Artificial. En esta ocasión la idea es enseñar a programar videojuegos en C++ a base de ejemplos e ir explicando las cosas paso a paso. Me di cuenta que en su día el Curso de Pygame tuvo bastante buena acogida porque en el proceso del tutorial se fue creando un juego, es decir, nos enfrentamos a un problema real y no a casos teóricos, esa es la idea que quiero seguir en estas nuevas entregas.

Qué no es este curso

Antes de nada quiero aclarar que esto no es un curso de iniciación a la programación, ni si quiera un curso de C++, aunque espera, no dejes de leer aún. La idea es ir explicando los conceptos de programación en C++ y de la programación de videojuegos a medida que se avanza. Se empezará elaborando juegos sencillos en modo consola y luego se pasarán a juegos gráficos en 2D, manejo de archivos, inteligencia artificial, etc.

Tampoco es un curso de videojuegos 3D si alguien quiere seguir esto para hacer su propio Final Fantasy o Wordl of Warcraft, es un buen sitio para empezar pero ni de lejos para terminar.

Tengo una duda, ¿Te puedo mandar un correo?

Poder, puedes, pero preferiría que las dudas las discutieramos en los comentarios de cada entrada así ayudaríamos a más usuarios que puedan tener la mismas dudas y ayudaríamos a enriquecer este curso con las aportaciones.

Qué necesitamos

Pues simplemente un compilador de C++ que esté mas o menos actualizado y un editor de texto, no voy a imponer ninguno, cada uno es libre de usar el que quiera. En cuanto al Sistema Operativo, también somos libres de usar el que queramos. Yo por mi parte usaré el Sistema Operativo Ubuntu y para los primeros juegos en modo consola solo usaré el IDE Geany y una consola para compilar y ejecutar los juegos. Cuando pasemos a los juegos gráficos usaré la biblioteca SFML para el control multimedia Gráficos, Audio, Entrada, etc. entonces pasaré a usar el IDE Codelite pues es más fácil para la gestión de proyectos y configurar las bibliotecas. Ambos IDEs son multiplataforma y explicaré como configurarlos tanto en Windows como en Linux. Aunque es muy fácil encontrar en internet muchos más y como configurarlos, eso ya queda a elección de cada uno.

Organización

Yo voy a trabajar de la siguiente manera, he creado una carpeta llamada curso y dentro de ella crearé una carpeta para cada juego que realicemos, así están todos en un mismo lugar y podemos consultar cosas de los juegos anteriores. Respeto a la organización del código en cada juego, lo iremos viendo con cada uno, en los primeros que serán simples no habrá que hacer divisiones, pero en futuros juegos más complejos separaremos en carpetas los archivos de cabecera y los de implementación, las bibliotecas, etc. Pero no os preocupéis llegado el momento todo eso lo explicaremos.

• [Curso C++] – Primer Juego – Game Over!
• SFML – Manejando eventos
• SFML – Abriendo una ventana
• SFML – Instalación y configuración
• Una introducción a la STL I – Introducción a los contenedores

La clase App sigue, como el SceneManager, el patrón de diseño Singleton pues no tiene sentido tener más de un objeto App, cualquier intento de crear un nuevo objeto App devolverá la instancia única.

Empezamos con las variables públicas.

// Constantes
///////////////////////////////////////////////////////////////////////////
static const unsigned int DEFAULT_VIDEO_WIDTH = 640;
static const unsigned int DEFAULT_VIDEO_HEIGHT = 480;
static const unsigned int DEFAULT_VIDEO_BPP = 32;

// Variables
///////////////////////////////////////////////////////////////////////////
/// Título de la ventana
std::string title;
/// Ventana de la aplicación
sf::RenderWindow window;
/// Modo de video (Width, Height, Bpp)
sf::VideoMode video_mode;
/// Opciones de la ventana
sf::WindowSettings window_settings;
/// Estilo de la ventana
unsigned long window_style;
/// Input manager de la ventana
const sf::Input& input;
/// Log de la aplicación
std::ofstream log;
/// Puntero a Scene inicial
Scene* scene;
/// Puntero al SceneManager
SceneManager* scene_manager;

Como vemos lo primero que hacemos es declarar 3 constantes enteras con el modo de vídeo por defecto. Luego pasamos a las variables, están todas explicadas en los comentarios y se entiende su función claramente, cualquier duda podéis preguntar.

como privadas también tenemos unas cuantas.

/// Código de salida de la aplicación
int exit_code;
/// Verdadero si la aplicación se está ejecutando
bool running;
/// Archivo de log de la aplicación
std::string log_file;
/// Reloj que obtiene el tiempo pasado en cada loop
sf::Clock update_clock;
/// Almacena el tiempo pasado en cada bucle
float update_time;

Sin ninguna duda tampoco de la función que cumplen.

Antes de ver los métodos vamos a ver un esquema del ciclo de ejecución y a continuación lo explicamos.

Con la imagen a mano miramos el código de la clase.

• app.h
• app.cpp

Como siempre lo primero que se ejecuta es el constructor que inicializa variables y constantes y creo un archivo de log.

A continuación se llama a ProcessArguments que se encarga de procesar los argumentos pasados por linea de comandos, este método es opcional, pero es útil para cuando se están creando los juegos pasarle comandos que hacen determinadas acciones de pruebas. De momento no está implementado el método simplemente imprime los comandos pasados en el log. La idea es que este método lo implemente el usuario para lo que le interese.

Luego se llama a SetFirstScene que recibe una escena y la establece como la inicial, luego se verá mejor porque hacerlo aquí y así.

A continuación se llama al método Run que es el que ejecuta la aplicación, este método se encarga de llamar a los métodos PreInit, Init, Loop y cleanup.

El método PreInit aún no está implementado, se encarga de leer un archivo de configuración con las opciones de las aplicaciones y con estos datos crear la ventana.

Después se llama al Init, de momento se encarga de crear el SceneManager, se añade la primera escena a la cola y se pone como escena activa. En el futuro aquí se inicializarán también clases que lleven control de fps, etc.

Llegamos al método Loop que suele ser de los más importantes de un juego, aquí se encuentra nuestro bucle que va manejando el juego.

Lo primero que hace nuestro bucle es obtener los eventos del sistema, hay algunos por defecto que se encarga de manejar la aplicación de los que por ahora solo está implementado el de cierre y el resto de eventos se los mandamos a la escena activa.

Luego actualizamos nuestra variable de tiempo pasado en cada ciclo y reseteamos el reloj, recuerda que estas son variables privadas de la escena, pero que hay métodos para obtener este tiempo.

A continuación se llama al método Update de la escena activa y al método Draw, lo típico de todos los juegos.

Por último si recuerdas en el artículo anterior en la clase SceneManager habíamos declarado App como friend, es decir una clase amiga. Esto es que la clase App puede acceder a los miembros privados de SceneManager, la razón de esto es que si revisamos la clase SceneManager el método ChangeScene es privado, este método se encarga de cambiar el puntero de la escena activa a la indicada, si cambiáramos esto a la ligera en medio de una escena podría darnos un problema de memoria.

En lugar de eso tenemos como publico el método SetActiveScene que es el siguiente.

void SceneManager::SetActiveScene(SceneID id_scene)
{
    next_scene = id_scene;
}

simplemente le da un valor a next_scene y luego desde app controlamos el cambio de escena fuera del método update y draw y sin peligro de segmentación de memoria.

// Comprobamos cambios de escena
if (scene_manager->next_scene != "")
{
	scene_manager->ChangeScene(scene_manager->next_scene);
	scene_manager->next_scene = "";
}

tanto la variable next_scene como el método ChangeScene son privados, pero la clase App al ser friend si que puede acceder a ellos. Simplemente se encarga de comprobar si la variable next_scene no esta vacía en cuyo caso llama a ChangeScene y vuelve a vacías next_scene.

Mientras la aplicación se está ejecutando se repite este ciclo.

Por último cuando se sale del loop se entra en el Cleanup que se encarga de las funciones limpieza, llama al RemoveAllScene del SceneManager que a su vez llama al Cleanup de cada escena y luego las elimina. Por último elimina el SceneManager.

Tenemos varios métodos útiles declarados como son.

• IsRunning – Valor booleano si la aplicación se está ejecutando o no.
• GetUpdateTime – Devuelve el tiempo pasado en cada ciclo
• Quit – Para la aplicación con un código de salida

Bueno esto ha sido un repaso general a la clase App. Si algo no se entiende preguntar en los comentarios. En el próximo artículo se vera todo más claro pues crearemos una aplicación de ejemplo.

• [BGE] La clase SceneManager
• [BGE] La clase Scene
• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico
• Guía aprender programar videojuegos con C++

Sobre SceneManager he visto muchas formas de implementarlo, la más común es utilizar una pila donde haciendo push y pop se puede cambiar de escena fácilmente, la desventaja de una pila es la poca flexibilidad para ir de una escena a otra, veamos un ejemplo práctico.

Añadimos una escena inicial:
>> scene_manager->push("SceneStart")
Ahora "SceneStart" es la escena activa.
>> scene_manager->push("SceneMenuPrincipal")
Ahora "SceneMenuPrincipal" es la escena activa.
>> scene_manager->push("SceneGame")
Ahora "SceneGame" es la escena activa
>> scene_manager->pop()
Ahora "SceneMenuPrincipal" es la escena activa

Parece un buen método, es fácil poner una escena y volver a la anterior mediante pop, pero, ¿Y si queremos volver 2 escenas atrás? Pues hacemos 2 veces pop y solucionado, ¿Y si son 15? Esto ya empieza a ser mas engorroso. ¿Y que sucede si queremos hacer push de una escena que ya está en la pila?

Como vemos es un sistema muy rígido que no permite cambiar a la escena que queramos con facilidad.

Mi idea es utilizar un simple array con una lista de escenas inactivas y una variable con un puntero a la escena activa.

/// Escena actualmente activa
Scene* active_scene;
// Lista de escenas inacticas
std::vector<Scene*> inactives_scenes;

Estas dos objetos pertenecen a la clase SceneManager y con diferentes métodos los controlaremos. Puedes ver los diferentes métodos de la clase y su documentación en GitHub

• scene_manager.h
• scene_manager.cpp

Como ves tenemos métodos para añadir escenas, cambiarla, eliminarlas, eliminarlas todas, etc. Todas están perfectamente documentadas, pero si surgen dudas podéis dejar un comentario.

Un detalle es que los métodos ChangeScene y RemoveAllScene son privados. Esto es así por que el primero se encarga de cambiar la variable scene_active y si no se hace en el sitio correcto dentro de la clase App puede haber un error, se verá mejor cuando veamos la clase App. En cuanto a RemoveAllScene hace lo mismo que RemoveAllInactiveScene, pero también destruye la escena activa, se usa como limpieza cuando se termina la aplicación.

Como vemos tenemos a la clase App como amiga, esto es así porque nos interesa que pueda acceder a estos métodos privados y a la escena activa.

Otro detalle importante es que la clase está diseñada con el patrón Singleton, esto hace que solo pueda haber un SceneManager y no se cree más de uno por error.

• [BGE] La clase Scene
• [BGE] La clase App
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico

¿Que es una escena?

Puede parecer obvio, pero por si acaso vamos a aclararlo. Una escena es cualquier pantalla de un juego que necesite mostrarse en pantalla, actualizar datos y/o interactuar con el usuario.

Por ejemplo, una pantalla de inicio donde se muestra un vídeo de introducción al juego sería una escena, se muestra en pantalla, pero no interactúa con el usuario. Un menú de inicio donde podemos empezar un nuevo juego, cargar, salir, etc. sería otra escena de nuestro juego, etc.

Cada escena debe tener unas funciones básicas comunes, estas son:

• Init – Se encarga de inicializar la escena.
• Pause – Es llamado cuando se pausa la escena.
  
• Resume – Es llamado cuando se reanuda la escena.
• Cleanup – Es llamado al eliminar la escena, realiza funciones de limpieza.
• Events – Es llamado para procesar los eventos del sistema.
• Update – Se encarga de actualizar la lógica de la escena, llamado una vez por ciclo.
  
• Draw – Se encarga de dibujar en pantalla, llamado una vez por ciclo.

Estos son algunos de los métodos que tendrá nuestra escena. Cuenta también con otros métodos constantes que devuelven información de la escena.

• GetID – Devuelve el identificador de la escena.
• IsInitComplete – Devuelva true si se ha completado el Init.
• IsPaused – Devuelve true si la escena esta pausada.

Como variables tenemos, los seguientes:

• App* app – Puntero al objeto de la aplicación (Protegido).
• SceneID id – Almacena el id de la escena (Privado).
• bool m_cleanup – Almacena si la escena necesita limpieza.
• bool m_init – Almacena si la escene esta inicializada.
• bool m_paused – Almacena si la escena está pausada.

De todos estos datos el constructor recibe los dos primeros,  Scene(SceneID m_id, App* p_app). Aún no hemos visto la clase App ya veremos luego para qué es este puntero al objeto app. Los otros tres son valores booleanos y se inicializan como false.

Bueno, la explicación está muy bien, pero creo que es mejor que enseñe el código, aquí dejo los enlaces a GitHub de la clase.

• https://github.com/adrigm/Basic-Game-Engine/blob/master/src/BGE/scene.h
• https://github.com/adrigm/Basic-Game-Engine/blob/master/src/BGE/scene.cpp

Como vemos en la implementación (scene.cpp) no están los métodos Events, Update y Draw. De hecho, en la definición de la clase (scene.h) podemos ver que están igualados a 0. Esto es que son funciones virtuales puras, es decir, esta clase no las implementan sino que deben hacerlo las clases que hereden de ella, es decir, las escenas de nuestros juegos. Los otros métodos no constantes también son virtuales, pero tienen una implementación básica necesaria.

En el próximo artículo veremos la clase App. Cualquier duda, dejad un comentario,

• [BGE] La clase SceneManager
• [BGE] La clase App
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico

|- src/
   |- BGE/
      |- BGE.h
      |- types.h
      |- app.h
      |- app.cpp
      |- scene.h
      |- scene.cpp
      |- ...
   |- main.cpp
   |- scene_start.h
   |- scene_start.cpp
   |- ...

Es decir, metemos los ficheros del engine propiamente dichos dentro de la carpeta src/BGE y los archivos de prueba que usamos para ir probando nuestro engine quedan en la carpeta src/.

Esta es la estructura que tendría un juego que use el engine, simplemente añadir la carpeta con los archivos del engine y utilizarlos. Más adelante veremos como convertirlo en bibliotecas para que el Engine no se esté compilando cada vez.

Espacio de nombre BGE

He decidido que toda las clases del engine se encuentren dentro del namespace BGE, la razón de esto es que vamos a trabajar con bibliotecas de desarrollo de videojuegos y estamos haciendo un engine para hacer juegos esto hace que sea muy probable tener nombres iguales en diferentes bibliotecas, por ejemplo, en SFML hay una clase llamada Clock y el engine también tendrá una clase llamada Clock y probablemente cuando se haga un juego con el engine el programador quiera tener su propia clase Clock. Con los espacios de nombre solucionamos el problema de saber a que clase nos estamos refiriendo.

El archivo de encabezado

Basándome en SFML he decidido hacer un archivo de encabezado genérico por módulo, es decir un header que incluya lo necesario para hacer funcionar cada parte del engine. esto sería el ejemplo de como estaría actualmente.

#ifndef BGE_H
#define BGE_H

#include "types.h"

#include "app.h"
#include "scene.h"

#include "clock.h"

#endif // BGE_H

Como vemos incluye las clases de las que hemos hablado y que son básicas para hacer funcionar el engine. No os preocupéis se que aún no hemos entrado en materia con ninguna, en próximos artículos lo haremos.

Tipos propios del engine

En el código anterior verás un archivo del que no hemos hablado el types.h. Este archivo contendrán los tipos específicos creados para el engine. He declarado algunos básicos.

/**
 * Definición de tipos del espacio de nombre BGE
 *
 * @file types.h
 * @author Adrián Guerra Marrero
 * @date 20110422 - Initial Release
 */

#ifndef TYPES_H
#define TYPES_H

#include <string>

namespace BGE
{

// Tipo de dato que representa el ID de una Escena
typedef std::string SceneID;

/// Status Enumeration for Status Return values
enum StatusType
{
	// Values from -99 to 99 are common Error and Good status responses
	StatusAppMissingAsset = -4, ///< Application failed due to missing asset file
	StatusAppStackEmpty   = -3,  ///< Application States stack is empty
	StatusAppInitFailed   = -2,  ///< Application initialization failed
	StatusError           = -1,  ///< General error status response
	StatusAppOK           =  0,  ///< Application quit without error
	StatusNoError         =  0,  ///< General no error status response
	StatusFalse           =  0,  ///< False status response
	StatusTrue            =  1,  ///< True status response
	StatusOK              =  1   ///< OK status response

	// Values from +-100 to +-199 are reserved for File status responses
};

// Forwards Declarations
class App;
class SceneManager;
class Scene;

} // Namespace BGE

#endif // TYPES_H

En primer lugar he declarado el tipo SceneID que no es más que una string que se usará para identificar las escenas, ya lo veremos mejor cuando expliquemos la clase Scene.

Luego tenemos un enumerado con una lista de estados del proyecto, por ahora solo hay definidos algunos básicos. Esto se usa para el return de la aplicación y evitar los números mágicos.

por último tenemos los Fowards Declarations, si no sabes lo que son puedes mirar este artículo en concreto es el problema 2, pero recomiendo leer todo el artículo.

• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico
• [BGE] La clase SceneManager
• [BGE] La clase Scene
• Proyecto Generic Game Engine

Estructura básica de un juego

Se sale de este artículo explicar el desarrollo del bucle de un juego, pero no está mal recordarlo con un simple esquema:

Es un esquema muy simplificado, sin tener en cuenta temas como la velocidad de actualización para diferentes máquinas, etc. Si alguno necesita un tutorial sobre estos conceptos básicos que deje un comentario y haré un tutorial sobre el tema.

Cuando desarrollamos juegos simples este esquema está muy bien, pero cuando necesitamos manejar un proyecto a gran escala se nos empieza a quedar corto, por ejemplo, si necesitamos manejar varias pantallas como un menú, una pantalla de inicio, créditos, etc. este sistema sería bastante engorroso pues habría que estar añadiendo muchas sentencias de control para ver cuando se ejecuta qué y al final no habría forma de continuar del lío que se formaría, ahí es donde entra un gestor de escenas.

Gestor de Escenas

La idea es similar a lo explicado en este artículo con Pygame. Tener una clase abstracta llamada Scene que contenga los métodos virtuales de las diferentes escenas y gestionarlos en el bucle principal a través de un Scene Manager.

Para los que no estéis muy puestos en el tema lo de arriba os sonará a chino, pero con un esquema quizás se vea mejor.

Como vemos existe una clase App que se encarga de de inicializar el engine, carga ventanas, bibliotecas, archivos de configuración, etc.

También contiene una clase llamada SceneManager que se encarga de gestionar las escenas, esta clase cuanta con una lista de escenas inactivas y una Escena activa que con diferentes métodos podemos añadir, eliminar o cambiar, cuando veamos el SceneManager entraremos en detalles.

En el próximo artículo empezamos a ver el código de estas clases.

• Haciendo un Game Engine 2D básico
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] La clase App
• [BGE] La clase SceneManager
• [BGE] La clase Scene

Cuando se está haciendo un programa es normal utilizar la salida estándar para ir poniendo mensajes de resultados parciales y pruebas para ver si las cosas están sucediendo como se esperan. Cuando el software que estamos creando alcanza mayor complejidad estos mensajes no son suficientes, es aquí donde entran los archivos de log. Esto son básicamente ficheros de texto que van guardando esto mensajes para luego poder analizarlos en profundidad.

Hay muchas maneras de crear un archivo de log algunas más complejas y con mas datos como hora, fehcas, colores, etc y otras mas sencillas. Aquí voy a mostrar una manera sencilla de crear uno de estos archivos utilizando las grandes herramientas de control de flujo de C++. Como no hay mucho más que explicar simplemente dejo el código.

#include <string>
#include <fstream>

int main()
{
	// Declaramos las variables
	std::ofstream log;
	std::string log_file;

	// Creamos el archivo de log
	log_file.assign("log.txt");
	log.open(log_file.c_str());

	// Escribimos una línea con el nombre del archivo
	log << "LogFile: " << log_file << std::endl;

	// Escribimos en el log
	log << "Esta es una linea del log" << std::endl;

	// Cerramos el archivo
	log.close();
}

Como ves no es un log con mil pijerías pero es rápido y eficiente, podemos usar simplemente:

log << "Lo que quiera poner en el fichero";

Como lo haríamos con la salida estándar con cout.

El resultado sería un archivo log.txt con el siguiente contenido:

LogFile: log.txt
Esta es una linea del log

Las herramientas de control de flujo de C++ que están en la biblioteca estándar son muy poderosas, en próximos artículos hablaremos más de ellas.

• Una introducción a la STL I – Introducción a los contenedores
• Guía aprender programar videojuegos con C++
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• [BGE] La clase SceneManager

Creando un repositorio

Lo primero que necesitaba era crear un repositorio para el proyecto donde tener un control de versiones y avances, me he decidido por GitHub pues ya he trabajado con Git antes y GitHub es un buen host basado en Git.

Este será el repositorio del proyecto: https://github.com/adrigm/Basic-Game-Engine

Estructura del proyecto

Una de las primeras cosas que uno tiene que decidir es como organizar el proyecto, como distribuir los archivos etc. La idea es que los diferentes módulos del proyecto sean al final Bibliotecas que se puedan añadir sencillamente para crear un juego sobre ellas, pero mientras está en fase de desarrollo no se pueden aislar como bibliotecas.

Otra cosa a tener en cuenta es separar el código fuente de cualquier IDE, compilador o plataforma,

Así que la distribución elegida es la siguiente:

|- Basic-Game-Engine/
    |
    |- src/
        |- BGE/
        |- ficheros.hpp
        |- ficheros.cpp
    |
    |- builds/
        |- cmake/
        |- codelite/
        |- VS2010/
        |- ...
    |
    |- doxygen/
        |- Doxyfile
        |- ...
    |
    |- README
    |- log.txt
    |- Executable

Como puedes ver en principio habrá 3 directorios:

• src - Donde irá el codigo fuente, separados en carpetas según módulos.
• builds - Aquí irán las diferentes carpetas con los ficheros de proyecto de las diferentes ide, yo trabajo con codelite y por ahora solo está configurado para esta IDE, también lo configuraré para Cmake, pero cualquiera puede añadir una carpeta para cualquier otro IDE. En la carpeta del proyecto se deben crear todos los ficheros que necesite la IDE, los .o, etc y generar el ejecutable en el directorio base del proyecto.
• doxygen – Aquí se encuentran los ficheros necesarios para generar la documentación del proyecto.

Por ahora eso son los directorios pensado, conforme crezca el proyecto es posible que se necesiten otros extras.

• [BGE] La clase App
• [BGE] La clase SceneManager
• [BGE] La clase Scene
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] Sistema base del Engine

Hace tiempo vengo planeando hacer un Game Engine básico para juegos 2D, Se que existen muchos en la red y que uno más no va a aportar nada. La idea de hacer uno propio es aprender y ver como se hacen las cosas, de paso iré publicando los avances por si puedo ayudar a alguien.

Yo no tengo experiencia en este tema y probablemente haga burradas y no haga las cosas de la manera más eficiente posible o las diseñe mal, estaría encantado de recibir sugerencias y/o críticas en los comentarios así todos aprendemos más y buscamos los mejores métodos para hacer las cosas.

El Engine

La idea es que sea modular, que cuente con diferentes módulos: Física, IA, Gestión de recursos, etc. Que sea una capa de abstracción para las bibliotecas que use. En principio solo he decidido una biblioteca y es SFML para le manejo multimedia: Ventana, recursos, E/S. En el futuro pienso usar otras bibliotecas como Box2D para temas de física y es posible que alguna dedicada a la Inteligencia Artificial.

Características

Esta lista no es definitiva pues aún está en una fase temprana de desarrollo, pero estás son algunas de las características que se están pensando implementar.

• Escrito en C++ sobre bibliotecas consolidadas para el bajo nivel (SFML, PugiXML, Box2D, etc)
• Gestor de escenas. Cambio fácil y sencillo de diferentes pantallas en un juego.
• Gestión de recursos. Carga fácil de diferentes tipos de recursos y plantillas para que el usuario puede crear sus propios recursos, estos son algunos de los recursos que cargará por defecto el engine:
  • Imágenes. Formatos conocidos: png, jpg, bmp, gif, psd, etc.
  • Audio. Formatos conocidos: mp3, ogg, midi, etc.
  • Fuentes tipográficas.
  • Ficheros de configuración: cfg, ini.
  • Ficheros XML.
  • Mapas en formato TMX (Tiled Map Editor).
  • Scripts en Python (posibles futuras ampliaciones a otros lenguajes de scripts como Ruby o LUA).
• Modular. Se diseñará con la idea de que el engine sea modular, según el juego que se cree puede que sea necesario unas características u otras por lo que no tiene sentido cargar los módulos de física o IA si se está creando un clon del tetris. Estos son algunos de los modulos pensados.
  • App: Módulo principal del engine: Bucle del juego, Gestión de escenas, E/S, Control de la ventana.
  • AssetManager: El manejador de recursos, lo que permite cargar todo lo del punto anterior y definir nuevos tipos de recursos.
  • Física: basado en Box2D.
  • Inteligencia Artificial: Con algoritmos típicos: FSM, Pathfinding, MinMax, etc.
  • GUI. Creación fácil de interfaces del usuarios.
  • Otros. Será posible añadir nuevos módulos fácilmente a modo de plugins.
• Abstracción total de las bibliotecas de bajo nivel: Nada de lidiar con SFML, Box2D u otras bibliotecas, el engine será una capa de abstracción de todas estas bibliotecas.
• Manejo fácil de Animaciones y SpritesSheet.
• Totalmente documentado en español. El código está documentado con Doxygen en español por tanto toda la referencia de clases está en español. Se elaborarán también tutoriales para el manejo del engine.

• [BGE] Sistema base del Engine
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] La clase App
• [BGE] La clase SceneManager
• [BGE] La clase Scene

Si bien muchos programas simples caben en un solo archivo C o Cpp, cualquier proyecto serio va a necesitar dividir el código en varios ficheros con el fin de ser manejable. Sin embargo, muchos principiantes no se dan cuenta hasta que punto esto es importante (Sobre todo por que muchos lo han intentado y les ha dado más problemas que soluciones y decidieron que no merecía la pena el esfuerzo). En este artículo intentaré explicar porqué hacerlo y cómo hacerlo correctamente. Cuando sea necesario, doy une breve explicación de como trabajan los compiladores y enlazadores para ayudar a entender porque se tienen que hacer las cosas de una manera determinada.

Terminología

En este artículo voy a llamar a los ficheros estándar de C y C++ (normalmente con extensión .c o .cpp) “ficheros fuentes”. Esto será para distinguirlos de los “archivos de cabecera” (normalmente con extensión .h o .hpp). Esta terminología es la usada por Visual C++ y la mayoría de los libros. Ten en cuenta que esta diferencia es puramente conceptual, ambos son archivos de texto con código en el interior. Sin embargo, como se muestra en el resto del artículo, la diferencia de como se trata a unos archivos u otros es muy importante.

¿Por qué dividir el código en varios archivos?

La primera pregunta que los programadores novatos se hacen cuando ven un directorio lleno de archivos de código es ¿Por qué no un solo archivo? No entienden el sentido de separar el código en varios ficheros.

Dividir cualquier proyecto de tamaño razonable tiene algunas ventajas, siendo las más significativas las siguientes:

• Acelerar la compilación. La mayoría de compiladores trabajan en un solo archivo a la vez. Así que si tenemos 10.000 líneas de código en un solo archivo y cambiamos una línea para compilar nuestro programa necesitamos volver a procesar y compilar 10.000 líneas de código. Sin embargo, si 10.000 líneas de código se distribuyen uniformemente en 10 archivos, si cambiamos una línea solo tendremos que volver a compilar 1000 líneas de código, ahorrando tener que compilar las 9000 líneas restantes del resto de ficheros.
• Aumenta la organización. Dividir el código en una línea lógica hará el trabajo más fácil para ti (O cualquier programador del proyecto) para encontrar variables, clases, estructuras, funciones, etc. Imagina que usas la función de búsqueda de tu editor para encontrar una parte del código, si tienes un fichero llamado juego.cpp tendrás que buscar a lo largo de todo el código, sin embargo, si tienes tu juego dividido en 4 ficheros del tipo graphics.cpp, main.cpp, audio.cpp e input.cpp, si quieres buscar algo relacionado con el sonido sabrás donde buscar reduciendo en 3/4 tu búsqueda.
• Facilita reutilizar código. Si el código está cuidadosamente dividido y los archivos son independientes unos de otros te permite reutilizarlos en otros proyecto ahorrándote mucho trabajo en el futuro. Hay muchas más cosas necesarias para poder reutilizar el código, pero sin una buena organización es difícil saber que partes van a trabajar juntas y cuales no. Por lo tanto, poner los subsistemas y clases en ficheros independientes ayuda a portar el código a otros proyectos fácilmente.
• Compartir código entre proyectos. En principio es el mismo tema que la reutilización, pero hay ocasiones que el mismo archivo se usa en varios proyectos en vez de simplemente copiar y pegar, esto facilita que si se corrigen errores o se cambia algo no se tenga que modificar cada copia del archivo y te aseguras de que ambos proyectos utilizan la última versión del código.
• Dividir las tareas entre los programadores. En proyectos grandes donde trabajan varios programadores no es factible trabajar todos en el mismo fichero, la separación de código facilita que cada uno pueda dedicarse a una parte sin interferir en las demás. Por supuesto, puede darse el caso de que dos quieran modificar el mismo archivo a la vez, para ello existen el software de control de versiones como SVN, GIT, Mercurial…

Todo lo anterior son aspectos de modularidad, un elemento clave tanto en el diseño estructurado como orientado a objetos.

Como hacerlo. Los Fundamentos

Es probable que te estés convenciendo de que hay que dividir el código, ahora la cuestión es cómo hacerlo. Aunque algunas de las decisiones que tome serán razonablemente arbitrarias hay algunas reglas básicas que debería seguir para asegurar el trabajo.

En primer lugar, mirar como dividir el código en secciones. A menudo se separa en subsistemas o “módulos” como el sonido, música, gráficos, manejo de ficheros, etc. Crea nuevos ficheros con nombres significativos para saber a simple vista que contiene, a continuación mueva todo el código que pertenece al módulo a ese archivo. A veces no está claro que pertenece a cada módulo (Algunos te dirían que es por un mal diseño de su software).

Una vez dividido el código en archivos fuentes el siguiente paso es considerar que meter en el archivo de cabecera, en un nivel simple, lo que suele estar en la parte superior del código es un serio candidato a ir al archivo de cabecera, de ahí a que se llamen así.

Los archivos de cabecera suelen incluir algunas o todas de las siguientes cosas:

• Definición de estructuras y clases.
• Definición de tipos (typedef).
• Prototipos de funciones.
• Variables Globales (ver más adelante).
• Constantes
• Macros #define.
• Directivas #pragma.

(Además, deberías incluir las plantillas y las funciones en línea. Esto debería quedar claro al terminar este artículo).

Por ejemplo, mira cualquier biblioteca estándar que venga con el compilador que uses. Stdlib.h es un buen ejemplo (ver aquí). Te darás cuenta que tiene algunas de las cosas mencionadas en la lista de antes. Del mismo modo puedes ver que las variables globales están precedidas por el modificador extern, esto es importante, pero lo veremos más adelante.

En general será necesario tener un archivo de cabecera para cara archivo de código fuente, si tienes un sound.cpp tendrás un sound.h, si tienes un sprite.cpp tendrás un sprite.h. Mantener siempre el mismo orden es importante. Saber lo que va en el archivo de cabecera y lo que va en el archivo fuente.

Estos archivos de cabecera se convertirán en la interfaz entre los subsistemas. Al incluir (#include) un archivo de cabecera en otro archivo tendrás acceso a todas las funciones, clases y tipos declarados en ella. Por lo tanto en todos los archivos que uses sprintes probablemente tengas que incluir sprite.h en cada uno de ellos. Recuerda usar #include “sprite.h” y no #include <sprite.h> para que busque en el directorio del proyecto y no en la biblioteca estándar.

Recuerda que, en lo que al compilador se refiere, no existe ninguna diferencia entre un archivo de cabecera y un archivo de código fuente, para el compilador ambos son archivos de texto que contienen código y tratarán igual, la diferencia es puramente conceptual y para los programadores. Los archivos de cabecera deben contener la interfaz, es decir, la definición de lo que contienen los archivos de código fuentes. Estos son los que contienen las funciones, clases y demás. Esto significa que un archivo fuente utiliza otros archivos fuentes gracias a los archivos de cabecera, estos hacen de enlace entre unos y otros.

Dificultades potenciales

Las reglas anteriores son bastante vagas y sólo sirven como punto de partida para organizar el código. En casos sencillos, se puede producir por completo los programas de trabajo siguiendo las directrices. Sin embargo, hay algunos detalles más que han de tenerse en cuenta, y es a menudo estos detalles los que causan a los programadores noveles tanto dolor, cuando comienzan a dividir su código hasta en los archivos de cabecera y los archivos normales.

En mi opinión hay cuatro errores básicos de los que entran en el turbio mundo de los archivos de cabeceras definidos por el usuario:

• La fuente de los archivos ya no compila ya que no pueden encontrar las funciones o variables que necesitan. (Esto a menudo se manifiesta en forma de algo parecido a un “error C2065: ‘MyStruct’: identificador no declarado”. En Visual C++, aunque esto puede producir cualquier número de mensajes de error diferentes en función de exactamente lo que están tratando de referencia)
• Dependencias cíclicas. Cuando dos encabezados tienen la necesidad de incluirse entre sí. Por ejemplo la clase sprite incluye un puntero a la criatura que representa y la clase de la criatura necesita un puntero a la clase sprite. No importa como lo hagas ambas deben ser declaradas antes de usarse, pero a la fuerza cuando una se está declarando la otra no ha sido declarada aún.
• Duplicar las definiciones. Imagina que tienes un archivo llamado map.h que incluye los archivos sprite.h y hero.h, a su vez hero.h incluye sprite.h por lo que sprite.h se incluiría dos veces en map.h, provocando un error.
• Duplicado las instancias de los objetos dentro del código que compila bien. Este es un error vincular, a menudo difícil de entender.

Entonces, ¿cómo solucionar estos problemas?

Solución problema 1

Afortunadamente, estos problemas son fáciles de arreglar, y aún más fácil de evitar, una vez que las entienda.

El primer error, en un archivo de origen se niega a compilar porque uno de los identificadores fue declarado, es fácil de resolver. Simplemente incluye (#include) el archivo que contiene la definición del identificador que usted necesita. Si sus archivos de cabecera están organizados de forma lógica y llamado así, esto debe ser fácil. Si es necesario utilizar la estructura Sprite, entonces es probable que tenga que incluir “sprite.h” en todos los archivos que lo hace. Un error que los programadores suelen tener es asumir que es un archivo ha sido incluido porque está incluido en otro archivo ya incluido, un ejemplo.

/* Header1.h */
#include "header2.h"
class ClassOne { ... };

/* Header2.h */
class ClassTwo { ... };

/* File1.cpp */
#include "Header1.h"
ClassOne myClassOne_instance;
ClassTwo myClassTwo_instance;

En este caso File1.cpp compila bien ya que incluye a Header1.h e indirectamente (a través de Header1.h) también incluye a Header2.h, pero en el futuro alguien puede decidir que Header1.h no necesita incluir a Header2.h. Esto hará que se rompa File1.cpp la próxima vez que compiles al no tener la declareción de ClassTwo.

La solución está en incluir siempre los archivos necesarios explícitamente en el archivo que son necesarios y no confiar en que otros archivos incluidos ya lo incluyen, esto además ayuda a entender y documentar el código pues se ve que archivos necesita ese fichero en concreto para funcionar.

Solución Problema 2

Las dependencias cíclicas son un problema común en la ingeniería de software. A menudo se necesita que una clase o estuctura conozca la existencia de otra y esta de la primera, esto termina con el siguiente aspecto.

/* Parent.h */
#include "child.h"
class Parent
{
    Child* theChild;
};

/* Child.h */
#include "parent.h"
class Child
{
    Parent* theParent;
};

Dado que uno de ellos tiene que ser compilado en primer lugar, necesita alguna manera de romper el ciclo. En este caso, de hecho es bastante trivial. La estructura de Parent en realidad no necesita saber los detalles de la clase del Child, ya que sólo se almacena un puntero a una. Los punteros son casi lo mismo no importa lo que apuntan, por lo tanto no es necesario que la definición de la estructura o la clase con el fin de almacenar un puntero a una instancia de esa estructura o clase. Así que la línea #include no es necesario. Sin embargo, sólo tiene que sacarla para tener un “identificador no declarado” error cuando se encuentra con la palabra Child, así que tienes que dejar que el compilador saber que Child es una clase a la que desea apuntar. Esto se hace con una declaración adelantada (forward declaration), tomando la forma de una definición de clase o de clase sin un cuerpo. ejemplo:

/* Parent.h */
class Child; /* Forward declaration of Child; */
class Parent
{
    Child* theChild;
};

Observa como sustituimos la línea #include por la declaración adelantada, igualmente podemos hacerlo en el archivo Parent.h, esto, además, ahorra tiempo de compilación ya que es un #include menos que tratar. Como solo estamos utilizando un puntero y no el tipo en sí no necesita la declaración entera. En el 99% de los casos esto se puede aplicar a uno o ambos archivos para romper las dependencias cíclicas.

Por supuesto, en los archivos fuentes, habrá funciones que se aplican a Parent que modifican también a Child. Por lo tanto es probable que haya que incluir Parent.h y Child.h tanto en Parent.cpp como en Child.cpp Click para ver la imagen.

Tenga en cuenta que ser capaz de eliminar completamente la dependencia no siempre es posible. Muchas de las clases y las estructuras están compuestas de otras clases y las estructuras, que es una dependencia no se puede evitar. Sin embargo, siempre que esta dependencia es de un solo sentido, el orden de compilación será fijo y no debería haber ningún problema.

Solución Problema 3

Duplicar definiciones en tiempo de compilación significa que un archivo de cabecera terminó incluyéndose más de una vez en un archivo en particular. Esto lleva a que una clase o estructura se define más de una vez, causando error. Lo primero que debes hacer es asegurarte de que se incluyen solo los archivos necesarios para ese código fuente en particular y quitar todo lo que no utilice.

Lamentablemente, esto rara vez es suficiente, ya que algunas cabeceras se incluyen otras cabeceras. Vamos a revisar un ejemplo de las anteriores, con ligeras modificaciones:

/* Header1.h */
#include "header3.h"
class ClassOne { ... };

/* Header2.h */
#include "header3.h"
class ClassTwo { ... };

/* File1.cpp */
#include "Header1.h"
#include "Header2.h"
ClassOne myClassOne_instance;
ClassTwo myClassTwo_instance;

Por alguna razón tanto Header1.h como Header2.h incluyen a Header3.h, quizás ClassOne y ClassTwo se compenen con funciones de Header3.h. La razón no es importante, pero muchas veces sucede casos como estos en los que al final en File1.cpp se acaba incluyendo dos veces el mismo archivo incluso sin haber una #include a él en el mismo archivo, recuerda que la directiva #include lo que hace es, antes de compilar, copiar todo el contenido del archivo incluido en el archivo actual. así que File1.cpp quedaría de la siguiente manera.

A los efectos de la compilación, File1.cpp termina con copias de Header1.h y Header2.h, los cuales incluyen sus propias copias de Header3.h. El archivo resultante, con todas las cabeceras de expansión en línea en su archivo original, se conoce como una unidad de traducción. Debido a esta expansión en línea, todo lo declarado en Header3.h va a aparecer dos veces en esta unidad de traducción, causando un error.

Así que, ¿qué hacer? No se puede hacer sin Header1.h o Header2.h, ya que se necesita para acceder a las estructuras declaradas en su interior lo que necesita alguna forma de asegurar que, no importa qué, Header3.h no va a aparecer dos veces en el File1.cpp cuando se compila.

Si se miraba stdlib.h antes, te habrás dado cuenta las líneas en la parte superior similar a lo siguiente:

#ifndef _INC_STDLIB
#define _INC_STDLIB

Y en la parte inferior del archivo, algo así como:

#endif  /* _INC_STDLIB */

Esto es lo que se conoce como un “inclusion guard”. Viene a decir que si no está definido _INC_STDLIB defínelo, sino, ve a #endif sería similar al código cuando quieres que algo se ejecute solo una vez.

static bool done = false;
if (!done)
{
    /* Do something */
    done = true;
}

Durante la compilación de File1.cpp, la primera vez que pide que se incluya el archivo stdlib.h, llega a la línea #ifndef y continúa porque “_INC_STDLIB” aún no está definida. La siguiente línea define ese símbolo y lleva a cabo la lectura en stdlib.h. Si hay otra “#include” durante la compilación de File1.cpp, leerá el cheque #ifndef y luego salta a #endif al final del archivo. Esto se debe a todo lo que entre el #ifndef y #endif se ejecuta sólo si “_INC_STDLIB” no está definido, y que se definió la primera vez que lo incluye. De esta manera, se garantiza que las definiciones en stdlib.h sólo son cada vez incluye una vez al ponerlos dentro de #ifndef / #endif.

Esto es trivial para aplicar a sus propios proyectos. Al comienzo de cada archivo de cabecera que usted escribe, escribe lo siguiente:

#ifndef INC_FILENAME_H
#define INC_FILENAME_H

Tenga en cuenta que el símbolo (en este caso, “INC_FILENAME_H”) tiene que ser único a través de su proyecto. Es por esto que es una buena idea de incorporar el nombre del archivo en el símbolo. No agregue un guión bajo al principio como stdlib.h tiene como identificadores precedidos por un guión bajo se supone que son reservados para “la aplicación” (es decir, el compilador, las librerías estándar, y así sucesivamente). Luego se agrega el #endif / * INC_FILENAME_H * / al final del archivo. El comentario no es necesario, pero le ayudará a recordar a que pertenece ese #endif.

Solución Problema 4

Cuando el enlazador trata de crear un archivo ejecutable (o biblioteca) de su código lo que hace es meterlo todo en un archivo objeto (.obj o .o), uno por cada archivo de código fuente y los une. El trabajo principal del enlazador es resolver los identificadores (básicamente, las variables o los nombres de funciones) y convertirlas en direcciones máquina en el archivo final. El problema surge cuando el enlazador en cuentra dos intancias o más de ese identificador en los archivos objetos, entonces no se puede determinar cual es el “correcto” para su uso. El identificador debe ser único para evitar cualquier ambigüedad, Así que ¿Cómo es que el compilador no ve que hay un identificador duplicado y el enlazador si lo ve?

Imagina el siguiente código:

/* Header.h */
#ifndef INC_HEADER_H
#define INC_HEADER_H
int my_global;
#endif /* INC_HEADER_H */

/* code1.cpp */
#include "header1.h"
void DoSomething()
{
    ++my_global;
}

/* code2.cpp */
#include "header1.h"
void DoSomethingElse()
{
    --my_global;
}

La primera se compila en dos archivos objeto, probablemente llamado code1.obj y code2.obj. Recuerde que una unidad de traducción contiene una copia completa de todos los encabezados incluidos en el archivo que está compilando. Finalmente, los archivos de objetos se combinan para producir el archivo final.

Aquí hay una representación visual de la forma en que estos archivos (y su contenido) se combinan:

Note que hay dos copias de “my_global” en ese bloque final. Aunque “my_global” fue único para cada unidad de traducción (esto sería garantizada por el uso de los guardias de inclusión), que combina los archivos objeto generados por cada unidad de traducción se traduciría en que haya más de una instancia de my_global en el archivo. Esto se marca como un error, ya que el enlazador no tiene manera de saber si estos dos identificadores son en realidad una misma, o si uno de ellos era mal llamado justa y que se supone en realidad que es de 2 variables independientes. Así que hay que arreglarlo.

La respuesta no consiste en definir las variables o funciones en los archivos de cabecera en lugar de los archivos fuentes, donde estás seguro que se compilan solo una vez. Esto trae un nuevo problema, ¿Cómo hacer las funciones y variables visibles globalmente si no se encuentra en un archivo de cabecera? ¿De qué manera la pueden “ver” otros archivos? La respuesta es declararlas en los archivos de cabecera, pero no definirlas. Esto permite al compilador saber que la función o variable existe, pero delega el acto de de asignarle una dirección al enlazador.

Para hacer esto para una variable, se añade ‘extern‘ la palabra clave antes de su nombre:

extern int my_global;

El especificador ‘extern‘ es como decirle al compilador que esperar hasta el tiempo de enlace para resolver la “conexión”. Y para una función, simplemente hay que poner el prototipo de función:

int SomeFunction(int parameter);

Las funciones se consideran “extern” por defecto por lo que se acostumbra a omitir el ‘extern’ en un prototipo de función.

Por supuesto, estas son sólo las declaraciones de que my_global y SomeFunction existen en alguna parte. En realidad, no los creas. Todavía tiene que hacer esto en uno de los archivos de origen, de lo contrario aparecerá un error de vinculador nuevo cuando se descubre que no puede resolver uno de los identificadores a una dirección real. Así que para este ejemplo, tendría que añadir “int my_global” a cualquiera de Code1.cpp o Code2.cpp, y todo debería funcionar bien. Si se trata de una función, deberá añadir la función como su cuerpo (es decir, el código de la función) en uno de los archivos de origen.

La regla aquí es recordar que los archivos de cabecera define una interfaz, no una implementación. En ellas se indica que las funciones, variables y objetos existen, pero no se hace responsable de su creación. Ellos pueden decir lo que una estructura o clase debe contener, pero en realidad no debe crear instancias de esa estructura o clase. Se puede especificar los parámetros de una función y se lo devuelve, pero no cómo se obtiene el resultado. Y así sucesivamente. Esta es la razón por la que la lista de lo que puede entrar en un fichero de cabecera al principio de este artículo es importante.

Hay dos notables excepciones a no incluir el cuerpo de las funciones en los archivos de cabecera:

La primera excepción es la de funciones de la plantilla. La mayoría de los compiladores y enlazadores no puede manejar plantillas se definen en archivos diferentes a la que se utilizan en, por lo que las plantillas casi siempre es necesario definir en un encabezado para que la definición se puede incluir en todos los archivos que necesita para usarlo. Debido a la forma de plantillas se crea una instancia en el código, esto no conduce a los mismos errores que se podrían obtener mediante la definición de una función normal en un encabezado. Esto es así porque las plantillas no se compilan en el lugar de la definición, sino que se compilan, ya que son utilizados por el código en otros lugares.

La segunda excepción es las funciones en línea, mencionó brevemente antes. Una función en línea se ha compilado en el código, en vez de llamadas de la forma habitual. Esto significa que cualquier unidad de traducción que ‘llama “el código de una función en línea tiene que ser capaz de ver el funcionamiento interno (es decir, la puesta en práctica) de esa función con el fin de insertar el código de esa función directamente. Esto significa que un prototipo de función sencilla no es suficiente para llamar a la función en línea, lo que significa que donde quiera que normalmente sólo tiene que utilizar un prototipo de función, se necesita el cuerpo de la función general de una función en línea. Al igual que con las plantillas, esto no causa errores de vinculador como la función en línea no es realmente compilado en el lugar de la definición, pero se inserta en el lugar de la llamada.

Otras Consideraciones

Por lo tanto, el código está muy bien dividido en varios archivos, que le da todos los beneficios mencionados en el inicio como la velocidad de compilación de una mayor y mejor organización. ¿Hay algo más que necesitas saber?

En primer lugar, si estás usando la biblioteca estándar de C++ (STL) o cualquier otra biblioteca que utilice espacios de nombres, no utilice la se sentencia “using” en los archivos de cabecera pues reducirás la utilidad de los espacios de nombres casi por completo, es mejor usar el identificador del espacio de nombre en cada función u objeto que uses, así tienes la ventaja de saber a que biblioteca pertenece ese código y no tendrás problemas de superponer nombres de funciones propias que te hagan rectificar el código.

En segundo lugar, el uso de macros debe ser cuidadosamente controlado. Los programadores de C tienen que confiar en las macros de un montón de funcionalidades, pero los programadores de C++ debe evitarlos siempre que sea posible. Si desea una constante en C + +, utilice la palabra clave ‘const’. Si desea una función en línea en C++, utilice la palabra clave ‘inline’. Si desea una función que opera sobre los diferentes tipos utilice plantillas o sobrecarga. Pero si necesitas utilizar una macro, por alguna razón, y lo coloca en un fichero de cabecera, trate de no escribir macros que podrían interferir con el código en los archivos que se incluyen. Cuando se producen errores extraños de compilación, no quiero tener que buscar a través de todos los archivos de cabecera para ver si alguien utiliza un # define para cambiar inadvertidamente su función o sus parámetros a otra cosa. Así que siempre que sea posible, mantener las macros de cabeceras a menos que usted puede estar seguro de que no les importa que afecta a todo en el proyecto.

original: http://www.gamedev.net/page/reference/index.html/_/reference/programming/languages/c-and-c/organizing-code-files-in-c-and-c-r1798

• Guía aprender programar videojuegos con C++
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• [BGE] La clase SceneManager
• [BGE] La clase Scene

Unity3D es un game engine gratuito, el cual podemos descargar, usar y gratuitamente exportar (ya sea para su comercialización o liberación gratuita) juegos para ordenador o para la web escribiendo código una vez y obteniendo resultados para varias plataformas. Lo bueno es que podemos adquirir diversas licencias que nos permiten exportar a Android, iPhone, MacOS, Playstation 3 y Xbox 360.

El motor implementa un completo editor de escenarios que nos permite arrastrar y colocar objetos en 3D para animarlos de forma fácil, y para esta tarea podemos utilizar algunos programas de diseño 3D como Blender, Maya, Cinema 4D, 3ds Max, entre otros.

Por otro lado, el editor nos permite trabajar fácilmente con algunos componentes como partículas, colisiones, audio y física y lo más importante es que el editor de escenarios nos proporciona una gran cantidad de opciones para ahorrar tiempo creando los terrenos, por ejemplo, nos permite añadir fácilmente agua o crear elevaciones de terreno en unos segundos.

En cuánto a la programación, Unity3D nos permite trabajar con 3 lenguajes: Javascript, C# y una implementación de Python. Por otro lado los precios varían mucho dependiendo de la plataforma, por ejemplo podemos comprar la licencia pro que nos permite exportar el juego a varias plataformas a $1.500 dólares, o la versión para exportar a iPhone o Android a $400.

En sí este motor resulta ser una gran alternativa al Unreal Engine sobre todo porque la calidad de los juegos que se pueden realizar con el mismo es realmente alta y dichos resultados se pueden lograr en muy poco tiempo.

Algunos enlaces interesantes sobre Unity3D

• UnitySpain – Comunidad y foros de Unity3D en español.
• Información, guías y tutoriales de Unity3D en español.
• Demos de juegos en Unity3D.
• Videotutoriales de Unity3D en inglés.
• Sitio oficial de Unity3D.

• No hay entradas relacionadas.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

El Daimyo era la figura en el entorno feudal japonés que poseia un terreno y se encargaba de administrarlo. Cuando no estaban en guerras con el resto de Daimyos era porque uno de ellos habia asumido el rol de Shogun o repartidor de palos máximo, en cuyo caso el resto tenian que dar buena cuenta de lo que se cocía en su territorio. De cualquier modo, la visión del daimyo que reparte la pana en su tierra y que debe cumplir con una serie de peticiones del Shogun en materia de tributos es la que nos interesa a nosotros. Nos vamos a dedicar a construir un Daimyo para nuestro sistema de entretenimiento de estrategia en tiempo real. Veamos que tenemos que tener en cuenta para crear el azote de los recolectores.

Respecto a los que habeis seguido la distribución de comportamiento mediante comandantes que ya hemos visto en otros artículos vereis que aqui vamos a tratar acerca del Comandante de Recursos. El que va a encargarse de distribuir las responsabilidades entre las unidades de recolección y de proveer al resto. Temas como la creación de unidades o la distribución de las mismas serán problemas a tener en cuenta.

Antes de nada hay que diferenciar entre el análisis desde el punto de vista de una inteligencia artificial que sigue las reglas establecidas y una que no. La primera se refiere a aquella que tiene la misma información que el usuario de modo que juega ‘limpio’ teniendo en cuenta que la IA no tiene la capacidad de un cerebro humano por lo que ya jugar limpio implica que los oponentes tienen capacidades muy diferentes, es decir, juegarían en diferentes categorias. Aqui lo que queremos es dar una visión del enfoque científico donde las pirulas no se deben tener en cuenta. Sin embargo, para estar a la orden del dia en lo referente al ámbito comercial, le vamos a dar un repaso al tema del trampeo en lo que se refiere al tema de minado de recursos.

Introducción a la extracción de recursos

Como en la vida real, de la correcta disponibilidad de los materiales dependerá la velocidad de desarrollo del juego y el desempeño de nuestra estrategia. Extraer recursos es una tarea que implica un nivel de organización amplio y que requiere de una serie de estructuras que soporten la posibilidad de que la lógica del sistema vaya creciendo sin que el acoplamiento y las dependencias entre los diferentes elementos crezcan de una forma inapropiada.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Para llevar a cabo las tareas, se tienen en cuenta varias necesidades. Por un lado la necesidad de calcular con exactitud el número y la proporción de recursos necesarios para llevar a cabo la estrategia. Por otro, la necesidad de determinar los elementos necesarios para llevar a cabo la extracción con un ratio tiempo/unidades válido. Y finalmente la distribución y comando de las unidades asignadas a recursos o energías no renovables.

Número óptimo de unidades

Para calcular el número óptimo de unidades necesitamos tener una medida de lo que estas deben llevar a cabo. En términos generales se pretende que a partir de una medida de los requisitos de cada uno de los elementos que controlan la lógica del sistema (comandantes de construcción, de exploración, de guerra o cualquier otro que definamos), generemos una solución que permite obtener los recursos necesarios en un tiempo determinado.

El administrador de recursos será la pieza clave en todo el desarrollo y cumplirá con las tres tareas principales que hemos visto: calcular recursos, crear unidades de recolección y distribuirlas. La forma en la que trabaja este elemento lógico es adquiriendo peticiones, ejecutando acciones para llevar a cabo la adquisición y traspasando estos recursos obtenidos.

Vale la pena comentar que el administrador o comandante de recursos está apoyado por el comandante de exploración que se ha definido anteriormente y que marca un mapa interno con las posiciones de los recursos a minar. Pequeños ajustes en este comandante harán que este administrador disponga de más o menos opciones a la hora de distribuir las unidades.

La proporción exacta de cada elementos. La petición del material

En nuestro sistema, será posible disponer los diferentes elementos en muchas configuraciones y estructuras diferentes. Para este tipo de sistemas, la distribución jerárquica es muy apropiada por lo que distribuiremos el comportamiento bajo este paradigma. Como se ha visto anteriormente en el artículo de “Comandantes y Subcomandantes para el control de comportamiento”, para cada comandante hay un superior que monitoriza las acciones y determina la estrategia de la partida, este es el Comandante General o General a secas.

De el General cuelgan de forma jerárquica los diferentes comandantes. Para simplificar vamos a considerar 3 de ellos. El subcomandante de exploración, el de extracción de recursos y el de batalla. Ya podemos identificar que los 3 tienen necesidad de recursos.  El lugar idoneo para colocar un gestor de los mismos es en el General. De este modo cada subcomandante comunica a su superior los recursos que necesita para llevar a cabo su estrategia. El modelo jerárquico permitirá que varias capas de jerarquía vayan aglutinando los recursos necesarios conforme se sube en el escalafón hasta llegar al nivel superior que determina la estrategia general, el Shogun que comentabamos antes.

Cada clase subcomandante, por lo tanto,  tendrá una función que vincula al General y se resume en:

peticionDeRecursos(proporción tipo0, proporción tipo1 … proporción tipoN)

por ejemplo:

// 100 unidades de oro, 200 de madera y 100 de piedra.
peticionDeRecursos(100, 200, 100);

Una pequeña variación de comandante será esta:

La clase General tendrá una estructura que permite anotar estos requisitos y facilitarlos cuando sea necesario. Vemos como.

Como repartir los recursos entre los diferentes elementos lógicos

Cuando tenemos registradas las peticiones de cada subcomandante podemos abordar el problema desde dos puntos de vista diferentes.

El primero de ellos es seguir una estrategia general y suministrar los recursos en base al estado de la partida (fase inicial, desarrollo, defensiva o ataque… o cualquier otra distribución). De este modo se asigna un porcentaje concreto de distribución de recursos que varía constantemente conforme varía el estado de la partida.

El segundo punto de vista es el de las ‘Proporciones dinámicas’. En este caso, el cálculo se hace en base a la suma de todas las peticiones realizadas por los diferentes comandantes de modo que si la suma de de los recursos de un material se dobla, los esfuerzos a realizar por las diferentes unidades también se doblarán.

Una estrategia diferente es la de llevar una lista de las peticiones de cada subcomandante y servirlas de forma ordenada conforme se van adquiriendo los recursos. Esta opción es más costosa de modificar en caso de cambio de estrategia por lo que se utilizará en aquellos
casos que no representen una complejidad importante o en el que los estados de juego no varien de forma importante.

Parámetros para la creación de unidades de recolección óptimas

Uno de los elementos clave es la creación de unidades y su distribución. Podemos hacer cálculos sencillos definiendo un porcentaje fijo de los recursos que extraemos y creando un número concreto de cada unidad de juego o podemos estimarlas en base a un cálculo más ‘inteligente’.

Para un cálculo más elaborado tendremos que tener en cuenta una serie de medidas que pueden estar o no disponibles y que ajustaremos acorde a nuestro sistema.

• Total de las demandas de cada subcomandante. Ct
• Recursos disponibles actuales cedidos por el General. Rd
• Coste de las unidades de recolección, simplificamos con una. Ur
• Velocidad de desplazamiento de las unidades. Vu
• Tiempo de recolección de las unidades. Trec
• Tiempo de construcción de cada recolector. Tc
• Distancia Euclidea media a cada tipo de recurso (simplificamos a un solo tipo). De1
• Tiempo estimado de consecución de los objetivos actuales. Te

El número de trabajadores será, escalado a cada proporción de recursos respecto el total Cd (suponemos solo un tipo):

Suponemos que el Te = (Tiempo de construcción TiC) + (Tiempo de minado total TiM). Este es el peor de los casos ya que podemos construir en paralelo mientras vamos minando, sin embargo es una buena aproximación.

Sea el tiempo de recolección que requiere un trabajador para minar todos los recursos (tiempo en llegar, recolectar y volver medio).

T1t = Ct/(Trec+Tdesp);

Tiempo de desplazamiento medio:

Tdesp = De1 / Vu; (x = vt <– ¿suena esta?)

Se calcula el TiM (Tiempo que tenemos disponible para minar) como:

TiM = Te – TiC; 

En un primer paso no conocemos el tiempo de construcción ya que no sabemos cuantos construiremos por lo que marcamos un determinado porcentaje del tiempo esperado de recolección que inicialmente representa un estimador de la velocidad que queremos darle a la extracción y por lo tanto al juego. de este modo:

//Iniciamos con un factor alto y vamos disminuyendo, por ejemplo 0.8.
//Quiere decir que tenemos la espectativa de dedicar el 20% del tiempo a construir en un primer plano.
TiM = factor*Te; 

Y marcamos el número de trabajadores inicial como Nt:

Nt =  TiM / T1t;

Desde este punto monitorizaremos la entrada de recursos y ampliaremos o disminuiremos en función de la carga de los recursos y la disponibilidad de los mismos. Seguiremos una política prudente para no disponer de un número excesivo de efectivos.

Una vez conocemos el Nt podemos calcular el tiempo de recolección esperado como:

TeCalculado = Tc*Nu + TiM;

Si este supera en un determinado porcentaje a nuestras espectativas de Te ajustamos el parámetro y volvemos a calcular. El proceso es único para cada paso de la partida y será rápido. De cualquier modo no deja de ser un estimador y debe de ser calculado constantemente para ajustarse a las variaciones del juego.

Control de los trabajadores y cálculo del recurso idoneo

El parámetro principal es la distancia a la base desde el recurso. Cuando la mínima distancia al recurso es superior a un determinado parámetro, se debe crear nueva base de recolección más cercana. Esta responsabilidad será del comandante constructor.

Nosotros mandaremos a nuestras unidades al recurso más cercano y al tipo concreto y tantas como el recurso sea capaz de asimilar sin que las unidades interfieran entre ellas. El algoritmo de selección del recurso idóneo para cada unidad será:

para cada unidad
min = +infinito;
para cada base
para cada recurso libre
distanciaParcial = calculoDistanciaEuclidea (baseActual, recurso);
si distanciaParcial < min
marcaRecursoActual();
finsi
fin
fin
recursoMarcado.numeroDeMineros++;
Si recursoMarcado.numeroDeMineros > máximoDeMinerosPorRecurso
recursoMarcadoExtraidoDelCálculo;
finsi
MonitorPathFinding(unidad, recurso, base);fin

En términos generales el algoritmo busca el recurso más cercano y lo asigna. Si hay muchas unidades asignadas lo saca del cálculo. Este está simplificado pero para el cálculo algo más complejo tendremos en cuenta la posición de la unidad actual para reasignarla primero a los más cercanos a su posición. Por otro lado podemos tener en cuenta el tipo de recurso filtrando en el caso de que haya más de uno.

Cuando la unidad notifica el fin de recursos a su comandante se reasigna. Si recibe ataque o cualquier otro evento también notifica y se le reasigna.

Recursos renovables VS No renovables. El comercio de comodín

El tipo de recursos en muchos de los juegos RTS puede caracterizarse en tres tipos por norma general: renovables, no renovables y auto-generables.

En el último caso no es necesario preocuparse por la distribución ni la estrategia a largo plazo, sin embargo, los otros dos representan un problema, la disponibilidad. Este aspecto lo tendremos en cuenta en la definición de la estrategia general en el ‘General’ haciendo una estimación en base al mapa en el que nos encontremos y a la densidad de recursos. Esto produce una solución dependiente del problema.

Otra solución que no permitirá aprovechar la distribución de los recursos desde el inicio será la de una estrategia adaptativa. Mediante esta orientación, vamos solventando de forma progresiva las peticiones de los subcomandantes conforme vamos adquiriendo material. El ‘comandante General’ puede tener acceso a la lógica de sus subcomandantes de forma conceptual asignando determinados porcentajes de recursos de modo que ell subcomandante ‘conozca’ la situación del minado de los recursos de forma indirecta. De este modo, el subcomandante puede decidir ajustarse al tipo de unidad que más se adapta a la producción en curso y a su cuota asignada. Los elementos que intervendrían en resumen: producción de cada tipo, porcentaje de la producción asignada a cada subcomandante y en sistemas avanzados, estimadores en base a las previsiones de generación de recursos.

El comercio toma una baza significativa en muchos sistemas actuales, siendo el único modo de adquirir determinadas materia primas o recursos y en muchas ocasiones la más efectiva. En nuestro subcomandante de recolección podemos definir una cuota asociada al desarrollo a largo plazo del elemento de comercio. Si bien puede permanecer inactiva en las fases iniciales del juego, conforme se desarrolla puede tomar mayor importancia. Las adquisiciones se harán en base a valores absolutos que recibe el jefe, es decir, el General.

Defensa de los recursos

Los recursos son casi tan importantes como las bases por lo que nuestra estrategia a largo plazo implicará defenderlos y afianzar las posiciones de las minas u otros recursos. En este caso interviene el ‘Posicionamiento de las unidades de defensa’ y es una tarea que debe llevar a cabo el Subcomandante de Defensa. La ventaja de haber distribuido la lógica por funcionalidad y tipo de tareas es que en lugar de tener que preocuparnos de buscar recursos o de defenderlos, tenemos que ir a la materia, recogerlos.

Los scouts o exploradores estarán gestionados por el subcomandante de exploración que en la fase correspondiente se encargará de posicionarlos de forma correcta para prevenir ataques sobre las minas. Cuando se detecta una intrusión o un ataque inminente, el Subcomandante de Exploración se encarga de avisar al General con su posición y el General de comunicar a los diferentes Subcomandantes que actuan en un radio de seguridad determinado de una alerta. Si el sistema de control o subcomandante de Recursos recibe una orden de peligro del General, deberá aplicar las maniobras necesarias. En este caso podemos mover las unidades a un punto seguro (la base o los puntos de seguridad concretos) o podemos plantear una mabiobra evasiva. De cualquier modo esperaremos la señal de fin de alerta del General para volver al trabajo.

Trampeando para mejorar la competitividad

Una vez hemos visto como lo hacemos bien y de forma organizada, nos bajamos al mundo real en el que tenemos que disponer de un sistema competitivo y que plantee retos a los niveles más avanzados de usuarios. En este caso, podemos trabajar la IA y ajustarla de forma que mediante muchos estados de juego y muchas optimizaciones quizá lleguemos a obtener un buen desempeño, o bien podemos tomarnos la licencia de hacerle un pequeño feo al jugador, claro está este no debe percibirlo, por eso es una trampa.

Lo que se hace en general es inyectar soluciones que influyan directamente en la economía del sistema sin que los enemigos lo perciban. ¿Donde metemos mano? Pues muy facil, en todo lo que se menea y en lo que no. Costes de unidades y edificios, capacidad de extracción de recursos de las unidades, tecnologías adicionales y en definitiva todo aquello que no pueda ser percibido directamente.

Un conocido ejemplo entre los insiders es el del Starcraft, donde en la modalidad Insane, la máquina se ‘atribuye’ 2000 de mineral y de gas, haciendo que la partida sea dura (Por supuesto esto no se extrae a través de un comunicado oficial): http://www.shamusyoung.com/twentysidedtale/?p=1597

En resumen

Hemos visto en detalle los elementos que se deben tener en cuenta a la hora de extraer recursos
con un punto de vista estratégico, desde la cantidad hasta el control de las unidades. Hemos comprobado como en ocasiones, es necesario añadir ‘ventajas’ competitivas sobre los jugadores y hemos distribuido la lógica del sistema de recolección y su comunicación con el resto de elementos del juego. Se ha visto que en función del estado en el que nos encontremos, aplicaremos una estrategia diferente y que en lo referente a la defensa y a la exploración, daremos por hecho que cada elemento cumple con su objetivo. En caso de detectar cualquier problema, sabremos donde ir a solucionarlo.

• Artesania del control de exploradores en juegos de estrategia
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia
• ORTS. Estrategia en tiempo real OpenSource
• Gran Pack de desarrollo de videojuegos
• IA en videojuegos – Persiguiendo y evadiendo II

En este artículo vamos a ver en detalle algunos de los conceptos que tienen que ver con el descubrimiento y la observación del terreno incluyendo las tácticas de exploración más comunes. Dado que trataremos la mayor parte de las técnicas necesarias, empezamos a nivel conceptual por aquellas que tienen lugar primero: las de scouting.

En primer lugar tendremos que decidir si queremos que nuestro sistema de inteligencia artificial sea piratilla y trabaje basado en trampas o si por el contrario queremos desarrollar un sistema realista. De antemano ya os digo que muchos de los juegos que se comercializan actualmente hacen trampas y saben exactamente a donde dirigirse, tanto en materia de recursos como en posiciones de enemigos. Muchos hacen la trampa de la sorpresa, hasta que no los atacas parece que desconocen tu posición, sin embargo podeis hacer la prueba y ver en cuantos juegos de RTS (real time strategy) podeis permanecer ‘ocultos’ despues de un ataque por sorpresa. Generalmente recibireis un generoso contraataque si la máquina está en condiciones.

De cualquier lugar aqui apostamos por crear sistemas realistas, entendiendo por realistas los que disponen de la información que les proporcionan sus unidades y no de otros parámetros externos al juego. Las dos opciones son válidas puesto que como es lógico, en ocasiones la rigurosidad de los sistemas viene determinada de forma inversamente proporcional al grado de presión que ejerza el game designer. Nosotros nos centraremos ahora en la solución en la que vale la pena discutir el tema, sin trucos.

Scouting basics

Sin entrar en detalle de los algoritmos que vayamos a emplear a nivel interno (pathfinding, comandantes, autómatas … etc), trataremos el tema desde un punto de vista mayormente teórico. La única preocupación que debemos tener es la de generar puntos del mapa bajo determinadas trayectorias.

El primer elemento a identificar es la unidad de scout. De entre todas las unidades disponibles en el ejercito, lo más probable es que una de ellas sea la más adecuada por su ligereza, su bajo coste, su resistencia moderada y rango de visión. Esta o estas serán las unidades de exploración.

Objetivos

Lo que buscamos con el explorador no es solo descubrir el terreno sino mantenerlo libre de enemigos y disponer de información precisa de lo que pasa. Se identifican algunas de las metas a alcanzar.

• Encontrar recursos
• Identificar unidades enemigas en el territorio propio y en el enemigo
• Encontrar la posición de la base del enemigo
• Marcar puntos de interés (pasos elevados, cuellos de botella, etc.)
• Táctica del oponente. Preveer movimientos y ataques en camino.
• Llevar a cabo ataques estratégicos.

Algunos de estos objetivos son únicos en el tiempo puesto que el mapa no variará respecto al tiempo. Otros requerirán de un monitorizado constante y de ajustes continuos.

De cualquier modo no se presenta como una solución absoluta sino como un primer enfoque más profundo de lo que es necesario en materia de exploración y sobre el que añadir nuevas tácticas y varias objetivos.

Fase I. La puesta en marcha

Nos ponemos en la piel de un jugador de RTS y vamos a poner de ejemplo una partida de Age of Empires. En ella nuestro explorador es un jinete a caballo rápido y con puntos de defensa y ataque limitados.

Nuestros objetivos principales son, identificar fuentes cercanas de abastecimiento y descubrimiento radial del entorno. Fijaremos con punto inicial de referencia el de la base propia y generaremos trayectorias radiales de diámetro creciente hasta un cierto punto que fijaremos en función del mapa.

Una vez identificadas las fuentes de suministros mínimas fijadas desde el planificador o el comandante de exploración segun el control de comportamiento que llevemos, pasaremos a seguir con las tácticas de medio juego.

Fase II. El desarrollo de la partida.

Una vez hemos identificado las fuentes de recursos y descubierto el entorno más próximo. El siguiente nivel es ampliar el rango de exploración para detectar el resto de elementos relevantes: recursos, enemigos y puntos de interés.

Seguiremos una estrategia radial del mismo modo. Iremos marcando posiciones al explorador siguiendo un radio creciente y marcaremos cada fuente de recursos encontrada y la posición de los enemigos así como la de su base en caso de encontrarla.

Los puntos de interés son zonas elevadas y pasos estrechos. Estos los conoceremos por nuestro grafo de claridad que se ha visto en detalle anteriormente. Como resumen, llevamos un estado de los espacios de cada posición del mapa al obstáculo más cercano, lo que nos permite saber si determinadas unidades pasarán o guiar los algoritmos de pathfinding. Nos interesa por tanto los puntos en los que pasan pocas y los marcaremos como cuellos de botella. En estrategia de combate que veremos más adelante veremos como nos pueden ser de ayuda.

En lo referente a las bases enemigas, una vez localizadas intentaremos dirigir la búsqueda o exploración hacia áreas alejadas con la finalidad de reducir la probabilidad de que el scout reciba un ataque.

Una vez localizado el enemigo y algunos grupos de recursos adicionales, la exploración toma otro matiz.

Fase III. La fase de convergencia

Esta fase se alcanza una vez conocemos suficiente sobre el entorno estático (para simplificar recursos, enemigo y puntos de interés) Una vez disponemos de esa información los exploradores pasan a tener otro cometido, el de estudiar el avance del enemigo y el de garantizar la integridad del territoriio. Eventualmente pueden colaborar en la estrategia de combate pero eso lo veremos más adelante. No tengas prisa pequeño saltamontes, todo lo bueno llega.

El patrullado

es una de las tareas principales de los exploradores en esta fase de desarrollo del juego. No podemos simplemente asignar y distribuir los exploradores por el territorio sin más y substituirlos cada vez que son eliminados ya que esto representaria un comportamiento predecible y el usuario podría detectar un comportamiento repetitivo y por lo tant aburrido en muy poco tiempo.

La estrategia en este caso varía. A priori se deben tener en cuenta dos temas básicos dentro del patrullado. El primero de ellos es  el posicionamiento de los exploradores. En este caso la distribución óptima vuelve a ser radial, sin embargo el ángulo de colocación de los exploradores no tiene porqué ser el de máxima difusión, de otro modo, el usuario puede detectarlo y acabar regularmente con todos ellos. Es más apropiado generalmente distribuirlos de forma semialeatoria en un rango que varie de la máxima difusión en pequeños porcentajes. Por ejemplo, si desde la estrategia general se asignan recursos como para disponer de 6 exploradores, la máxima difusión suponiendo que estamos emplazados en el centro inferior y tomando como ángulo 0 la linea inferior que delimita la pantalla, colocariamos de forma de máxima difusión los 6 exploradores para abarcar un sector de 180 grados por lo que estarán en los ángulos 0, 30, 60, 90, 120, 150 y 180 respectivamente con un radio de patrullado determinado (pongamos 20 grados). Una posible colocación y comportamiento sería inicialmente definir un radio de patrullado aleatorio y una colocación +- un 20%, de este modo la distribución es menos predecible. La distancia del radio a la base será definida de forma dinámica calculando la distancia al edificio más lejano como medida de simplificación y añadiendo un determinado factor. Soluciones más complejas darán lugar a una mejor distribución y adaptación al terreo, utilizando mapas de influencia por ejemplo describiremos con mayor precisión el area en la que debemos situar los exploradores. De cualquier modo se trata de tener en cuenta estos conceptos cuando abordemos un trabajo del estilo.

La evasión

Otro de los temas a tener en cuenta es el de la evasión. Una vez localizado al enemigo debemos iniciar la táctica de evasión y comunicar al comandante el avistamiento. Si utilizamos cualquier otra forma de control de comportamiento deberemos igualmente incluir una función que comunique el evento. POdemos o bien iniciar la evasión simple, vuelta a la base y espera de un tiempo concreto o bien iniciar el seguimiento desde la distancia del enemigo localizando el enemigo más cercano y manteniendo una distancia prudencial. Esta última estrategia generalmente dará como lugar la eliminación del explorador pero aportará más información sobre las intenciones del enemigo. En cualquuier caso el explorador
debe estar monitorizado.

Tácticas de comando

La inclusión de tácticas de comando en el area enemiga. Estas maniobras irán destinadas a descubrir los avances y las posiciones del enemigo por lo que iniciaremos tareas de acercamiento progresivo al area del enemigo alternando maniobras de exploración con maniobras de evasión. Esta será una táctica arriesgada que dará lugar en muchas ocasiones a la eliminación del scout. En este aspecto se asumen los costes en favor de un bien mayor ya que con la información obtenida podemos informar a los comandantes de combate, constructor y científico acerca de los progresos y que ellos actuen en consecuencia. Cualquier otro enfoque dará lugar a corregir de algun modo las construcciones, la creación de unidades y el desarrollo científico para el correcto uso de la información que hemos obtenido con el scout.

maniobra Tora Tora Tora

La maniobra Tora Tora Tora! Es la que pretende acercarse al corazón del enemigo en una maniobra kamikace que da lugar a la eliminación prácticamente segura del scout pero aporta mucha información acerca del grado de desarrollo del enemigo. Muchos de los jugones aqui presentes habrán hecho sacrificios similares para ver como va el tema en casa del malo. El caso es que aqui no podemos guardar antes de liarla y volver a cargar una vez sabemos donde estan las defensas y los edificios más importantes.

Hay más elementos tácticos que son importantes en lo referente a esta fase del juego pero para empezar y tener un buen conocimiento de los elementos que se tienen en cuenta en el juego ya está muy pero que muy bien. Desarrollar a nivel técnico lo que aqui se escribe a nivel conceptual representa un buen reto para cualquier desarrollador de sistemas de IA por lo que tenemos trabajo que hacer.

Conceptos matemáticos involucrados

Hemos hablado aqui bastante de generar trayectorias radiales sobre las que ir explorando o  colocando a los exploradores pero que demonios es una trayectoria radial y cómo la calculo? De eso nos vamos a encargar ahora. Porque aqui y no arriba cuando las necesitabamos? POrque una vez sabemos para que las vamos a utilizar nos podemos poner manos a la obra mucho más agusto.

En primer lugar, una trayectoria radial se refiere al hecho de que un determinado elemento sigue un camino definido en base a un punto que representa el centro de un circulo y un radio concreto de distancia a ese círculo. Pongamos que si quisieramos mover una unidad de forma radial por una rueda de bicicleta, dariamos puntos muestreados que coincidirian en la cubierta. Más sencillo, dibuja un círculo y las unidades se moverán por un sector determinado de ese círculo.

El centro de la trayectoria es generalmente un punto de una malla, no bajamos a nivel de pixel para no complicar nuestros algoritmos de pathfinding (si esto lo llevas verde dale un vistazo a los artículos de pathfinding, tenemos para todos los públicos). Por lo tanto tendremos un punto X y otro Y que definen la posición en X y en Y respectivamente. Los llamaremos Xc e Yc a partir de ahora.

Otro elemento será el radio R que definirá la distancia a la que deberán moverse o posicionarse las unidades. Por supuesto que cuando le pasemos las posiciones finales al algoritmo de pathfinding, el mismo buscará las trayectorias más adecuadas. Si queremos un movimiento claramente radial deberemos obtener muchas muestras y pasarselas a nuestro pathfinder. De cualquier modo no te preocupes de esto porque lo definiremos como Nm (número de muestras).

Otro de los elementos a tener en cuenta son los grados de posicionamiento (Gp). Con este elemento posicionamos en la circunferencia el elemento. Una unidad situada a 10 pasos de radio y a 90 grados se posicionará enfrente. A 0 grados se moverá en linea recta hasta la derecha y a 180 se moverá a la izquierda.

Teniendo todos los elementos ahora, como calculamos la posición X e Y definitiva. Mucho más sencillo de lo que puede parecer a priori, utilizando senos para la componente vertical y cosenos para la horizontal. Dado que nuestra posición en el mapa será arbitraria, simplificaremos suponiendo que al empezar es lógico explorar toda la circumferencia de la base, sin embargo, algoritmos sencillos pueden estimar y determinar que rango de grados deben ser explorados en casos como por ejemplo si aparecemos en una esquina del mapa. Vamos por partes.

En la imagen vemos desde un pun to C los puntos abarcables con un determinado radio.

1. calculamos la posición X e Y donde debe ir la unidad para un grado concreto y un radio determinado. El valor en X será el coseno del ángulo por el radio y el de Y el seno del mismo ángulo por el radio.

2. calculamos la correspondencia a nuestra malla de los valores obtenidos. Sabiendo el tamaño en X y en Y de nuestra malla (no siempre igual), el cálculo del elemento al que tenemos que ir se obtendrá dividiendo el valor obtenido por el propio tamaño correspondiente. De este modo si habiamos obtenido en el primer paso X = 2.2 e Y = 4.6 y tenemos tamaños de malla igual a 1 en X e Y, la posición pasará a ser (x,y) = 2, 4. Y ya se la podemos pasar al algoritmo de pathfinding que para ser eficiente trabajará con la malla.

3. Vistas las posiciones absolutas planteamos un muestreo desde un grado inicial de la circumferencia a un grado final de la misma.

Teniendo el parámetro número de muestras (Nm) calcularemos los incrementos de grado que le vamos a pasar a nuestra función de cálculo de posiciones construida a partir de los pasos 1 y 2 asi:

incGrados = (GradoFinal – GradoInicial) / Nm;

Una vez tenemos el incremento de grados para cada paso del algoritmo iteramos.

iteracion = 1;
Desde 1 Para cada Nm
(x, y) =CalcularPosición(GradoInicial + (incGrados*iteracion);
pathfinding(x, y);
iteración ++;
Final

Es decir, calculamos, movemos y repetimos el proceso.

El enfoque hacia objetivos

Se ha tratado un enfoque basado en fases de juego en los que pasar de una fase a otra dependía de la consecución de diferentes metas como encontrar al enemigo o descubrir una parte del terreno. El enfoque hacia objetivos varía respecto a la propuesta anterior por el hecho de que las unidades scout se generan y se comportan exclusivamente para cumplir determinados objetivos.

La diferencia respecto a la anterior propuesta es sutil pero a nivel interno el cambio es más importante. Vemos un ejemplo que lo dejará más claro. Nuestro procedimiento será ahora crear tantos exploradores como sean posibles, encontrar N fuentes de recursos. Una vez encontrados revelar un porcentaje concreto del mapa. Una vez hecho esto buscar al enemigo. Cuando esté localizado determinar 3 puntos de interés, sino pasa un tiempo determinado damos por supuesto que no hay más y seguimos con el revelado del mapa. Hecho esto protegemos y patrullamos la base. La diferencia radica en el enfoque, mientras que en el modelo anterior se va trabajando segun la fase, aqui se motiva este cambio de forma progresiva y secuencial en función del objetivo. En el modelo anterior se cambiará de fase cuando se completen unos determinados puntos, en este último seremos nosotros los que busquemos la consecución inmediata de estos aunque esto no sea la estrategia más adecuada a largo y corto plazo.

Respuesta a inconvenientes

Es atacado

El scout es detectado y está siendo atacado. En este caso se puede dirigir a la base o considerar el movimiento alejandonos de ella. En una primera valoración puede parecer lógico llevarlo al abrigo de nuestras unidades, sin embargo puede que no nos sea beneficioso guiar al enemigo a nuestra posición.

Conceptos más laboriosos son los que involucran bases de apoyo secundarias que pueden proteger de forma eventual problemas de este tipo.

Encuentra un grupo de aldeanos

En este caso existe la posibilidad de iniciar maniobras de hostigamiento. Mientras el enemigo no ponga vigilancia, será posible golpear y huir a los aldeanos provocando molestias y pérdidas al jugador. Generalmente será contrarrestado con un destacamento de protección. Hecho que también puede ser aprovechado para atacar la base en extremos opuestos, a sabiendas de que hay unidades alejadas que antes defendian y ahora no.

Pincelada de estrategia de combate usando exploradores

Como veremos en artículos de estrategia de combate. Una de las tácticas más efectivas es la de la distracción. Desde que los humanos peleábamos con garrote las tácticas de distracción han sido extremadamente útiles. En este caso se trata de mandar al scout a una zona de minado de recursos del enemigo lo más alejada posible y de forma casi simultanea enviar tropas de ataque por el lateral contrario de la base enemiga. Las inteligencias artificiales en su práctica totalidad enviarán unidades y desplazarán algunas de las producidas. Puede ser efectiva o no, en cualquier caso si los aldeanos no se protegen serán menguados y su ritmo de producción caerá, lo que ya es positivo. Si defienden correctamente la protección en la zona se verá disminuida por lo que podremos aprovechar el ataque con más garantías.

Esto es estrategia de combate y de la complejidad y riqueza de las mismas haremos disfrutar y sufrir al jugador dándole un buen nivel al juego.

En resumen

Hemos visto los elementos más importantes a tener en cuenta en materia de exploración para tener una inteligencia artificial competitiva. Se han tenido en cuenta los conceptos matemáticos para generar una trayectoria radial respecto a un punto concreto y definir el grado de precisión a pasarle al pathfinder. Finalmente se han tratado algunos modelos más sencillos y se ha adelantado un pequeño concepto de combate. Ahora toca ponerlos en práctica.

Algunos de los juegos actuales incluyen unidades espia. La función de éstos es básicamente la del explorador con funcionalidad añadida como el sabotaje o la contaminación de edificios. Muchas de los conceptos aqui detallados son aplicables a la unidad espia.

Original: http://www.starcostudios.com/blog/2010/02/artesania-del-control-de-exploradores-en-juegos-de-estrategia/

• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia
• Gran Pack de desarrollo de videojuegos
• ORTS. Estrategia en tiempo real OpenSource
• IA en videojuegos – Persiguiendo y evadiendo II

Como creadores de inteligencia artificial orientada a los juegos de estrategia, debereis ser conocedores de las más antiguas técnicas estratégicas. Para ello vamos a echar mano de uno de los mejores generales y estrategas del pasado, Sun Tzu. El aspirante a Samurai Informático deberá conocer las enseñanzas del maestro a través de su célebre libro ‘El arte de la Guerra’.

El Maestro Sun Tzu dijo: “Un ejército victorioso gana primero y entabla la batalla después; un ejército derrotado lucha primero e intenta obtener la victoria después.”

Aqui veremos como crearlo.

En la mayoría de juegos de estrategia estaremos condicionados a conseguir determinados objetivos que se verán por regla general amenazados por uno o varios enemigos de diferente índole. En este artículo vamos a ver en detalle que conceptos intervienen en el enfoque estratégico y táctico de una partida genérica de un juego de estrategia en tiempo real. Muchos de estos conceptos son extrapolables a otro tipo de juegos como los basados en turnos o los queestán orientados al crecimiento del jugador sin oponentes. Sin embargo, serán muy útiles especialmente en los RTS.

Nuestro objetivo como creadores de inteligencia artificial es claro, crear una máquina mortífera capaz de destruir al jugador oponente, ya sea humano u otra máquina. Por otro lado tenemos que garantizar la posibilidad de dominar a la bestia, haciendo que sea todo lo efectiva que queramos, es decir, permitir que diferentes niveles de jugador puedan enfrentarse.

Detallaremos los conceptos que son necesarios para modelar nuestro propio Gengis Kan, tu Napoleon o tu Jerjes, cada uno con sus gustos. Una vez hayamos terminado aqui sereis especialistas estrategas en lo que al mundo virtual se refiere.

Empezamos

Un buen sistema de estrategia se focalizará en todos los elementos que toman parte en el desarrollo del juego. Tendremos en cuenta de este modo, tanto recursos como unidades, tecnología o terreno.

En primer lugar hay que marcar el camino que queremos seguir en materia algoritmica. Poemos elegir principalmentedos opciones cada una de ellas apropiada para cada caso. La primera de ellas es usar estrategias preconcebidas.

Esta modalidad implica que tenemos que dotar de un conocimiento previo a nuestro sistema para que responda de forma correcta y se oriente a llevar a cabo una serie de soluciones. Un ejemplo de este modelo será el desarrollo clásico de una partida de estrategia: recoletar, fortificarse, contruir ejército y atacar/defenderse. A un nivel más detallado podemos incluir reglas concretas como favorecer la ocupación de lugares altos o crear una determinada proporción de unidades de diferentes tipos. Estas etrategias vendrán por lo tanto muy ajustadas al entorno en el que estamos creando la inteligencia artificial y serán difícilmente rehusables en otros.

La segunda de nuestras opciones será más compleja e implicará técnicas de Ninja Informático como algoritmos de modelado del jugador mediante machine Learning. Estas soluciones suelen requerir algunas partidas para ajustar los parámetros principales y se adaptan al nivel del jugador. Sin embargo, son más complejas de diseñar y adaptar por lo que en la mayoría de las ocasiones se opta por definir un comportamiento concreto como el fijado en el primer puntoy se crea un autómata de estados finito jerárquico para controlarlo. De cualquier modo, una vez dominados los algoritmos de aprendizaje, pueden utilizarse con mayor sencillez para tipos de juego similares.

Una vez escogido el modo en el que vamos a llevar a cabo nuestro desarrollo, deberemos profundizar en el uso de estratagemas más propias de táctica y estrategia general que de cuestiones tecnológicas. Vamos a ver ahora en qué áreas y qué tiposd de estrategias vamos a llevar a cabo en cada una.

Áreas a tener en cuenta

Cada área de las que tendremos en cuenta a continuación suele presentarse casi de forma obligatoria en los juegos de estrategia en tiempo real. Añadir complejidad en el comportamiento de nuestra sistema en las mismas hará que el usuario tenga una mejor experiencia de juego y se le presente una inteligencia artificial no encorsetada en la misma reacción. Esto es lo que realmente añade riqueza a la inteligencia artificial ya que conforme las estratgemas y mecanismos aumentan, más dificil es para el jugador preveer el comportamiento. No se trata de hacer que el sistema sea invencible sino de que sorprenda al usuario. Una regla de oro en el desarrollo de sistemas de inteligencia artificial para juegos es que la IA nunca debe ser más ‘lista’ que el jugador pero si tanto o más pícara por caracterizarla con una palabra políticamente correcta. Se me ocurren otras palabras para describir el comportamiento que debe tener la IA con más exactitud pero no las diré aqui. Queda a la imaginación de cada uno. Piensa mal y acertarás.

Vamos a ir viendo en detalle las áreas que siguen a continuación. De la correcta creación y desempeño de cada una de estas áreas dependerá la calidad de nuestro ‘Warlord’ Artificial.

• Inteligencia artificial para la recolección.
• Inteligencia artificial para la construcción.
• Inteligencia artificial para la tecnología.
• Inteligencia artificial para la exploración.
• Inteligencia artificial para el ataque.
• Inteligencia artificial para la defensa.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Cada una de ellas es una pieza clave en el correcto desarrollo del juego, Mejorarlas y añadiendo complejidad respetando la regla de oro anterior es hacer que nuestro sistema sea cada vez más rico e interesante. Las veremos en detalle una a una.

Ahora, el general que gana una batalla hace muchos cálculos en su cuartel, considera muchos factores antes de que ésta se libre. El general que pierde una batalla hace pocos cálculos en su cuartel, considera pocos factores antes de que ésta se libre. Muchos cálculos llevan a la victoria, pocos cálculos llevan a la derrota.

Dificultad exacta

Un factor importante que se ha comentado anteriormente es el de limitar las capacidades de nuestro sistema de IA. Es necesario que de un modo u otro, el usuario pueda desarrollar los objetivos sin desesperarse en exceso. Si bien es bueno que nuestro sistema plantee un reto considerable, no es preferible que el usuario acabe lanzando la consola o el pc por la ventana.

Para definir y acotar el nivel de dificultad tenemos infinidad de mecanismos, sin embargo, unos de los más empleados son los que se comentan a continuación. En primer lugar, al no disponer de un nivel de proceso concreto como el aplicado en algoritmos de teoría de juegos como el minimax, no es sencillo definir de forma numérica el desempeño del algoritmo. Lo que haremos en este caso es relajar los objetivos. Con relajar se entiende ralentizar la obtención de elementos (recursos, tecnologías, unidades), disminuir el grado de desempeño de las unidades y bajar el nivel de coherencia de las acciones (gastos en tecnologías que no ofrecen sinergias, producción de determinados tipos de unidades en exceso o insuficientes…etc). Esto será muy sencillo si definimos los objetivos de forma que en cada estado del juego pueda medirse el grado de consecución de los mismos.

Este es solo un enfoque del estudio del ajuste de la dificultad a los diferentes niveles de juego previstos. Otro enfoque se basa en dificultar el desempeño en las diferentes áreas que hemos visto anteriormente haciendolas más ineficientes. En esta variante intentaremos definir nuestros algoritmos internos (pathfinding, distribución, scouting…etc) de forma que podamos parametrizar lo máximo posible su grado de eficiencia. De este modo creariamos algoritmos flexibles en desempeño, en el caso de los algoritmos de pathfinding la eficiencia máxima corresponde al mínimo camino entre la fuente y el destino. En el caso de un algoritmo de scouting la eficiencia máxima puede darse cuando se busca magnificar el área descubierta con la máxima velocidad.

Visto el ajuste de dificultad por relajación de los objetivos y el ajuste por areas, vamos a ver un concepto diferente, el modelado del jugador.

Modelar al jugador

Una vez que planteamos el ajuste de la dificultad de forma interna en el juego, podemos hacer dos cosas. O bien permitir que el usuario ajuste la dificultad y a partir de niveles concretos (fácil, medio, dificil…) traduciendo internamente a las diferentes áreas u objetivos.

O bien podemos modelar nosotros mismos a partir del desempeño del jugador y hacer un autoajuste. Existe mucha documentación referente al modelado del jugador, por lo que este tema puede verse con mucho detalle.

Un ejemplo de modelado sería el siguiente. En primer lugar estableceremos una correspondencia entre los elementos que intervienen en el juego y la dificultad que esto plantea al usuario a nivel medio. Una vez disponemos de esta información el monitorizado será una constante durante el desarrollo de la partia. Cada cierto tiempo austaremos nuestros valores internos mediante los mecanismos de ajuste de dificultad vistos anteriormente y en función de los parámetros observados en el usuario. Esto, sin embargo plantea un problema desde el punto de vista en el que necesitamos valores del usuario a los que teóricamente no tenemos acceso como jugadores y por esto desde el punto de vista de la inteligencia artifical estamos haciendo trampas. Esto es más que usual en el desarrollo de juegos comerciales, sin embargo, aqui estamos buscando soluciones que impliquen una inteligencia artificial ‘real’.

una solución al problema anterior es echar mano de algoritmos de aprendizaje. En este caso, los algoritmos irán tomando decisiones y observando la recompensa o la pérdida que estas decisiones le reportan ajustando los diferentes parámetros. Para ello, será necesario interactuar con el usuario inicialmente sin conocer sus capacidades y las primeras partidas pueden ser un tanto desastrosas. Solo los Grandes Maestros Ninjas Informáticos se atreven a ofrecer soluciones comerciales de este tipo. Uno de los pocos ejemplos es el Black And White de LionHead Studios que apostó por algoritmos de este tipo y salió más que bien parado.

Para los más interesados podeis profundizar en temas de redes neuronales, algoritmos de computación evolutiva y machine learning en general. De cualquier modo el tema es tan extenso como interesante por lo que no perdais ni un minuto. Yo diría que entre todos los conceptos de computación, los que están en estas áreas son los que me han resultado más interesantes.

Trampas de los creadores de juegos

Para terminar el tema de la estrategia es necesario y más que recomendable echar un vistazo a los pequeños trucos de Ninja Informático que utilizan los creadores de inteligencia artificial orientada a los juegos de estrategia. Puede parecer que esto es un insulto a la integridad de vuestro sistema de IA y a vuestras capacidades, sin embargo, cuando los tiempos de entrega aprietan y se hace necesario disponer de un sistema competitivo, os acordareis de esta sección.

La primera de las trampas es jugar con los recursos. La cantidad de recursos y el tipo de los mismos que tu minas por unidad de tiempo con una unidad determinada no siempre tiene que ser igual a la que tiene vuestro oponente artificial. Esto se llama generalmente ‘dopar’ a las unidades.

Otra de las trampas más utilizadas es el monitorizado de la creación de unidades de los oponentes. El sistema observa los tipos de Unidades que se están creando y construye las más apropiadas para combatir el ejército enemigo. La velocidad de construcción y de minado cuando es posible tambien se modifica, haciendo que el desarrollo sea más rápido. El resto de unidades estar tambien dopadas.

Otro truco es modificar los costes de las unidades y del resto de elementos del juego. Con lo que tu obtienes X, el sistema de inteligencia artificial puede obtener 2X, ¿fácil no?.

Uno de los más recurridos es el de la omnipresencia (Disabled fog of war), mediante el que el oponente máquina puede ‘ver’ unidades, edificios y demás elementos en cada momento. Con esto puede percibir y prepararse para ataques o incluso fortificarse para evitar asaltos.

Independientemente de la estrategia de desarrollo tecnológico que se haya establecido, algunos sistemas de inteligencia artificial actualizan la tecnología para que esté acorde con la del jugador, teniendo mayor ventaja y estando mejor preparado frente a los ataques del mismo.

Parecido al anterior sería el conocimiento de los detalles del jugador. Se sabe en todo momento los recursos, las unidades, los edificios y las tecnologías de modo que se trabaja en consecuencia para neutralizar los avances y se inyectan los recursos (y en ocasiones unidades) necesarios.

Si conoces a los demás y te conoces a ti mismo, ni en cien batallas correrás peligro; si no conoces a los demás, pero te conoces a ti mismo, perderás una batalla y ganarás otra; si no conoces a los demás ni te conoces a ti mismo, correrás peligro en cada batalla.

Como veis, los chicos encargados de las inteligencias de cada juego se han aplicado el cuento de 3000 años de antiguedad.

En resumen

Hemos visto la profundidad con la que podemos llegar a tratar un tema que aparentemente centra su complejidad en el apartado técnico y que resulta ser más conceptual que otra cosa. Se han visto las diferentes áreas que intervienen en el desarrollo sentando las bases de un estudio más profundo sobre cada área.

Se a establecido la importancia de modelar al usuario y permitir diferentes grados de dificultad. La regla más importante será en este aspecto que la IA nunca puede ser más ‘lista’ que el usuario. Aplicar técnicas de modelado del usuario puede ser muy útil aunque plantea una complejidad importante.

Finalmente hemos comprobado que cuando los tiempos de desarrollo aprietan, independientemente de lo riguroso y comprometido que sea uno con el entorno de la inteligencia artificial en el ámbito científico, las cosas tienen que salir bien y rápido. Por
esto muchos sistemas de entretenimiento recurren al uso de ciertas trampas hacia el usuario, lo que implica que no se puede considerar una inteligencia artificial ‘real’ u honesta. En un conflicto similar con parámetros realistas no tendriamos acceso a estos mecanismos.

Comparte tu conocimiento táctico tanto en este artículo general como en cada una de las áreas que vamos a tocar.

Original: http://www.starcostudios.com/blog/2010/02/sun-tzu-2-0-el-arte-de-la-guerra-en-los-juegos-de-estrategia/

• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• ORTS. Estrategia en tiempo real OpenSource
• IA en videojuegos – Persiguiendo y evadiendo I
• La Inteligencia Artificial de L4D
• Guía aprender programar videojuegos con C++

Aunque los game engines hechos en javascript son poco populares, si podemos resaltar el trabajo de algunos como ImpactJs (comercial) o GameJs (open source) que permiten realizar casi todo lo que un motor común. Sin embargo la limitación de estos motores está dedicada exclusivamente a la web, por lo que el proyecto PhoneGap pretende acabar con esa limitación y ofrecer una serie de funcionalidades que permitirán al desarrollador portar sus juegos a dispositivos móviles.

Algunas características de PhoneGap son las siguientes:

• Permite portar juegos hechos con HTML5, Javascript y CSS.
• Brinda la posibilidad de exportar los juegos a iPhone, Android, BlackBerry, WebOS, Symbian y según el sitio oficial ya están trabajando para hacerlo compatible con Windows Mobile.

Para cada dispositivo existen tutoriales muy bien explicados en el sitio oficial y según la documentación hay clases disponibles para hacer compatible el juego con el acelerómetro, la cámara del dispositivo, redes, notificaciones y varios tipos de eventos.

Enlace: PhoneGap

• No hay entradas relacionadas.

Obtener eventos

Básicamente, hay dos formas de recibir los eventos en un sistema de ventanas:

• Pedir a la ventana los eventos que han sucedido en cada iteración del bucle lo que se conoce como “sondeo”.
• Darle a la ventana un puntero a una función que es llamada cuando recibe un evento.

SFML utiliza el sistema de sondeo para recibir eventos. Es decir, se debe pedir a la ventana los eventos en cada ciclo. La función a utilizar es GetEvent() que rellena una instancia de sf::Event y devuelve true si hay algún evento o falso si la pila está vacía.

// Esto va en el Game Loop del tutorial anterior

sf::Event Event;
if (App.GetEvent(Event))
{
    // Procesar evento
}

Pero puedo haber más de un evento en cada interacción del bucle y lo de arriba solo nos procesará el primero de la pila. La forma correcta sería:

sf::Event Event;
while (App.GetEvent(Event))
{
    // Procesar eventos
}

Debes colocar esto en la parte superior del bucle ya que es bueno obtener los eventos de la ventana en cada ciclo antes de hacer otra cosa para actuar en consecuencia.

while (Running)
{
    sf::Event Event;
    while (App.GetEvent(Event))
    {
        // Procesar eventos
    }

    App.Display();
}

Procesar eventos

Lo primero que hay que comprobar cuando llegamos a un evento es su tipo, SFML define los siguientes tipos de eventos, todos dentro de sf::Event:

• Closed
• Resized
• LostFocus
• GainedFocus
• TextEntered
• KeyPressed
• KeyReleased
• MouseWheelMoved
• MouseButtonPressed
• MouseButtonReleased
• MouseMoved
• MouseEntered
• MouseLeft
• JoyButtonPressed
• JoyButtonReleased
• JoyMoved

Dependiendo del evento la instancia del objeto tendrá diferentes parámetros:

• Size events (Resized)
  • Event.Size.Width Nuevo ancho de la ventana, en píxeles
  • Event.Size.Height Nuevo alto de la ventana, en píxeles
• Text events (TextEntered)
  • Event.Text.Unicode contiene la codificación UTF-32 del código del carácter que se ha introducido
• Key events (KeyPressed, KeyReleased)
  • Event.Key.strong contiene el código de la tecla que se presiona / suelta
  • Event.Key.Alt Si la tecla Alt está o no presionada
  • Event.Key.Control Si la tecla Control está o no presionada
  • Event.Key.Shift Si la tecla Shift está o no presionada
• Mouse buttons events (MouseButtonPressed, MouseButtonReleased)
  • Event.MouseButton.Button Botones del ratón que se presionan / sueltan
• Mouse move events (MouseMoved)
  • Event.MouseMove.X Coordenadas X de la posición del ratón, coordenadas locales
  • Event.MouseMove.Y Coordenadas Y de la posición del ratón, coordenadas locales
• Mouse wheel events (MouseWheelMoved)
  • Event.MouseWheel.Delta Movimiento de la rueda del ratón. Positivo si es hacia adelante y negativo hacia atrás.
• Joystick buttons events (JoyButtonPressed, JoyButtonReleased)
  • Event.JoyButton.JoystickId Indice del Joystick (puede ser 1 ó 0)
  • Event.JoyButton.Button Índice de los botones del ratón pulsados / soltados , rango [0, 15]
• Joystick move events (JoyMoved)
  • Event.JoyMove.JoystickId Indice del Joystick (puede ser 1 ó 0)
  • Event.JoyMove.Axis Movimiento del eje
  • Event.JoyMove.Position contiene la posición actual en el eje, en el rango [-100, 100] (excepto Punto de vista que está en [0, 360])

Las teclas del teclado son constantes de SFML definidas en Events.hpp, por ejemplo para la tecla F5 sería sf::Key::F5

Lo mismo para el ratón, tiene definidas cinco constantes: sf::Mouse::Left, sf::Mouse::Right, sf::Mouse::Middle (botón de la rueda), sf::Mouse::XButton1 y sf::Mouse::XButton2

Para el Joystick las constantes son: sf::Joy::AxisX, sf::Joy::AxisY, sf::Joy::AxisZ, sf::Joy::AxisR, sf::Joy::AxisU, sf::Joy::AxisV, y sf::Joy::AxisPOV.

Así que … volvamos a nuestra aplicación, y añadir algo de código para controlar eventos. Vamos a añadir algo para detener la aplicación cuando el usuario cierra la ventana, o cuando se presiona la tecla de escape:

sf::Event Event;
while (App.GetEvent(Event))
{
    // Si se cierra la ventana
    if (Event.Type == sf::Event::Closed)
        Running = false;

    // Si se presiona Escape
    if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
        Running = false;
}

Cerrando la ventana

Si has jugado un poco con las ventanas de SFML te habrás dado cuenta que al pulsar cerrar (la cruz superior) se genera un evento de cierre, pero no se cierra la ventana, esto es así para dar la posibilidad al programador de implementar su cierra, por ejemplo que pregunte al jugador si desea guardar la partida o si está seguro.

Podemos usar el método Close() para cerrar la ventana. Hay otro método llamado IsOpened() que devuelve verdadero si la ventana está abierta y falso si está cerrada, con estos dos métodos podemos controlar el bucle de nuestro juego sin variables auxiliares.

while (App.IsOpened())
{
    sf::Event Event;
    while (App.GetEvent(Event))
    {
        // Window closed
        if (Event.Type == sf::Event::Closed)
            App.Close();

        // Escape key pressed
        if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
            App.Close();
    }
}

Entrada en tiempo real

Este sistema de eventos es lo suficientemente bueno para reaccionar ante eventos como el cierre de la ventana, o pulsar una tecla. Pero si deseas controlar, por ejemplo, el movimiento continuo de un personaje cuando se presiona una tecla de dirección, a continuación, pronto verás que hay un problema: habrá una demora entre cada movimiento, el retraso se define por el sistema operativo cuando se siguen presionando una tecla.

Para solucionar esto empleamos la clase sf::Input. Esta instancia no puede vivir por si misma, está ligada a una ventana y se debe de definir a que ventana es cuando se crea.

const sf::Input& Input = App.GetInput();

Como vemos es una referencia al método GetInput() de nuestra ventana. Con esto podemos comprobar los valores en tiempo real de la siguiente forma:

bool         LeftKeyDown     = Input.IsKeyDown(sf::Key::Left);
bool         RightButtonDown = Input.IsMouseButtonDown(sf::Mouse::Right);
bool         Joy0Button1Down = Input.IsJoystickButtonDown(0, 1);
unsigned int MouseX          = Input.GetMouseX();
unsigned int MouseY          = Input.GetMouseY();
float        Joystick1X      = Input.GetJoystickAxis(1, sf::Joy::AxisX);
float        Joystick1Y      = Input.GetJoystickAxis(1, sf::Joy::AxisY);
float        Joystick1POV    = Input.GetJoystickAxis(1, sf::Joy::AxisPOV);

Como vemos, un método mucho mejor para controlar la entrada de un videojuego.

• SFML – Instalación y configuración
• SFML – Abriendo una ventana
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• SFML – Juego de ejemplo

El juego es sencillo y no está terminado, nada de menús ni puntuaciones. Solo lo básico de la mecánica del juego crear una estructura mayor se salía de los fines del ejemplo.

Para compilarlo en linux solo debes descomprimirlo, entrar en la carpeta desde la línea de comandos y ejecutar:

g++ -o Pong ./pruebas.cpp -lsfml-graphics

Claro está primero tenéis que tener instalado SFML.

• Descargar ejemplo

• SFML – Manejando eventos
• SFML – Instalación y configuración
• Proyecto Generic Game Engine
• [BGE] Espacio de nombre, tipos y cabeceras
• [BGE] Sistema base del Engine

Preparando el código

En primer lugar tenemos que incluir el header necesario para manejar ventanas.

#include <SFML/Window.hpp>

Este es el único archivo necesario ya que contiene el resto de includes de las partes de SFML que maneja la ventana. Recuerda enlazar cuando compiles en esta caso a sfml-Window.

A continuación definimos la función main típica de todo programa en C++.

int main()
{
    // Cuerpo
}

O si queremos pasarle argumentos por la línea de comandos:

int main(int argc, char** argv)
{
    // Cuerpo
}

Abriendo una ventana

El siguiente paso es abrir una ventana, esto se hace con la clase sf::Window. Especial atención al espacio de nombre “sf” todos los objetos y tipos de datos de SFML están en el namespace “sf”.

sf::Window App(sf::VideoMode(640, 480, 32), "SFML Window");

Aquí creamos un nuevo objeto llamado App que representa a nuestra ventana. Vamos a explicar los parámetros.

El primer parámetro es sf::VideoMode representa el modo de vídeo elegido en este caso una ventana de 640 píxeles de ancho, 480 píxeles de alto y 32 bits de profundidad de color. Estas medidas solo es la ventana interior se excluyen los bordes y la barra te títulos.

El segundo parámetro representa el título de la ventana y el tipo de dato es un std::string.

Si desea crear la ventana posterior, o volver a crearla con diferentes parámetros, puede utilizar la función Create:

App.Create(sf::VideoMode(800, 600, 32), "SFML Window");

El constructor y el método crear aceptan otros parámetros opcionales: El primero para controlar el estilo gráfico de la ventana y el segundo para opciones avanzadas gráficas que no veremos de momento.

El parámetro estilo es una combinación de banderas de sf::Style separadas con el operador “|”. Las banderas son None, Titlebar, Resize, Close and Fullscreen. Por defecto toma los valores: Resize | Close.

// Esto crea una ventana a pantalla completa
App.Create(sf::VideoMode(800, 600, 32), "SFML Window", sf::Style::Fullscreen);

Modos de vídeo

En el ejemplo anterior, no me importa el modo de video ya que se ejecutan en modo de ventana, de cualquier tamaño va a estar bien. Pero si quisiéramos ejecutar en modo de pantalla completa, sólo unos cuantos modos se permitirían. sf::VideoMode proporciona una interfaz para obtener todos los modos de vídeo compatibles con las dos funciones estáticas GetModesCount y GetMode:

unsigned int VideoModesCount = sf::VideoMode::GetModesCount();
for (unsigned int i = 0; i < VideoModesCount; ++i)
{
    sf::VideoMode Mode = sf::VideoMode::GetMode(i);

    // Mode es un modo de vídeo valido
}

Tenga en cuenta que los modos de vídeo están ordenados de mayor a menor, por lo que sf::VideoMode::GetMode(0) devolverá siempre el mejor modo de vídeo compatible.

// Crear una ventana a panalla completa con el mejor modo de vídeo
App.Create(sf::VideoMode::GetMode(0), "SFML Window", sf::Style::Fullscreen);

Si quieres obtener el modo de vídeo de otro lado, por ejemplo, un fichero de configuración puedes usar el método IsValid() para comprobar que es válido.

sf::VideoMode Mode = ReadModeFromConfigFile();
if (!Mode.IsValid())
{
    // Error...
}

Por último con GetDesktopMode() puedes obtener el modo de vídeo del escritorio.

sf::VideoMode DesktopMode = sf::VideoMode::GetDesktopMode();

El bucle principal

Una vez creada la ventana debemos hacer el bucle principal del juego.

bool Running = true;
while (Running)
{
    App.Display();
}

return EXIT_SUCCESS;

Para cerrar el bucle del juego basta con cambiar la variables Running a False. Esto podríamos hacerlo al cerrar la ventana o al presionar la tecla Escape. Veremos la forma de detectar estos eventos en el próximo tutorial.

La única sentencia en nuestro bucle principal es App.Display();. Esta es la única sentencia necesaria para mostrar el contenido de nuestra ventana en la pantalla. Debe estar en el bucle principal y siempre ser la última en llamarse, después de dibujar todo lo necesario y actualizar todas las variables.

Como puedes ver no hay nada más que hacer después del bucle, al Destructor de la ventana se encarga de cerrar todo. EXIT_SUCCESS es una constante que vale 0, lo que debe devolver un programa si todo ha ido bien.

• Descargar ejemplo

Nota: Artículo basado en el tutorial oficial.

• SFML – Manejando eventos
• SFML – Instalación y configuración
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• Una introducción a la STL I – Introducción a los contenedores

Instalar SFML en Linux es bastante fácil, al menos para distribuciones basadas en Debian (Ubuntu entre ellas) ya que los paquetes se encuentran en los repositorios, para otras distros seguro que los paquetes también están. Para instalar en consola:

$ sudo  apt-get build-essential install libsfml-dev libsfml-doc

Con esto ya tenemos la biblioteca instalada en nuestro sistema.

Compilar por consola

Vamos ahora a compilar un programa de prueba, creamos un archivo .cpp con el siguiente código:

#include <SFML/System.hpp>
#include <iostream>

int main()
{
    sf::Clock Clock;
    while (Clock.GetElapsedTime() < 5.f)
    {
        std::cout << Clock.GetElapsedTime() << std::endl;
        sf::Sleep(0.5f);
    }

    return 0;
}

Guardamos el archivo y pasamos a compilarlo.

$ g++ -o pruebas ./pruebas.cpp -lsfml-system

Con esto compilamos el programa, como ves enlazamos sfml-system que es el archivo que usamos, pero en nuestros programas podemos tener otras partes de SFML, como sfml-graphics o sfml-window. Para enlazar varios archivos es del mismo modo:

g++ -o ... -lsfml-graphics -lsfml-window -lsfml-system

Compilar con CodeLite

Hay un IDE que me gusta mucho llamado CodeLite vamos a aprender como usarlo con SFML. Lo primero es bajar de aquí la versión de vuestro sistema. Una vez instalada abrimos.

Vamos a crear un espacio de trabajo, un proyecto y configurarlo. En el menú superior:

Workspace –> New Workspace…

A continuación volvemos al menú de espacio de trabajo para crear un proyecto

Workspace –> New Project

Lo dejamos como se muestra en la imagen. A la izquierda tenemos el árbol del espacio de trabajo con nuestro proyecto recién creado.

Abrimos el archivo main.cpp borramos su contenido y ponemos el ejemplo anterior.

#include <SFML/System.hpp>
#include <iostream>

int main()
{
    sf::Clock Clock;
    while (Clock.GetElapsedTime() < 5.f)
    {
        std::cout << Clock.GetElapsedTime() << std::endl;
        sf::Sleep(0.5f);
    }

    return 0;
}

Ahora abrimos las propiedades del proyecto: Workspace –> Open Active Project Settings… y ahi en el menú desplegable de la izquieda vamos a Common Settings –> Linker ahi en options enlazamos las librería, en este caso usamos -lsfml-system. Puedes poner varias simplemente dejando un espacio o seprandolas con “;”

Pues ya está todo listo, Pulsamos F7 para compilar y luego Ctrl+F5 para ejecutar.

En Windows

Para Windows os dejo un excelente video de como intalar en Visual C++ 2010.

http://www.youtube.com/watch?v=-uHGZGgMETg

• SFML – Manejando eventos
• SFML – Abriendo una ventana
• Introducción a PySFML
• Proyecto Generic Game Engine
• [Curso C++] – Primer Juego – Game Over!

IberOgre ofrece documentación sobre programación de videojuegos en 3D utilizando el motor open source Ogre3D. Partiendo de conocimientos de programación de videojuegos básicos en 2D, cubre un amplio rango de materias. Desde conceptos matemáticos y física elemental del espacio hasta el uso del motor Ogre.

Está concebida para cubrir el hueco de la escasez de documentación es castellano referente a Ogre así como proporcionar una guía para desarrollar juegos 3D multiplataforma (GNU/Linux y Windows) con herramientas libres.

El principal autor de IberOgre es David Saltares y junto son IberOgre está desarrollando un juego de ejemplo llamado Sion Tower. En su blog podéis ver cosas interesantes acerca del proyecto que no se ciñen solo a Ogre.

Web: IberOgre

• Gran Pack de desarrollo de videojuegos
• Una introducción a la STL I – Introducción a los contenedores
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• SFML – Manejando eventos

Me gustaría pedir algo a los lectores. Como sabéis esta web ofrece todo el contenido gratis y sin publicidad. Ahora mismo mantener la web solo nos cuesta dedicación ya que el servidor nos lo ceden, pero en un futuro puede que no sea así.

Hemos puesto el proyecto en Lánzanos para ver si cubrimos algo del tiempo empleado y damos algo a cambio del servidor prestádo. De momento solo necesitamos tu voto para que el proyecto pueda recibir financiación.

Vota: http://www.lanzanos.com/caja/proyecto/489/

• Bienvenidos a Razón Artificial 2.0
• Iberogre – Documentación de Ogre en español
• Volverán los tutoriales
• Cambio de filosofía del blog
• Sobre qué quieres que escribamos

La escena por defecto en Blender se parece a esto, un cubo normal en perspectiva.

Cámara Ortográfica

Lo primero que queremos hacer es cambiar la cámara a ortográfica. Hacemos click derecho en la camara para seleccionarla, cambiar al panel de edición (F9) y haga clic en el botón “ortográfica”.

Nuestro cubo ahora se verá en la perspectiva correcta. En los juegos isomñetricos las líneas perpendiculares al plano de tierra deben ser paralelas entre sí. Dicho de otra manera, los objetos más lejanos en vista ortográfica no parecen más pequeños.

Ángulo de cámara isométrica

El siguiente paso es establecer el ángulo de cámara en el modo isométrico perfecto. En los videojuegos cuando decimos “isométrico” por lo general significa que el tamaño de los tiles es dos veces el ancho del alto (por ejemplo, 64×32). Con la cámara seleccionada “N” para abrir el menú de “Transform Properties” (Propiedades de transformación). Las opciones las dejamos de la siguiente manera: RotX = 60, RotY = 0, RotZ = 48. Y ya que estamos aquí vamos a poner la cámara en un lugar predecible: LocX = 5, LocY = -5, LocZ = 5.

Si se mide la cara superior de este cubo, se puede comprobar que el ancho en píxeles es exactamente el doble que la altura.

Tamaño de Render

Queremos adaptar el tamaño del render para que se adapte a nuestra salida deseada. Para manter sencillo este tutorial, vamos a remplazar el cubo por defecto por un plano predeterminaso. (Seleccionamos el cubo y lo eliminamos. Ass -> Mesh -> Plane para añadir el plano).

Vamos a cambiar el tamaño del render. Cambia al panel de escena(F10). Establecer SizeX = 64, SizeY = 32. Cambiamos también el formato de salida de JPG a PNG y el color de RGB a RGBA.

Ahora la imagen PNG tiene el tamaño correcto, pero el tile obviamente no.

Cámara LocZ y la escala del objetivo

Ahora hay que ajustar el LocZ de la cámara y la escala del objetivo hasta que el tile se ajuste a la imagen PNG.

Esta es la manera en la que lo hago: Cambio a la vista cámara (NumPad 0) Hasta la línea de puntos exterior es lo que va a ser nuestra imagen. Con esto como referencia. Camara LocZ esta en el menú “Transform Properties” (Seleccionar la cámara y pulsar N) y Lens Scale está en el “Editing Panel” (Encima de donde se elige la vista ortográfica).

En esta caso el me da salen los siguientes valores LocZ = 4.08 y la Escala del objetivo = 2.75. Te daras cuentas que las esquinas se salen de la zona del render, que se salga un poco ayuda acuando RGBA con AA esta activado. Los bordes de los tiles tendrán un valor Alpha que se vería sobre tiles adyacentes.

Sobremuestreo/Anti-Aliasing

La salida es un poco borrosa, pero es difícil de ver, vamos a aplicar una textura bonita al plano.

Definitivamente borrosa. Para los sprites pequeños de los tilesets queremos un filtro anti-aliasing diferente. En el panel de escena (F10), cambiar el filtro de Gauss (heavy blur) a CatRom o Mitch (CatRom muestra más detalles, pero es un poco ruidoso, me gusta para las texturas arenosas que uso en mi juego).

El resultado es mucho más nítido.

(Si desea aún más nítida, pruebe a desactivar MipMap e Interpol en la configuración de la textura de “Map Image”).

Sky a Key

Si aumentas la imagen resultante notarás un azul muy leve en el contorno de todo el tile. Esto se debe a que, por defecto, hacer un alpha-layer render (RGBA Mode) se mezcla el color del cielo en los píxeles con transparencias (0 < A < 1). Este azul se mostrará cuando se muestren tiles juntos. Tenemos que cambiar de "Sky" blending a "key" para mantener bien los bordes.

Iluminación

Por último, tenemos que tener una iluminación uniforme en el tile. Si se mira de cerca, el otro extremo del tile se ve más oscuro que el extremo mas cercano. Por defecto, las luces en Blender iluminan dependiendo de la distancia de la fuente de luz. Si cambia la fuente de luz a “Sun” la iluminación no disminuye con la distancia. Con un tipo de fuente de luz “Sun” se puede elegir el ángulo de la luz. Esta ángulo debe ser (generalmente) el mismo para todos los tiles del tileset y del juego. (En mi proyecto OSARE RPG uso RotX = 27, RotY = 25, RotZ = -12 que proyecta las sombras hacia atrás y a la derecha.

Ahora tiene una iluminación uniforme:

El tile en acción

Ahora vamos a cargar el tile en el editor de mapas libre Tiled.

Los tiles encajan correctamente y se ven claros. Por supuesto son repetitivos, por lo que querrás variedad de tiles.

Pero esto solo es la base, guarde este archivo y utilícelo como base para hacer otros. (Descargar fichero .blend).

Tiles con altura

Cuando llegue el momento de añadir tiles con altura ajuste el tamaño del render, el LocZ de la cámara y la escale del objetivo de nuevo. Un ejemplo: He añadido el cubo por defecto de nuevo y quiero hacerlo un tile de alto. 64×64 no será suficientemente alto como para meter el bloque, así que voy a cambiar el tamaño del render a 64×96 y mover la base del cubo a la parte inferior de la zona de render. Vea la captura de configuración debajo.

Y el resultado. (Tenga en cuenta que en esta vista previa he deshabilitado OSA/anti-aliasing de los tiles. OSA en realidad podría ayudar en algunos tiles).

Otras consideraciones

• Ayuda usar una escala fija para tus tiles. Por ejemplo: 1 Unidad de blender = 1 metro y 1 tile = 1 metro cuadrado. De esta manera podrás mantener los tiles a escala.
• Es posible que quieraas incluir sombras en tiles con altura. Crea un plano grande en (0, 0, 0) y ponle un material con Shaders con la opción “OnlyShad [ow]“.
• Si tienes muchas tiles diferentes puedes montar tilesets de manera fácil con ImageMagick.
• Si estas usando verdadero isométrico en juegos 2:1 pseudo-isométricos, cambia la cámara RotX de 60 a 54.736.

Ir a OpenGameArt.com para ver la serie completa de estos tiles marrones.

Written by Clint Bellanger. Released under CC-BY-SA and the GFDL.

Original en inglés

• Tileset isometrico – Grassland
• Otro tileset isométrico muy bueno – Cavernas
• Tileset isométrico de gran calidad
• Pack de gráficos para juegos
• SFML – Manejando eventos

GfxPlace es un sitio web donde puedes encontrar gráficos gratis para tus juegos. Pueden ser usados tanto en proyectos personales como comerciales. La web cuenta con un sistema de etiquetas y categorías para encontrar recursos de temas específicos. En la web abundan plantillas de interfaces gráficas, tecturas, fuentes tipográficas y Sprites 2D.

El autor planea en el futuro abrir la comunidad para que cualquiera pueda subir gráficos, el proyecto solo tiene unos meses, pero es una buena idea una comunidad de gráficos libres, sobre todo para programadores independientes que quieren mostrar sus habilidades.

http://www.gfxplace.com

• Gráficos para prototipos de juegos
• Tileset isometrico – Grassland
• SFML – Juego de ejemplo
• Otro tileset isométrico muy bueno – Cavernas
• Tileset isométrico de gran calidad

SFML es una biblioteca que permite crear aplicaciones multimedia de manera sencilla, tiene soporte para que puedas escribir tus aplicaciones en varios lenguajes y utiliza internamente la funcionalidad que provee opengl.

La poca documentación que existe de esta biblioteca es para SFML que está escrita en C++ y no para las adaptaciones a otros lenguajes, en este artículo voy a tratar de enseñar lo básico acerca de Pysfml. Doy por sentado que tienes correctamente instalado Python y PySFML.

Creando una ventana

Lo primero que tenemos que hacer es importar la bibliotecam a continuación creamos la ventana y por último creamos el llamado loop del juego, pero vamos primero a ver el código y lo explicamos mejor.

from PySFML import sf

window = sf.RenderWindow(sf.VideoMode(640, 480), "Hola Mundo")

run = True
while run:
    events = sf.Event()
    while window.GetEvent(events):
        if events.Type == sf.Event.Closed:
            run = False

        window.Display()

En la primera línea importamos PySFML. En la tercera línea creamos una ventana con sf.RenderWindow como vemos le pasamos dos parámetros (puede recibir más, pero se escapan del objetivo de este tutorial) que son el modo de video que lo establecemos con sf.VideoMode(640, 480) y el título de la ventana que es una cadena de texto.

En la quinta línea creamos una variable booleana auxiliar para controlar el bucle del juego. En la sexta línea empezamos el llamado Game Loop del juego, cuando run valga false será cuando se interrumpa el juego.

En la séptima línea declaramos otro variable llamada events que toma lo que devuelve sf.Event() y lo que devuelve es una lista de eventos que este recogiendo PySFML. La siguiente línea obtenemos los eventos que se proden sobre la ventana con el método GetEvent. En la octava línea comprobamos si el evento es de Closed, es decir, si es un evento de cierre de la ventana. En cuyo caso el la línea 9 cambiamos la variable run a False para salir del bucle.

Por último con la última línea llamamos el método Display() de la ventana que lo que hace es dibujarla. Con esto ya tenemos una ventana vacía con el título “Hola Mundo” que responde a eventos de cierre.

Añadir un Sprite

Ahora vamos a cargar una imagen. Yo voy a poner el logo de Razón Artificial en el centro de la pantalla pero puede ser cualquier imagen, simplemente ponerla en el mismo directorio que el script del ejemplo. Como antes, pongo el código y lo comentamos.

from PySFML import sf

window = sf.RenderWindow(sf.VideoMode(640, 480), "Hola Mundo")

logo_img = sf.Image()
logo_img.LoadFromFile('logo.png')
logo_sprite = sf.Sprite(logo_img)
logo_sprite.SetPosition(200, 100)

run = True
while run:
    events = sf.Event()
    while window.GetEvent(events):
        if events.Type == sf.Event.Closed:
            run = False

        window.Clear()
        window.Draw(logo_sprite)
        window.Display()

Líneas nuevas a partir de la 5. Creamos una variable llama logo_img y le pasamos sf.Image() con esto la creamos un objeto imagen de PySFML. A continuación llamamos al método LoadFromFile() y le pasamos como parámetro la ruta de nuestra imagen. Con esto tenemos nuestra imagen cargada, pero las imágenes no son dibujables en PySFML solo son un recurso. Lo que es dibujable es un Sprite que se pueden crear con una imagen.

En la línea 7 creamos un objeto Sprite llamado logo_sprite pasándole como parámetro nuestra imagen cargada. Ya tenemos nuestro Sprite listo. Los Sprites tienen varios métodos y parámetros que ya veremos en otros artículos, pero uno de ellos es SetPosition(x, y) que recibe los valores de las coordenadas donde queremos mostrar nuestra imagen como vemos en la línea 8.

Es hora de mostrar el Sprite en nuestra ventana. Lo hacemos en la linea 18 llamando al método Draw() de window y pasándole como parámetro nuestro Sprite. En parte es lógico casi se puede leer: ventana.Dubujar(Sprite).

Anteriormente en la lía anterior limpiamos la ventana con el parámetro Clear(), esto lo que hace es borrar la pantalla para dibujar de nuevo. Es lo que hace que al mover nuestro personaje se borre de un lado antes de ponerlo en otro. Este es el resultado:

Esto es una rápida introducción a PySFML, en futuros artículos miraremos esta estupenda biblioteca más en profundidad.

• SFML – Instalación y configuración
• Proyecto Generic Game Engine
• SFML – Manejando eventos
• [BGE] Sistema base del Engine
• Haciendo un Game Engine 2D básico

Abrimos nuevas secciones, reorganizamos todo el contenido que teníamos y por su puesto preparamos mucho más para esta nueva revolución en la comunidad. Continúa leyendo y entérate de todas las novedades.

Volvemos a ser comunidad

Dejamos de ser solo un blog para convertirnos en un lugar de encuentro para desarrolladores. Ahora tenemos Foro donde podrás preguntar dudas, intercambiar información, recursos con otros desarrolladores, etc., Chat y como siempre nos puedes seguir en Twitter.

Reorganizamos el contenido

Todo el contenido ha sido reorganizado en tres grandes áreas:

• Noticias - En ella incluiremos los últimas novedades en la industria y en el Scene. Intentaremos mantenerte informado de todo lo que pasa.
• Artículos – Categorizados en 5 grandes áreas: Diseño, Programación, Gráficos y Audio. Todos los tutoriales, reviews, cursos, guías, etc. para todo los temas de desarrollo de videojuegos.
• Recursos – Almacén de recursos libres para utilizar en tus proyectos. Códigos, Sprites, Modelos 3D, Música, Sonidos, etc.

También podrás buscar contenido utilizando el buscador o por las etiquetas para temas específicos como Python, Inteligencia Artificial o XNA.

Lo último en portada

La portada ha sido diseñada para tener de un vistazo lo último de la comunidad por lo que podrás encontrar en primera plana las últimas noticias, artículos, recursos, últimos mensajes en el foro y en twitter.

Diseño limpio

Hemos hecho un diseño claro y limpio con páginas amplias en la vista completa para facilitar la lectura de la documentación, las noticias, etc.

Apostamos por una comunidad referente en el desarrollo de videojuegos hispano, esperamos tu participación en el proyecto. Bienvenidos a todos.

• Ayuda a financiar la web: Vótanos en Lánzanos
• Iberogre – Documentación de Ogre en español
• Volverán los tutoriales
• Cambio de filosofía del blog
• Sobre qué quieres que escribamos

Curso Cerrado No se aceptan más participantes hasta la próxima edición.
Presentamos una nueva iniciativa de parte de CreaGames y Razón Artificial. Un curso para iniciarse en la programación de videojuegos, si siempre has querido aprender a programar videojuegos, pero nunca has sabido por donde empezar esta es tu oportunidad.

Características

- Iniciar al alumno en en la programación.
- Enseñar las matemáticas básicas necesarias.
- Curso ameno y divertido, se pretende que sea a base de elaborar juegos que van creciendo en dificultad.
- Python como lenguaje de programación. Sencillo para iniciarse y entender los conceptos sin tener que pelearte con el lenguaje.
- Aprendizaje de estructura de datos básicas.
- Programación gráfica utilizando la biblioteca gráfica Pygame

A quien va dirigido

A todo aquel que alguna vez a intentado aprender a programar videojuegos y que por una cosa u otra no lo ha conseguido. El curso es para gente que quiere aprender desde cero, no es un curso avanzado. No se verán juegos 3D ni serán capaces de hacer tu propio Final Fantasy al terminar. Se enseñará a programar en un lenguaje, gestionar proyectos de software, estructura de datos y manejo de programas auxiliares para la programación. Se pretende que el alumno sea capaz de saber hacer juegos 2D usando Python y Pygame, pero más que eso que se inicie en este mundo y que aprenda sobre el proceso de desarrollo de videojuegos que vale para otros lenguajes, tecnologías y juegos en 3D.

Método de aprendizaje

Enseñar leyendo un libro o un tutorial a veces puede ser liante y confuso y se puede perder la motivación. Mi objetivo es enseñar cumpliendo objetivos.

La idea es tener unos alumnos fijos a los que pueda supervisar y ayudar. Mediante prácticas, dudas por email, charlas por chat.

En principio no quiero poner un límite de alumnos, vamos a ver la acogida que tiene, pero se intentará que sea un grupo reducido del que me pueda encargar.

Requisitos

- Ganas de aprender a programar videojuegos. Es un trabajo de cabeza que requiere lógica y probar y probar. No es apretar dos botones. Hay que leer mucho.
- Tener tiempo para dedicarle. Al menos una hora al día.
- Ser serio y constante. Si alguien se apunta y abandona el curso por motivos no justificables le quedará prohibida la inscripción en nuevos cursos. Pensar si de verdad se puede o no antes de inscribirse, no pierdas mi tiempo ni el de otros posibles alumnos.

Inscripción

Para inscribirse dejar un comentario y mandar un correo a adrigm@creagames.es con los siguientes datos.

- Nombre
- Correo de contacto.
- Edad.
- Conocimientos previos en la programacion de videojuegos.
- Motivo por el que merecen ser elegidos.

• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• Gran Pack de desarrollo de videojuegos
• Arkanoid V – Creando la bola
• Arkanoid IV – Creando la pala

Intentaré escribir buenos artículos de desarrollo de videojuegos sin centrarme en un lenguaje o tecnología. Todo el que sepa ya programar lo básico sabe que lo difícil no es escribir el código sino saber como escribirlo, como hacer las cosas para que quede bien y sea eficiente y eso trataré de poner aquí.

Yo ahora mismo estoy embarcado en crear juegos para IOS, así que puede que haya artículos relacionados con objective-c, mac, iphone, etc. Pero intentaré que los dedicados a la IA y el desarrollo de videojuego sea lo más genérico posible.

Aprovecho para agradecer a todos los que comentan en el blog y dan las gracias, que son muchos, muchas veces no contesto por no llenar los post de comentarios alejados del tema, pero se agradecen. Espero que todavía alguien me siga, si es así os prometo mucho más contenido este año.

• Ayuda a financiar la web: Vótanos en Lánzanos
• Bienvenidos a Razón Artificial 2.0
• Cambio de filosofía del blog
• Sobre qué quieres que escribamos
• Repositorio en github para el Engine-RPG

• Ver charla

• Curso programación de videojuegos
• Gran Pack de desarrollo de videojuegos
• IA en videojuegos – Persiguiendo y evadiendo II
• Arkanoid V – Creando la bola
• Arkanoid IV – Creando la pala

Ahora después de unos días de reflexión, he decidido seguir el camino contrario. Escribir en un blog es gratificante, ver tu contenido publicado y que a otros les pueda servir enorgullece a uno, pero llega un momento en el que uno se tiene que plantear si quiere aprender o quiere enseñar. Por eso el blog pasará a ser simplemente mi web personal, en la que publicar mis proyectos, apuntes, notas, etc.

Seguirá todo relacionado con el mundo de los videojuegos, la inteligencia artificial y la programación, pero ahora estará mas centrada en cosas personales o simplemente  que sean de mi interés. ¿Y qué significa todo esto, no habrá más tutoriales? Pues no lo sé, depende, quizás algún día escriba pequeñas guías, experiencias, problemas que me surjan… a modo de bloc de notas personal y quizás os pueda ser útil.

Todo el contenido que hay seguirá estando disponible, pero ya no tendré la presión de escribir un artículo, tutorial, guía, etc. Simplemente escribiré para mí. Quizás incluso ahora liberado de esa presión escriba mucho más y cosas más interesante, no sé a donde llevará esta nueva etapa.

• Ayuda a financiar la web: Vótanos en Lánzanos
• Bienvenidos a Razón Artificial 2.0
• Volverán los tutoriales
• Sobre qué quieres que escribamos
• Repositorio en github para el Engine-RPG

Antes de nada quiero aclarar que no soy partidario de la piratería ni del todo “gratix” en el que parece que se ha convertido Internet. Por otro lado, si soy partidario de nuestro derecho como ciudadanos al acceso a la cultura. Mucha gente no puede permitirse comprarse todo juego, libro o película que sale al mercado, ¿Entonces como elegir? Pienso que para eso si está internet, puedes probar un juego o leer los primeros capítulos de un libro antes de comprarlo y ver si es realmente lo que quieres o mejor esperar a otra cosa.

Con esa mentalidad he hecho este pack. Una gran colección de libros y documentos sobre el desarrollo de videojuegos, hay mezcla de material tanto con copyright como material libre o con licencias abiertas. Por favor, te pido que si de verdad encuentras útil alguno de los libros con copyright y crees que de verdad puedes sacarle provecho, ve y compralo. Ganarás mucho teniendo el libro en papel y estarás pagando sabiendo ya de ante mano lo que compras.

Sobre el pack decir que cuenta con cientos de documentos de Diseño de niveles, Diseño de videojuegos, Programación, DirectX, OpenGL, Inteligencia Artificial, Matemáticas, Física, Engines, Gráficos y un largo etc son unos 2GB de documentación a cerca de la creación de videojuegos.

Está dividido en 16 partes de 100MB menos la última que tiene 50MB.

1. http://www.megaupload.com/?d=ZRB6LMT0
2. http://www.megaupload.com/?d=IHLAYGBT
3. http://www.megaupload.com/?d=RT3JJ9D0
4. http://www.megaupload.com/?d=K1SAGFGQ
5. http://www.megaupload.com/?d=E8HO5WT0
6. http://www.megaupload.com/?d=VW70J0E4
7. http://www.megaupload.com/?d=JOR6PHEE
8. http://www.megaupload.com/?d=X9X1SJXI
9. http://www.megaupload.com/?d=YOYVLJSC
10. http://www.megaupload.com/?d=AGVSH574
11. http://www.megaupload.com/?d=B1WOYA8H
12. http://www.megaupload.com/?d=WVSAXDZ0
13. http://www.megaupload.com/?d=784SYZFR
14. http://www.megaupload.com/?d=1N9JP834
15. http://www.megaupload.com/?d=XNFWJZN6
16. http://www.megaupload.com/?d=EKCOIVO1

• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Algoritmo Minimax, un jugador incansable
• Muestra del Engine de PyIA
• Pathfinding A* en Python. Parte I
• El salto del caballo, backtracking

Ya he hablado en el blog acerca de este programa, pero ahora paso a hacerle un análisis en profundidad ya que es un programa que utilizo mucho y un buen recurso.

Desarrollar videojuegos no es solo escribir código. Conlleva una gran parte de diseño y diferentes recursos como gráficos, audios, modelos, etc. Teniendo los recursos y un buen compilador se podría crear un juego, pero eso sería tan absurdo como utilizar un ordenador a base de 1 y 0, se puede, pero nadie lo hace. Con los juegos pasa algo parecido lo que se crea no es directamente el juego en sí, sino que se hacen una serie de herramientas que faciliten el proceso y abstraigan ciertas partes de bajo nivel. Engines gráficos, de física, de inteligencia artificial que se programan a bajo nivel para hacerlo eficiente y luego son llamados desde lenguajes de scripts más sencillos para darle lógica al juego. Otra de las grandes herramientas son los editores de nivel. En los que se compone la acción con los gráficos y demás para luego ser cargados desde el juego y de los editores de niveles vamos a hablar.

Lo que he explicado arriba no se aplica solo a grandes producciones juegos en 2D también precisan de editores de nivel, editores de sprites e incluso algunos complejo de ciertos engines que abstraigan del bajo nivel de bibliotecas como SDL o Allegro.

Las compañías que cuentan con recursos y presupuesto suele crear sus propias herramientas y formatos propios para sus proyectos, pero para amateur a veces nos interesa centrarnos en crear videojuegos y aprovecharnos de herramientas libres para crear nuestros juegos y ahí es donde entra en juego Tiled Map Editor.

El Tiled es un editor de mapas libre escrito en C++ y con la biblioteca QT. El programa es multiplataforma y de propósito general. Como su propio nombre indica esta hecho para juegos que tienen sus mapas en forma de tiles (casillas) esto es la gran mayoría de los juegos 2D.

Características

• Mapas tanto ortogonales como isométricos.
• Formato de archivo XML.
• Soporte para múltiples capas tanto de tiles como de objetos.
• Soporte para múltiples tilesets.
• Muy personalizable todas las propiedades de mapas con parejas de clave valor.
• Soporte de color clave y transparencias.
• Tamaño de los tiles y mapas totalmente personalizable.

Mapas ortogonáles e isométricos

Puedes crear mapas tanto en la vista clásica de los juegos 2D, como en la tan usada simulación del 3D a través de la vista isométrica. En la imagen inferior podemos ver la vista ortogonal.

Apreciamos como el editor cuanta con herramientas básicas en la parte superior para el dibujado de mapas como el tampón, el cubo de pintura para rellenar o la goma de borrar, con un par de usos se controlan todas estas herramienta. En la parte derecha nos encontramos con dos paneles, en la parte superior el panel de capas. Desde este panel podemos gestionar en que capa queremos pintar, cambiarles el nombre, ocultarlas o modificarlas. A parte de elegir su transparencia. Debajo de este panel nos encontramos con el panel de tilesets que se gestionan mediante pestañas. Ambos paneles son arrastables y se pueden poner como ventanas flotantes o acomodarlos en cualquier lugar del editor y con cualquier tamaño.

En la imagen superior podemos ver un mapa isométrico con dos tilesets abiertos.

Tamaño de los tiles y mapas totalmente personalizable

Cuando creas un nuevo mapa te da a elegir si será ortogonal o isométrico. También te deja elegir el número de tiles de ancho y alto y el tamaño que tendrán los tiles. Como vemos totalmente configurable.

Color clave y tilesets

Cuando se carga un nuevo tileset al mapa nos deja elegir el nombre, la imagen del tileset. El tamaño de los tiles y el margen y espacioado, esto es, la distancia visual en las que el editor debe separar los tilesets para un correcto mapeado. También nos deja elegir si usar color transparente. En el caso de marcarlo podemos escoger un color que representar como transparente, muy útil para si tienes tilesets con un fondo puesto.

Capas de objetos

Una característica muy interesante son las capas de objetos. Esto son capas especiales en las que se pueden colocar objetos rectangulares con la precisión a pixel y sin estar ligadas a los tiles.

Como podemos ver en la imagen superior podemos crear tantas capas de estas como queramos y asignarles diferentes colores y propiedades. Cada objeto que creemos tiene un cuadro de propiedades accesibles desde el boton derecho.

En este cuadro de diálogo podemos configurar diferentes datos del objeto como el nombre, el tipo, la posición, tamaño. Debajo tambiñen tenemos una lista con dos campos nombre y valor. Estas listas nos permitan definir propiedades propias y definir un valor. Como ves muy personalizable tu creas tus propias propiedades y sus valores para tu propio juego.

Estos cuadros de propiedades valor no solo estan disponibles en los objetos. También los poseen los tilesets, las capas, los mapas y en realidad casi todos los elementos para que puedas definir propiedades clave valor de casi todo. Debajo podemos ver un ejemplo de las propiedades del mapa y posibles usos. Pare definir una música de fondo, los enemigos, etc. Todo depende de tu proyecto.

El formato TMX

Una vez tengas tu mapa listo querrás guardarlo para poder usarlo en tu juego, pero ¿Como uso los datos del mapa? Cuando guardas un mapa el programa crea un fichero con extensión .tmx esto fichero en realidad no es más que un archivo XML que contiene todo los datos de nuestro mapa. Solo deberemos leer el archivo XML desde nuestro juego (casi todos los lenguajes tienen bibliotecas para trabajar con XML) y usar los datos como creamos convenientes. Veamos un ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<map version="1.0" orientation="isometric" width="40" height="40" tilewidth="64" tileheight="32">
 <properties>
  <property name="prop_map" value="25"/>
 </properties>
 <tileset firstgid="1" name="tiled_dungeon" tilewidth="64" tileheight="128">
  <image source="../graphics/tilesets/tiled_dungeon.png" width="1024" height="1920"/>
 </tileset>
 <layer name="Capa de Patrones 1" width="40" height="40">
  <properties>
   <property name="tipo" value="base"/>
  </properties>
  <data encoding="base64" compression="gzip">
   H4sIAAAAAAAAA+3SUQoAIQgAUa9Q9z9sN0jMFJUZ8K9dHpYI/WopU8G0L1Pdp+03Yu8W36u9q8+69+z7ffF5zlub5vv9f+/gw2fxeb+f5ou+L3y57x0fPnz48PXwERERUUwH5o9HhQAZAAA=
  </data>
 </layer>
 <layer name="Capa de patrones 2" width="40" height="40" visible="0">
  <data encoding="base64" compression="gzip">
   H4sIAAAAAAAAA+2V3QrCMAyF8066+f+H3ggK3ikivv9jWGGwWGNYllS9OB8cKGvWnaVNSgQimCfVTPdG/NnqB76q5tvTDrGDwl4kKkNs/UFXZc6bc4u/Poyc7x+Tdo32fjtvbJW5JdnyvlHWetbPmNp/GSZNmIcDm+NaK2tqeyf9lxYv7ROP71M7Vn8Les0R10mIP3/ZnxXub0bt2bkIY+mZ1tMi/JWs/ej8RROdP+nMauL1X8qfN3+l68N7/rz+eH+/CeO8/rQ7WboPvP4i61Pq79Z+mxPpL+I85cCfD/jzAX8+4M+H1t+t6nIfAAAAAOA/eACNJESSABkAAA==
  </data>
 </layer>
 <layer name="Capa de patrones 3" width="40" height="40" visible="0">
  <data encoding="base64" compression="gzip">
   H4sIAAAAAAAAA+3QMQrAIAxGYa+cpeBcsL1TPZwdHBzE0KGJ4vvgB4cMD0PAbpJ3ALb1vMveEQCA5UnzPupGzrqZzd5nKXoHfHB5B3Ro/3ebVOAvop8AAACgUQAv8zdRABkAAA==
  </data>
 </layer>
 <objectgroup name="Capa de Objetos 1" width="40" height="40">
  <object type="start" x="556" y="650"/>
  <object x="266" y="692" width="149" height="135"/>
 </objectgroup>
 <objectgroup color="#ffaaff" name="Capa de Objetos 2" width="40" height="40">
  <object x="188" y="193" width="110" height="92"/>
 </objectgroup>
</map>

Como puedes ver si te fijas un poco, contiene todo los datos que hemos configurado en nuestro mapa por un sistema de etiquetas XML, nada del otro mundo. Quizás la única parte inquietante sería esta.

<layer name="Capa de patrones 3" width="40" height="40" visible="0">
  <data encoding="base64" compression="gzip">
   H4sIAAAAAAAAA+3QMQrAIAxGYa+cpeBcsL1TPZwdHBzE0KGJ4vvgB4cMD0PAbpJ3ALb1vMveEQCA5UnzPupGzrqZzd5nKXoHfHB5B3Ro/3ebVOAvop8AAACgUQAv8zdRABkAAA==
  </data>
 </layer>

Esta parte como vemos guarda la información de las capas de tiles, pero los datos vienen codificados en base64 y comprimidos con gzip. ¿Por que esto? Por eficiencia, son la parte que más ocupa del archivo ya que contienen la lista de etiquetas de la grilla, algo como esto es lo que pone una vez descomprimido y decodificado.

<tile gid="17"/>
<tile gid="17"/>
<tile gid="5"/>
<tile gid="8"/>
<tile gid="0"/>

Como ves contiene en orden de arriba a abajo y de izquierda a derecha el tile que tiene la capa empezando por el uno. Es decir si la capa en el primer tile arriba a la izquierda la segunda imagen del tileset entonces contendrá un 2. Es importante resaltar que se empieza a contar en 1 y se deja el 0 para los casillas que no tienen ningún tile.

Los mapas sin comprimir y codificar ocupan entre 40 y 50 veces más, por lo que es altamente recomendable, luego desde el juego y el lenguaje de programación es fácil programar un algoritmo que descomprima y decodifique el mapa.

Página oficial: http://www.mapeditor.org/

• Tileset isometrico – Grassland
• SFML – Juego de ejemplo
• Iberogre – Documentación de Ogre en español
• GfxPlace – Gráficos para juegos gratuitos
• Gran Pack de desarrollo de videojuegos

¡Tenemos canal de irc! Debido a que paso bastante tiempo en otros canales de irc, he decidido crear un canal para razón artificial para el que desee hablar o preguntar dudas acerca de la creación de videojuegos. Podéis entrar al canal desde el Webchat que hemos añadido al blog.

Pero es mucho mejor disponer de un cliente nativo de irc como xchat. Nos podéis encontrar en el freenode en el canal #razonartificial. Yo estaré por allí, espero que se animen a entrar.

• No hay entradas relacionadas.

• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia
• IA en videojuegos – Persiguiendo y evadiendo II
• IA en videojuegos – Persiguiendo y evadiendo I
• Arboles e inteligencia Artificial

Bueno viendo que os gusto el tileset isometrico que mostré ayer, hoy os traigo otro, esta vez de una caverna. Está creado por pfunked y tiene licencia GPL 3.0 Viene preparado para el editor de mapas tiled espero que guste tanto como el anterior.

• Descargar tileset

• Tileset isometrico – Grassland
• Tileset isométrico de gran calidad
• Crear tiles isométricos 2D con Blender
• Gráficos para prototipos de juegos
• Pack de gráficos para juegos

El documento de diseño de videojuegos o Game design document (GDD) es un documento que me parece esencial para el desarrollo de un videojuego medianamente serio. En SionDream han hablado de ello y han elaborado uno para un proyecto que tienen entre manos de crear un juego de ejemplo para Ogre3D.

Es totalmente recomandable revisarlo si estás planeando el diseño de un videojuego ya que tiempo que inviertas en este documento son quebraderos de cabeza y correcciones que te evitas en la fase de desarrollo. Dejo la entrada en la que lo explica y el documento de ejemplo que han creado.

• Sobre Game Design Document
• GDD de ejemplo

• GameDevLesson – Crear videojuegos
• Gran Pack de desarrollo de videojuegos
• Conceptos de Diseño de Videojuegos

Os traigo un tileset isométrico de gran calidad para exteriores, no abundan los tilesets libres y mucho menos isométricos, pero este es muy bueno. El tileset tiene licencia CC-BY 3.0 y pertenece a Yar. los tiles son de 64×64 y son perfectos para prototipos.

La imagen superior está realizada con el tileset, a mi la verdad que no me parece para nada una imagen creada a base de tiles.

• Descargar tileset

• Tileset isometrico – Grassland
• Otro tileset isométrico muy bueno – Cavernas
• Crear tiles isométricos 2D con Blender
• Gráficos para prototipos de juegos
• Pack de gráficos para juegos

En principio prestamos atención a 3 cosas:

• El fichero Program.cs
• El fichero Game1.cs
• MiPongContent (Content)

Los dos primeros son los únicos ficheros de código que nos crea Visual Studio que pasamos a comentar a continuación. El Content es el manejador de contenido es aquí donde cargaremos los diferentes recursos que usemos en nuestros juegos: Imágenes, Sonidos, Fuentes, etc.

El archivo Program.cs

using System;

namespace MiPong // Namespace del juego que es el nombre del mismo
{
#if WINDOWS || XBOX
    static class Program
    {
        /// <summary>
        /// Este es el punto de entrada al juego, empieza ejecutandose aquí.
        /// </summary>
        static void Main(string[] args)
        {
            using (Game1 game = new Game1()) // Crea un objeto game de la clase Game1 (nuestro juego).
            {
                game.Run(); // Lanza el juego con el método Run().
            }
        }
    }
#endif
}

Bueno Como vemos por los comentarios que he puesto en el código este archivo es el principal de nuestro proyecto y se encarga de crear la clase del programa y el método main que es el punto de entrada a los porgramas C#. Luego dentro crea un objeto Game1 que es la clase de nuestro juego (el otro archivo) y llama a su método Run() que se encarga de entrar en el bucle del juego.

El archivo Game1.cs

El archivo Game1.cs tiene bastanes cosas, en este tutorial explicaremos la estructura general y lo que es relevante de momento. Lo pongo entero y vamos explicándolo paso a paso.

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Media;

namespace MiPong
{
    /// <summary>
    /// This is the main type for your game
    /// </summary>
    public class Game1 : Microsoft.Xna.Framework.Game
    {
        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        public Game1()
        {
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";
        }

        /// <summary>
        /// Allows the game to perform any initialization it needs to before starting to run.
        /// This is where it can query for any required services and load any non-graphic
        /// related content.  Calling base.Initialize will enumerate through any components
        /// and initialize them as well.
        /// </summary>
        protected override void Initialize()
        {
            // TODO: Add your initialization logic here

            base.Initialize();
        }

        /// <summary>
        /// LoadContent will be called once per game and is the place to load
        /// all of your content.
        /// </summary>
        protected override void LoadContent()
        {
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);

            // TODO: use this.Content to load your game content here
        }

        /// <summary>
        /// UnloadContent will be called once per game and is the place to unload
        /// all content.
        /// </summary>
        protected override void UnloadContent()
        {
            // TODO: Unload any non ContentManager content here
        }

        /// <summary>
        /// Allows the game to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing audio.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Update(GameTime gameTime)
        {
            // Allows the game to exit
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
                this.Exit();

            // TODO: Add your update logic here

            base.Update(gameTime);
        }

        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.CornflowerBlue);

            // TODO: Add your drawing code here

            base.Draw(gameTime);
        }
    }
}

Primero tenemos los using que se encargan de importar las partes de .Net y XNA necesarias, vemos algunos de los imports de XNA ahí con respecto a los típicos de un programa en C#.

A continuación abrimos el Namespace de nuestro juego que se llama igual que nuestro proyecto en nuestro caso MiPong. Todas las clases que escribamos para nuestro proyecto deberían de estar dentro de este Namespace.

Ya dentro del Namespace vemos solamente la creación de una Clase, la clase Game1 que hereda de Microsoft.Xna.Framework.Game y será la clase principal de nuestro juego, es de la que creamos el objeto en el archivo Program.cs. Vamos a comentar la clase.

Lo primero que nos encontramos son dos variable de clase:

GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;

Son el manejador de gráficos y de sprites, muy útiles y usados. Ya los veremos en profundidad a continuación.

Luego viene el constructor de la clase:

public Game1()
        {
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";
        }

Simplemente crea el GraphicsDeviceManager que es el encargado de dibujar en pantalla. La otra línea define el directorio del contenido, de momento no nos preocuparemos por esto porque no vamos a tener que tocar el constructor.

protected override void Initialize()
        {
            // TODO: Add your initialization logic here

            base.Initialize();
        }

Este método solo se ejecuta una vez, al principio y en el se debe iniciar toda la lógica del juego, es decir, dar valores a variables, crear objetos necesarios, etc.

protected override void LoadContent()
        {
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);

            // TODO: use this.Content to load your game content here
        }

Este método también se carga una sola vez y se usa para cargar el contenido, imagenes, texturas, etc. Dentro creamos el spriteBatch que lo usamos para dibujar texturas en pantalla. En XNA todos los sprites son texturas.

 protected override void UnloadContent()
        {
            // TODO: Unload any non ContentManager content here
        }

El método UnloadContent es para quitar contenido, de momento no lo usaremos.

protected override void Update(GameTime gameTime)
        {
            // Allows the game to exit
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
                this.Exit();

            // TODO: Add your update logic here

            base.Update(gameTime);
        }

El método Update, es de los más importantes se ejecuta continuamente y en el deberemos poner todo lo que necesita ser comprobado constantemente. Teclado, Colisiones, Movimiento, etc.

Dentro tenemos:

 if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
                this.Exit();

Sirve para salir del juego en la Xbox 360 ya que el juego es compatible tanto con WIndows como con Xbox y con muy poco también en Phone 7.

protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.CornflowerBlue);

            // TODO: Add your drawing code here

            base.Draw(gameTime);
        }

Por último el método Draw se encaga de dibujar en pantalla los sprites. También se ejecuta constantemente

De todo esto de momento nos debemos de quedar con que se el contenido se carga en el método LoadContent, la lógica se actualiza en Update y se dibuja con el método Draw, lo demás profundizaremos más adelante.

• Tutorial XNA 1 – Preparándonos para trabajar
• Una introducción a la STL I – Introducción a los contenedores
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• SFML – Manejando eventos

Dependencia e independencia lineal de vectores

Varios vectores se llaman linealmente  dependientes si alguno de ellos se puede poner como combinación lineal de los demás. En caso contrario se dirán que son linealmente independientes. En el último apartado del artículo anterior vimos cuando un vector es combinación lineal de otro.

Base

Tres vectores linealmente indendientes en (En el espacio) forman una base. Si los vectores básicos son perpendiculares entre sí, se dice que la base es  ortogonal. Si además los vectores tienen módulo 1, se dice que la base es ortonormal.

Cuando hemos encontrado una base, cualquier vector de (del espacio) se puede poner como combinación lineal de los vectores básicos, es decir, si es una base de y (el vector v pertenece al espacio) entonces 

La terna  se denomina coordenadas cartesianas de  respecto a la base B.

A partir de ahora tomaremos la base  que es la base canónica de y todas las coordenadas de vectores estarán expresadas en esa base.

Los vectores canónicos i, j y k se corresponden con los vectores , y respectivamente. Como vemos son 3 vectores de módulo uno en la dirección de los tres ejes, por lo tanto podemos representar fácilmente cualquier vector con esa base.

que se representaría de la siguiente manera.

Operaciones con vectores cartesianamente

Anteriormente vimos como hacer operaciones con vectores gráficamente, ahora vamos a ver como hacerlas por métodos matemáticos.

sean  y  dos vectores de entonces:

Determinación de un punto en el espacio

No debemos confundir punto con vector, aunque el punto y el vector tengan las mismas coordenadas como sucede en la imagen superior donde el punto P y el vector tienen las mismas coordenadas.

Coordenadas de un vector determinadas por dos puntos

Sean los puntos  y  se define el vector formado por A y B como:

Por ahora esto que no es mucho, pero al principio puede ser denso. En el próximo artículo espero terminar con vectores y ya para el próximo empezar con el espacio afín que es cuando la cosa se pone interesante.

• Geometría espacial. Vectores
• Función matemática
• El eje cartesiano y el punto
• Funciones de segundo Grado
• Hablemos de física y matemáticas

¿Qué es XNA?

XNA es un Framework desarrollado por Microsoft para desarrollar videojuegos para las plataformas Windows, Xbox 360, Zune y Phone 7. Está desarrollado sobre la plataforma .NET y se programa usando el lenguaje C#. XNA nos provee de muchas clases y recursos que facilitan el desarrollo de videojuegos tanto en 2D como en 3D, ahorrandote toda la parte tediosa de la programación de videojuegos y dejando al programador la implementación y la creatividad.

Requisitos del tutorial

• Tener un ordenador con una versión de Windows instalada.
• Conocimientos de C#. Si conoces otros lenguajes como C++ o Java aprender C# te llevará bastante poco, es un lenguaje sencillo y de alto nivel, pero muy potente.

Instalando lo necesario

Para desarrollar videojuegos en XNA necesitamos Visual C# 2010 Express, XNA Game Studio 4.0 y .NET Framework 4. Está son las últimas versiones a la hora de escribir este tutorial. Se puede conseguir todo el pack y algunos extras más de la siguiente url: http://create.msdn.com/en-us/home/getting_started

Creando un proyecto

Una vez todo instalado ya estamos listos para empezar a programar videojuegos usando XNA. Abrimos el Visual Studio y vamos a Archivo –> Nuevo –> Proyecto…

Elegimos XNA Game Studio 4.0 en el menú de la izquierda y luego seleccionamos Windows Game (4.0) le ponemos un nombre al proyecto, en mi caso lo he llamado MiPong y le damos a aceptar.

Con esto ya tenemos nuestro proyecto creado, en el siguiente tutorial explicaremos los diferentes ficheros creados. Por ahora puedes pulsar F5 y debería ejecutarse nuestro juego que es una simple ventana con un fondo celeste. Felicidades, ya tienes iniciado tu primer juego en XNA.

• Tutorial XNA 2 – Entendiendo el código
• Una introducción a la STL I – Introducción a los contenedores
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• SFML – Manejando eventos

A partir de ahora creo que trabajaré con el y publicaré algunas cosillas sobre XNA. Me gusta mucho Python y Pygame, pero lo cierto es que para videojuegos más allá que para una toma de contacto y empezar en el mundo no es muy útil ya que es algo limitado. He intentado analizar los pros y contras de Python+Pygame y C#+XNA y mis conclusiones son.

Python + Pygame

Ventajas

• Son libres.
• Son multiplataforma.
• Lenguaje y Biblioteca super sencilla. Muy recomendado para inciarse.

Desventajas

• El soporte de gráficos por hardware es limitado, tira mucho de procesador.
• Python es un lenguaje interpretado, para juegos que requieran grandes cálculo eso se nota.
• Soporte solo para 2D.
• La gestión del sonido de Pygame es nefasta. Hay que usar bibliotecas adicionales.

C# + XNA

Ventajas

• C# es un lenguaje moderno y eficaz. Hereda toda la potencia de C++, pero lo hace sencillo.
• Tiene detrás toda la plataforma .NET que hace que tengas un mundo de posibilidades.
• C# es un lenguaje compilado, por lo tanto más velocidad.
• XNA tiene soporte para 2D y 3D.
• El framework XNA construido sobre directX.
• Fácil de aprender a usar, casi todo viene hecho. Es montar las piezas para hacer lo que tu quieres.
• Puedes publicar tu juegos para Xbox 360 y Microsoft Phone.
• Es gratuito. Tando C# express como XNA son gratuitos.

Desventajas

• No es libre (XNA).
• Soporta menos plataformas que Pygame(nada de Linux, ni Mac por ahora).

Por tanto para mí la decisión es clara, me gusta el software libre y linux, pero en el mundo de los videojuegos si quieres dedicarte a eso no es el camino más óptimo actualmente. Así que bienvenido a XNA.

Intentaré terminar los tutoriales de Pygame que tengo a medias, no os los dejaré a la mitad.

• Guía aprender programar videojuegos con C++
• [Curso C++] – Primer Juego – Game Over!
• Curso de Videojuegos en C++ – Presentación
• [BGE] La clase SceneManager
• [BGE] La clase Scene

A lo largo de estos artículos estaremos situados en el espacio por los que las coordenadas de puntos y vectores serán de la forma .

Doy por su puesto que se conoce el concepto de punto en el espacio y que situarlo viene dado por sus 3 coordenadas. Así que pasaré directamente a los vectores.

Concepto de vector

Un vector fijo es un segmento orientado que tiene su origen en el punto y su extremo en el punto .

Un vector tiene 3 elementos:

• Dirección: Es la recta en la que está apoyada la flecha.
• Sentido: Es el que viene indicado por la flecha, hacia donde va.
• Módulo: Es la longitud del vector.

Cálculo del módulo

Para calcular el módulo del vector vamos a verlo con un ejemplo, para simplificar vamos a situarlo en el plano y no en el espacio, es decir, dos coordenadas solamente , pero se aplica el mismo principio al espacio. Tenemos el vector que tiene su origen en el punto  y su extremo en . Pues bien, trazando la distancia que hay desde  hasta y desde a tenemos lo siguiente.

Con esto se nos forma un triángulo rectángulo en el que la incógnita es el buscado módulo, siguiendo el teorema de pitágoras sabemos que.

Las Barras de la h significan valor absoluto, quiere decir que el valor que nos de, si sale negativo, debemos cambiar el signo siempre a positivo. Esto es así porque estamos calculando un módulo que es una distancia y las distancias nunca pueden ser negativas.

Bien aplicada a nuestra ecuación, la h quedaría de la siguiente manera.

Sustituyendo valores nos queda:

Por lo tanto ya tenemos la manera de hallar el módulo de un vector, a modo simplificado solo hay que saber que el módulo equivale a la raiz cuadrada de la suma de sus coordenadas al cuadrado, pero siempre es bueno saber de donde sale la formula.

Equipolencia de los vectores

Dos vectores no nulos son equivalente si tienen igual módulo dirección y sentido.

Vectores libres

A un representante de todos los vectores equipolentes a uno dado, se le llama vector libre. Se designan por o simplemente por una letra minúscula, por ejemplo

Operaciones con vectores

Producto de un vector por un escalar:

Suma de vectores:

Combinación lineal de vectores

Dados varios vectores y varios números reales la expresión se llama combinación lineal de los vectores.

Está es la primera parte acerca de vectores, en el siguiente artículo seguiremos hablando de vectores y ya puede que en el siguiente entremos en materia más interesante.

• Geometría espacial. Vectores II
• Iberogre – Documentación de Ogre en español
• Gran Pack de desarrollo de videojuegos
• Funciones de segundo Grado
• Función matemática

Persiguiendo en la línea de visión

Este algoritmo consiste en que el depredador persigue a la presa en línea recta desde su posición hasta la presa. En teoría el movimiento en línea recta es el camino mas corto entre dos puntos, a menos que haya obstáculos o que la presa esté en movimiento. Si hay obstáculos no es tema de este artículo pues necesitamos combinarlo con un algoritmo de pathfinding, sin embargo, si la presa está en movimiento el algoritmo también es válido, solo que debemos calcular la línea recta en cada interacción del bucle, haciendo que aunque nos movamos en línea recta, al cambiar la dirección de la recta podamos trazar un camino curvo, esté algoritmo es más eficiente que el anterior.

En la imagen anterior supongamos que el círculo es el depredador y la presa es el cuadrado, que está quieta. Los diferentes círculos son las posiciones del depredador en diferentes periodos de tiempo, en los que calcula una nueva recta hacia la presa, como la presa está estática es siempre la misma recta la que debe seguir el depredador.

Vamos a ver dos versiones de este algoritmo una para juegos basados en tiles y otra para espacios continuos.

Línea de visión para juegos basados en tiles

Como dijimos en el articulo anterior los juegos basados en tiles se dividen en casillas. Esto crea una limitación de movimiento que no se aplica a los entornos continuos. En los entornos continuos, las posiciones por lo general se representan con variables en punto flotante. Esas posiciones se asignan a los píxeles de la pantalla más cercanos. Al cambiar de posición en un entorno continuo puedes saltarte algunos píxeles ya que suelen ser lo suficientemente pequeños como para que el movimiento sea fluido y no se noten los saltos de uno a otro.

En los juegos basados en tiles, sin embargo, el cambio de posiciones es más restrictivo. Por su propia naturaleza, el movimiento los movimientos son más dentados y cuadriculados. Si tenemos que nuestros tiles son cuadrados tendremos 8 posibles direcciones a las que movernos.

Como vemos en la imagen ninguna de las 8 direcciones está en línea recta entre el perseguidor y la presa matemáticamente hablando. Esto nos crea un dilema, como movernos en línea recta si no hay línea recta directa entre las casillas.

Lo que necesitamos es una manera de determinar a cuál de las ocho casillas adyacentes hay que trasladarse con el fin de que el depredador avance a la presa en línea recta.

Como mostramos anteriormente, podemos utilizar el algoritmo de persecución simple. Se calculará la ruta más corta posible para el depredador. Así que, ¿Cual es el problema? La estética, me explico. Cuando trabajamos con tiles el método de persecución simple si siempre produce una línea visual directa, veámoslo con una imagen.

Como podemos ver la primera imagen la produce un algoritmo de persecución simple que ya hemos visto. Va moviendo las coordenadas x e y de manera que se acercan a la presa. Cuando la coordenada x coincide con la de la presa pasa a moverse en la coordenada y solamente hasta que también coincide por lo que ha alcanzado a la presa. Sin embargo, podemos ver que no es el camino más directo, como podemos ver el camino de la imagen de la derecha es mucho más directo hacia el objetivo. Cabe destacar que la distancia recorrida es la misma, 8 tiles en este caso, pero el segundo es mucho más natural el movimiento.

Otro problema sería que si en vez de uno tenemos varios perseguidores, llegados a un punto puede que todos estén en la misma coordenada y avanzando en línea hacia la presa, lo que queda algo antiestético, mejor que todos desde su posición avancen en línea recta hacia el objetivo.

El enfoque que vamos a tomar para resolver el problema consiste en utilizar un algoritmo para generar una línea entre los dos puntos que normalmente se utiliza en entornos de píxeles. Así que vamos a tratar nuestro mapa como si los diferentes tiles fueran píxeles gigantes y los cuadros que pasen por esa línea será la ruta que tomara nuestro depredador.

Por tanto el modo de hacer es trazar una línea entre el punto de origen (posición del depredador) y el punto destino (posición de la presa). Luego calculamos los puntos por los que pasa la recta y ya tendríamos los cuadros, por los que pasaría nuestro personaje, pero hay algo más. Hay varias maneras de calcular los puntos por los que pasa una recta, nosotros vamos a usar el algoritmo de Bresenham. Este algoritmo es uno de los más eficientes para dibujar líneas en entornos basados en píxeles. Este algoritmo es ideal porque a diferencia de otros algoritmos no dibuja dos puntos adyacentes en el eje más corto. Veámos.

A la derecha podemos ver los puntos que dibujarían otros algoritmos, es decir, todos los cuadros por los que pasa la recta. Sin embargo como vemos, ese camino no es el más corto ni el más eficiente. Sin embargo a la derecha podemos ver los puntos por los puntos que dibujaría en algoritmo Bresenham. Como vemos no dibuja dos puntos adyacentes en el eje más corto (en este caso el eje x) Obteniendo así un camino directo y optimizado. Creo que se puede ver claramente como el camino de la izquierda es mucho más corto que el de la derecha.

El algoritmo de Bresenham no es nada complicado, pero puede ser lioso porque hay que detectar cual es el punto más a la izquierda y cual más a la derecha. En este artículo podéis ver la explicación del algoritmo, y una implementación en C, tiene la explicación del algoritmo, pero da por supuesto que el eje corto es el x y no el y. Sin embargo en este otro artículo al final del mismo encontré una implementación generalizada para dos puntos cuales quieras. He hecho una traducción a Python del programa.

class Punto:
    def __init__(self, x=0, y=0):
        self.x = x
        self.y = y

    def __str__(self):
        return "(" + str(self.x) + ", " + str(self.y) + ")"

def linea(p1, p2):
    puntos = []
    dx = (p2.x - p1.x)
    dy = (p2.y - p1.y)

    # Determinar que punto usar para empezar y cual para terminar.
    if dy < 0:
        dy = -dy
        stepy = -1
    else:
        stepy = 1
    if dx < 0:
        dx = -dx
        stepx = -1
    else:
        stepx = 1
    x = p1.x
    y = p1.y

    # Bucle hasta llegar al otro extremo de la linea.
    if dx > dy:
        p = 2*dy-dx
        while x != p2.x:
            x += stepx
            if p < 0:
                p += 2*dy
            else:
                y += stepy
                p += 2*(dy-dx)
            puntos.append(Punto(x, y))
    else:
        p = 2*dx-dy
        while y != p2.y:
            y = y + stepy
            if p < 0:
                p += 2*dx
            else:
                x += stepx
                p += 2*(dx-dy)
            puntos.append(Punto(x, y))
    return puntos

p = Punto(2, 3)
q = Punto(9, 6)
puntos = linea(p, q)
for i in range(len(puntos)):
    print puntos[i]

Esto es un programa de prueba que lo implementa, imprimiendo en pantalla los puntos por los que pasaría. He creado una clase punto para manejarlos más fácil, pero el algoritmo en sí está en la función línea que devuelve la lista de puntos que tendría que tomar el depredador.

Ojo, si la presa se mueve de su posición habría que calcular de nuevo las posiciones a moverse, por lo que si la presa está en movimiento hay que calcular en cada bucle la nueva línea, si sabes que la presa se va a mover sí o sí en la siguiente interacción optimizar el algoritmo para que no calcule toda la lista y solo calcule la siguiente posición.

El resultado sería como el siguiente.

Como vemos es un camino mucho más natural y estético, haciendo que las persecuciones sean más inteligentes y realistas. En el próximo artículo veremos el problema en juegos sin tiles, es decir, de espacios continuos con coordenadas en coma flotante.

• Una introducción a la STL I – Introducción a los contenedores
• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• IA en videojuegos – Persiguiendo y evadiendo I
• Arboles e inteligencia Artificial
• Algoritmo Minimax, un jugador incansable

En este artículo nos centraremos en el problema omnipresente de la persecución y la evasión. Ya sea que esté desarrollando un juego de acción espacial, una simulación, estrategia o un juego de rol, es probable que necesites que los personajes no jugadores de la IA tengan que perseguir o huir del jugador. En un juego arcade la situación podría implicar tener naves enemigas que deben perseguir o evadir al jugador o un misil guiado que debe acabar con nosotros. En cualquier caso, necesitas una cierta lógica que permite a los depredadores no jugadores cazar y a sus presas, correr.

El problema de perseguir/evadir consta de dos partes. La primera parte consiste en la decisión de iniciar una persecución o una evasión. La segunda parte consiste en efectuar la persecución o la evasión, es decir, ser depredador o presa. Se podría decir que el problema contiene un tercer elemento: Evitar obstáculos. Tener que evitar obstáculos mientras se persigue o se huye definitivamente complica mucho las cosas, por lo que los algoritmos serán más difíciles de programar. En este artículo no nos centraremos en evitar obstáculos, pero ya hemos visto en el blog varios artículos de pathfinding para evitar obstáculos y en próximos artículos veremos como combinarlos con la persecución y la huida. De la primera parte entra en la toma de decisiones que veremos en futuros artículos cuando tratemos las maquinas de estados finitos y las redes neuronales. Por tanto en este artículo nos centraremos en la parte central del problema que es la persecución o la huida en sí misma.

La forma más simple y el método más común de programar una persecución consiste en actualizar las coordenadas del perseguidor (lo llamaremos depredador) en cada bucle del juego tal que las coordenadas que separan a depredador y presa sean cada vez menores. Este algoritmo no presta atención ni a la velocidad ni a la dirección de la presa y el depredador. Este método es eficaz si el depredador se mueve constante y en la misma dirección y no hay obstáculos, pero tiene sus limitaciones, como veremos.

Este método como vemos es muy básico, hay otros métodos que seguramente te resulten más útiles que junto con un motor de física se pueden combinar para tener en cuenta distancia y velocidades de depredador y presa. En los que el depredador podría tratar de interceptar a su presa y no solo perseguirla. En este caso, la información de posición y velocidad relativa puede utilizarse como entrada para un algoritmo que determinará la actuación adecuada: la dirección de la fuerza, por ejemplo, para guiar al depredador a su destino.

En este artículo vamos a ver varios métodos de persecución y evasión empezando por los métodos más básicos.

Persecución y evasión básica

El método más básico consiste, como ya dijimos, en comprobar las coordenadas de la presa y en función de ella mover nuestras coordenadas, para la evasión es lo mismo, pero hacer justo lo contrario alejarnos lo más posible.

if depredador_x > presa_x:
    depredador_x -= 1
elif: depredador_x < presa_x:
    depredador_x += 1

if depredador_y > presa_y:
    depredador_x -= 1
elif: depredador_y < presa_y:
    depredador_y += 1

Como vemos en el código comprobamos si la coordenada x del depredador es mayor que la coordenada x de la presa en cuyo caso disminuimos la coordenada x del depredador con el fin de acercarlo a la presa, si por el contrario la coordenada x es menor a la de la presa lo que hacemos es aumentarla. Lo mismo se aplica a la coordenada y.

Para la evasión es lo mismo, pero si la coordenada x de la presa es mayor que la coordenada x del depredador pues lo que hacemos es seguir aumentándola con el fin de alejarnos.

if presa_x > depredador_x:
    presa_x += 1
elif: presa_x < depredador_x:
    presa_x -= 1

if presa_y > depredador_y:
    presa_y += 1
elif: presa_y < depredador_y:
    presa_y -= 1

Podemos ver que si las velocidades del depredador y la presa son las mismas y ambas se mueven en una unidad por ciclo de juego como en el ejemplo, la distancia entre ambas va a permanecer constante, el depredador deberá tener algo más de velocidad con este método si quiere alcanzar a la presa.

En juegos basados en tiles el mapa esta dividido en celdas que pueden ser cuadrados, hexágonos, etc. y la posición del jugador está limitada a una de estas celdas. El moviento de jugador está limitado a estos tiles, normalmente a los tiles adyacentes. En un entorno continuo viene dado por un punto con coordenadas x e y normalmente en coma flotante y puede moverse en cualquier dirección.

El enfoque anterior es válido tanto para un método como para otro, pues en vez de coordenadas x e y usaremos filas y columnas. Veamos un ejemplo.

if depredador_col > presa_col:
    depredador_col -= 1
elif: depredador_col < presa_col:
    depredador_col += 1

if depredador_fil > presa_fil:
    depredador_col -= 1
elif: depredador_fil < presa_fil:
    depredador_fil += 1

Podemos ver como solo necesitamos cambiar las referencias a las coordenadas del punto por las filas y columnas y el algoritmo es perfectamente válido.

En la imagen podemos ver como sería la persecución en un mapa basado en tiles.

Cuidado con los movimientos diagonales en juegos basados en tiles, pongamos que tenemos tiles de 32×32 píxeles, el movimiento de un tile a otro en horizontal o vertical sería de exactamente 32 píxeles, pero el movimiento en diagonal seria: sqrt(25²+25²) Es decir, la raiz cuadrada de los lados al cuadrado, que es la diagonal de un tile que nos daría aproximadamente 35.35 por tanto el movimiento en diagonal debería penalizarse más.

En la segunda parte veremos métodos más avanzados, de momento esto nos sirve como introducción al tema.

• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia
• IA en videojuegos – Persiguiendo y evadiendo II
• Introducción a la IA en los juegos
• ORTS. Estrategia en tiempo real OpenSource

En el artículo anterior vimos una introducción a la diferentes técnicas de inteligencia artificial aplicadas a los videojuegos y en sucesivos artículos intentaremos tratar cada uno de estos temas más a fondo, pero he encontrado un pdf bastante completo que explica las bases de todas estas técnicas y que puede servir como complemente al artículo de introducción anterior.

En el explica los algoritmos de IA más comunes separándolos en básicos y avanzado, anteriormente nosotros a estos dos grupos los llamamos IA Débil e IA Fuerte, se trata de los mismos conceptos. Dejo el pdf para descargar. No puedo poner la fuente, porque no la tengo.

• Descargar Técnicas de ia en los videojuegos

• IA en videojuegos – Persiguiendo y evadiendo II
• IA en videojuegos – Persiguiendo y evadiendo I
• Introducción a la IA en los juegos
• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia

En el sentido más amplio la mayoría de los juegos incorporan algún tipo de inteligencia artificial (IA). Los desarrolladores han usado durante años la IA para dar vida a personajes aparentemente inteligentes en innumerables juegos. Desde los los fantasmas del clásico Pacman, los bots del juego en primera persona Unreal y muchos más de diferentes estilos. La gran variedad de géneros y personajes distintos requiere una interpretación bastante amplia de lo que se considera IA en un juego. De hecho, es uno de los debates de la IA, que se considera realmente inteligencia artificial.

Algunos desarrolladores consideran tareas como la búsqueda de caminos como parte de la IA del juego. Steven Woodcock dijo en en la “Game Developer’s Conference” de 2003 que algunos desarrolladores aún consideran la detección de colisiones como parte de la IA. Claramente existen muchas interpretaciones de lo que se considera IA.

Nosotros vamos a tener una interpretación amplia de la IA y vamos a incluirlo todo como parte de la misma, desde la simple persecución y evasión para patrones de movimientos hasta las redes neuronales y algorítmos genéticos. La IA de videojuegos probablemente se adapte de mejor a la IA débil (ver más abajo). Sin embargo, se puede pensar en en la IA de juegos en términos aún más amplios.

En los juegos no siempre estamos interesados en dar a los personajes no jugadores inteligencia de nivel humano. Tal vez estamos escribiendo código para controlar las criaturas no humanas, tales como dragones, robots, o incluso roedores. Además, ¿Quién dice que siempre tenemos que hacer a los jugadores no-humanos inteligentes? Hacer algunos personajes no inteligentes puede agregar al juego variedad y riqueza. Aunque es cierto que a menudo la IA de los juegos esta llamada a resolver problemas bastante complejos, podemos emplear la IA para cosas mas simples como tener personajes con diferentes personalidades o que actúen según nuestras acciones.

Definición de IA

La pregunta ¿Qué es la inteligencia artificial? No es fácil de responder. Si usted busca inteligencia artificial en un diccionario probablemente encuentre algo parecido a lo siguiente: “La capacidad de un ordenador u otra máquina para llevar a cabo tareas que normalmente se considera que requieren inteligencia”. Esta definición proviene de The American Heritage Dictionary del Idioma Inglés, Cuarta Edición (Houghton Mifflin Company). Sin embargo otras fuentes definen la inteligencia artificial como el proceso o la ciencia de la creación de máquinas inteligentes.

Desde otra perspectiva, es apropiado pensar en la IA como el comportamiento inteligente exhibido por el equipo que ha sido creado, o tal vez los cerebros artificiales detrás de ese comportamiento inteligente. Pero incluso esta interpretación no es completa. Para algunas personas, el estudio de la IA no es necesariamente para el propósito de crear máquinas inteligentes, sino con el propósito de obtener un mejor conocimiento de la naturaleza de la inteligencia humana. Y otros métodos de estudio de inteligencia artificial para crear máquinas que presentan una forma limitada de la inteligencia.

Esto plantea la pregunta: “¿qué es la inteligencia?” Para algunos, la prueba de fuego para la IA es lo cerca que está a la inteligencia humana. Otros sostienen que los requisitos adicionales deben cumplirse para que una máquina para ser considerado inteligente. Algunas personas dicen que la inteligencia requiere una conciencia y de que las emociones se encuentran estrechamente ligados a la inteligencia, mientras que otros dicen que la capacidad de resolver un problema que requiere de inteligencia si llegara a resolverse por un ser humano no es suficiente, también debe aprender y adaptarse para ser considerado inteligente.

LA IA que cumple todos estos requisitos se considera IA Fuerte. A diferencia de la IA Fuerte, existe la IA a débil que incluye una gama más amplia de propósitos y tecnologías. Los juegos entran en la categoría de la IA débil.

La conclusión es que la definición de IA es bastante amplia y flexible. Todo lo que da la ilusión de inteligencia a un nivel adecuado hace los juegos mas inmersivos, desafiantes y, lo más importante, más divertidos.

IA determinista vs no determinista

La IA de los juegos se puede considerar de dos tipos, determinista y no determinista.

Determinista

El comportamiento es especificado y predecible, no hay ninguna incertidumbre. Un ejemplo de IA determinista es un algoritmo de persecución simple. Usted puede explícitamente designar un personaje no jugador para moverse hacia algún punto objetivo. El algoritmo consistirá en moverse por los ejes x e y hasta alcanzar el punto objetivo.

No determinista

Es lo contrario al determinismo. El comportamiento tiene un grado de incertidumbre y es algo imprevisible (el grado de incertidumbre depende de el método de IA empleado y lo bien aplicado que esté). Un ejemplo de comportamiento no determinismo es un personaje no jugador que aprende a adaptarse a las tácticas bélicas de un jugador. Tal estudio podría ser una red neuronal o un algoritmo genético.

Las técnicas deterministas son el pan y la mantequilla de la IA de videojuegos. Estas técnicas son predecibles, rápidas y fáciles de implementar, entender, probar y depurar. A pesar de que tienen mucho a su favor. Las conductas deterministas hacen que todo tenga que programarse de manera explícita por los desarrolladores. Además, los métodos deterministas no facilitan el aprendizaje o la evolución y después de un rato de juego los comportamientos deterministas tienden a volverse predecibles.

En los métodos no deterministas se facilita el aprendizaje y el juego se vuelve más impredecible. Además los desarrolladores no tienen en el código explícitamente todas las conductas posibles en todos los escenarios posibles. Los métodos no deterministas pueden explorar y aprender por su cuenta, y pueden promover un comportamiento emergente o que no siga instrucciones explícitas. Las redes neuronales son buenos ejemplos de esto.

Los desarrolladores tradicionalmente han usado poco la IA no determinista, aunque esto está cambiando poco a poco. La imprevisibilidad es difícil de probar y depurar, ¿Cómo se puede probar todas las posibles variaciones de la acción del jugador para asegurarse de que el juego no hace cosas estúpidas en algunos casos?

Al menos hasta hace poco, otro factor que ha limitado el desarrollo de juegos de IA es el hecho de que los desarrolladores se han centrado la mayor parte de su atención en la calidad de los gráficos. Como resultado, el enfoque como en el desarrollo de mejores y más rápidas técnicas gráficas, incluyendo la aceleración de hardware, ahora puede permitirse más recursos que deben asignarse hacia el desarrollo de mejores y más sofisticada IA. Este hecho, junto con la presión para producir el exitoso juego que viene, está animando a los desarrolladores de juegos para explorar más a fondo las técnicas no deterministas.

Estableciendo técnicas de ia en juegos

Tal vez la técnica más utilizada sea hacer trampa. Por ejemplo, en un juego de simulación de guerra, el ordenador puede tener acceso a toda la información sobre sus oponentes humanos de ubicación de su base, el tipo, número y ubicación de las unidades, etc, sin tener que enviar exploradores para reunir información de inteligencia como debe hacer el jugador humano. Hacer trampa de esta manera es común y ayuda a dar al ordenador una ventaja frente a los jugadores humanos inteligentes. Sin embargo, el engaño puede ser malo. Si es obvio para el jugador que el equipo está haciendo trampa, el jugador es probable que asuma sus esfuerzos son inútiles y perder interés en el juego. Además, el engaño no balanceado puede dar a la computadora demasiado poder, lo que hace imposible que el jugador pueda vencer a la computadora. Una vez más, el jugador puede perder interés si ve que sus esfuerzos son inútiles. Hacer trampa debe ser equilibrado para crear un suficiente de un desafío para el jugador para mantener el juego interesante y divertido.

Por supuesto, el engaño no es la única técnica de IA bien establecida. máquinas de estados finitos son una técnica de IA muy usada en todas partes. En otros artículos las veremos en detalle, pero básicamente la idea es enumerar un montón de acciones o estados de personajes controlados por computadora y ejecutarlos o de transición entre ellos utilizando condicionales que comprueban varias condiciones y criterios.

Otras técnicas usadas habitualmente es la lógica difusa, una máquina de lógica difusa mejora la maquina de estado finito y hace el juego menos predecible. Por ejemplo, podemos tener la condición de que si distancia=10 y vida=100 entonces atacar, pero esto es muy predecible. Mejor hacer algo como si distancia=cerca y vida > 75% entonces atacar. Esto hace que el juego sea menos predecible ya que cerca puede variar según el enemigo y su capacidad de ataque y la vida puede ser diferente de uno a otro. En otro artículo lo veremos más a fondo.

Por último no podemos olvidarnos te algo elemental en casi todo los juegos como es la búsqueda de caminos por parte de los no-jugadores, caminos que sean rápidos y eficientes. Hemos visto variso artículos de pathfinding.

Este artículo es una introducción a la programación de inteligencia artificial para videojuegos, en artículos posteriores empezaremos a explicar algunas de las técnicas aquí nombradas y otra muchas.

• IA en videojuegos – Persiguiendo y evadiendo I
• Modelado del Daimyo artificial. Optimizando la extracción de recursos en juegos RTS
• Sun Tzu 2.0 – El Arte de la guerra en los juegos de Estrategia
• IA en videojuegos – Persiguiendo y evadiendo II
• Técnicas de IA en los videojuegos

Donde a, b y c son números. Si a vale 0 nos quedaría.

Que ya no sería una parábola sino una recta como vimos en el artículo anterior. La gráfica de la parábola es la siguiente.

Esta sería la parábola más básica, la del tipo:

Para dibujar su gráfica podríamos usar el método de ir dándole valores a la x y obtener sus respectivas y, pero necesitaríamos muchos puntos para poder dibujar bien, lo mejor es buscar los puntos claves. Los puntos de corte con los ejes y el vértice.

Veamos un ejemplo, representar la siguiente parábola:

Para saber en que punto corta al eje y debemos darle a la x el valor 0, así sabremos cuanto vale la y en el eje.

Bien ya tenemos un punto de nuestra parábola.

Ahora calculemos los puntos de corte con el eje x, esto lo hacemos dando a la y el valor 0. Nos daría la siguiente ecuación.

Que es una ecuación de segundo grado que se resuelve con la siguiente fórmula.

Sustituimos valores y obtenemos dos puntos (recuerda que una raiz devuelve dos valores uno con signo más y otro con signo menos).

Por último calculamos el vértice de la parábola que viene dado por la siguiente fórmula.

Este es el valor de la x del vértice, para hallar su y simplemente sustituimos el valor en la función.

Resolvemos y tenemos que el vértice es el punto.

Ahora solo nos queda marcar los puntos en el eje de coordenadas y obtener la gráfica.

En los videojuegos

Como dijimos al principio, los videojuegos de plataforma 2D utilizan la parábola para realizar saltos. La siguiente parábola.

Tiene la siguiente gráfica.

Por lo que es fácil ver como simula los saltos de los videojuegos de plataforma 2D, perfectamente. En realidad es una parábola, pero esta se calcula con cinemática, concretamente con el tiro parabólico, que algún día veremos en un artículo de física.

• Geometría espacial. Vectores II
• Geometría espacial. Vectores
• Función matemática
• El eje cartesiano y el punto
• Hablemos de física y matemáticas

Se lee: “y es igual a f de x” ó “y es función de x”, asimismo la “x” se llama variable independiente y la “y” variable dependiente. Esto es así porque a la x podremos darle el valor que queramos, pero la y dependerá de este valor que le demos a esta x. Es por eso que en una función a cada valor de de x le corresponde un único valor de y. Y solamente uno, es decir, en toda función solo existen un par de valores.

Funciones polinómicas

Son las más básicas y representan una recta. son del tipo:

Por ejemplo, si te encuentras con la siguiente funciones:

Tienes que saber de ante mano que representan una recta, podemos comprobarlo, creando una table de valores. Elegimos un par de valores de x y calculamos los valores de y.

Una recta tiene infinitos puntos, pero con solo calcular dos podemos dibujarla

Puedes usar los valores que quieras para calcular dos puntos de la recta, pero se práctico y usa valores sencillos como 0, 1, -1, 2. Según el caso es conveniente usar unos números u otros.

Por ejemplo representemos la siguiente recta:

Tomaremos los valores 0 y 1 para la x y calcular sus respectivas y.

Por lo que obtenemos dos puntos que pasan por nuestra recta:

Uniéndolos ya tenemos la recta:

La tabla de valores está bastante bien para casos simples, pero cuando se trata con funciones más complejas calcular los valores de y no es tan sencillo y no todas las funciones se pueden dibujar con dos puntos.

Si nos fijamos en la ecuación veremos que cuando la x vale 0, es decir, cuando corta al eje y. nos queda

Cualquier número multiplicado por 0 es 0. Así que nos queda.

Por lo que a b se le conoce como ordenada del origen y es donde corta la recta al eje y. Cuando b vale 0, por ejemplo:

Significa que la recta pasa por el centro del eje de coordenadas (0, 0).

La a es conocida como la pendiente de la recta y coincide con la tangente del ángulo que forma con el eje x, pero ya lo veremos cuando veamos trigonometría.

Bueno ya hemos introducido el concepto de función y hemos visto las funciones polinómicas y de primer grado, en el siguiente artículo introduciremos la funciones de segundo grado o parabólicas.

• Geometría espacial. Vectores II
• El eje cartesiano y el punto
• Geometría espacial. Vectores
• Funciones de segundo Grado
• Hablemos de física y matemáticas

Es imposible partir desde 0, pues se han de presuponer unos conocimientos básicos. No estamos aquí para enseñar a sumar o a dividir. Como tenía que tener un punto de corte por el que empezar a explicar el tema, lo que voy a presuponer por parte del lector es un nivel de matemáticas de nivel ESO, quizás un poco menos.

Asumiré que se sabe trabajar con ecuaciones tanto de primer como de segundo grado, que se saben representar, algo de geometría básica y operaciones elementales como el desarrollo de cuadrados, simplificaciones, factorización, etc. No voy a asumir ningún conocimiento trigonométrico aunque entra en el temario de la ESO ya que la trigonometría es bastente importante en el desarrollo de videojuegos.

Si no dominas los temas que se asumen es mejor que primero aprendas algo de  matemáticas básicas antes de meterte en el mundo de la programación o tienes el futuro en esto bastante oscuro.

El plano real

El mundo real puede ser complicado y encontrar un sitio exacto del espacio puede ser algo no trivial. Para hacerlo más fácil en matemáticas se simplifica usando un sistema de coordenadas. Hay varios sistemas, pero el mas utilizado es el sistema de coordenadas cartesianas.

Este consiste en dos ejes que se cortan y el punto de corte entre estos dos ejes es el origen.

El punto

Como vemos introducimos el concepto de punto. Un punto matemático es una coordenada única del espacio que viene dada por dos valores (x, y) donde x es las unidades de separación que hay con respecto al centro en dirección derecha o izquierda e y es la distancia de separación arriba o abajo.

Se puede ver claramente en el gráfico superior la representación de varios puntos matemáticos. Creo que el concepto queda claro.

Para simplificar estamos usando un plano 2D en el que nos movemos en dos ejes. El mundo real tiene 3 dimensiones y habría un tercer eje (z). Inclusos se puede hablar de una cuarta dimensión, el tiempo.

Operaciones con puntos

Sobre los puntos se pueden aplicar operaciones elementales como sumarlos, restarlos o multiplicarlos. La suma y la resta no tienen ninguna complicación es simplemente sumar la coordenada x con la x y la coordenada y con la y.

La multiplicación y la división igual cada coordenada por la suya.

También se puede multiplicar un punto por un escalar, en cuyo caso ambas coordenadas se multiplican por el número.

Esto ha sido una pequeña introducción y espero que los conceptos expuestos aquí se manejen de ante mano con soltura pues en el próximo artículo entraremos verdaderamente en materia introduciendo el concepto de función matemática.

• Geometría espacial. Vectores II
• Función matemática
• Geometría espacial. Vectores
• Funciones de segundo Grado
• Hablemos de física y matemáticas

Este blog como habréis notado se centra en publicar artículos, principalmente, sobre inteligencia artificial y videojuegos. Son dos temas que requieren de una cierta habilidad matemática y física para trabajar con ellos y como en todo cada vez que queremos hacer cosas más complejas estas matemáticas y esta física se complicada.

Por eso me ha surgido la idea de tratar en el blog temas de matemáticas y física que tengan relación con la programación de inteligencia artificial y videojuegos. Muchos llegarán al blog buscando como crear videojuegos o hacer IA. Pensando que la parte más difícil puede ser la programación. Cuando en realidad lo complicado de un desarrollo se encuentra en las matemáticas. Programar es para mí el arte de expresar con reglas matemáticas la realidad.

Es por eso que, aunque se que tengo ya varios frentes abiertos en el blog, voy a empezar a publicar sobre matemáticas y física orientada a videojuegos. Muchos pensaréis, vaya rollo, pero el que quiera de verdad aprender sobre estos temas, que sepa que sin las matemáticas no va a hacer nada nunca.

Si alguien está interesado en ayudarme con este tipo de artículos que me lo comente, así podremos enriquecer el blog.

• Geometría espacial. Vectores II
• Geometría espacial. Vectores
• Funciones de segundo Grado
• Función matemática
• El eje cartesiano y el punto

Primero necesitamos saber como vamos a codificar los genes en el cromosoma. Para esto tenemos que saber cuales son las posibilidades, que en este caso son ir al norte, al sur, al este o al oeste. La manera más sencilla de codificarlos es en formato binario, es decir,  con unos y ceros, dado que luego tiene varias ventajas añadidas, como por ejemplo que a la hora de mutar solo hay que cambiarlo de 0 a 1 o de 1 a 0, no hay que tratar con mas posibilidades que complicarían más la cosa. Una vez considerado esto, dado que las posibilidades son 4, cada gen del cromosoma será una pareja de estos números, así las combinaciones serán exactamente 4: 00 –> norte, 01 –> sur, 10 –>  este, 11 –> oeste. En otras ocasiones no tendremos tanta suerte, y nos acabarán sobrando posibilidades, por lo tanto habrá que realizar el tratamiento de errores que corresponda. Es importante que tengáis claro como lo habéis codificado dado que lo necesitareis recordar durante todo el desarrollo. Una cosa a tener en cuenta es que no hay ningún obstáculo en todo el recorrido

La estructura del código es sencilla. Una clase Cromosoma que contendrá los atributos “cromosoma”, una cadena, y  “aptitud”, un número en coma flotante, y con prácticamente todas las funciones que necesitaremos. El resto serán un par de funciones sueltas que no encajan el la clase y el programa en si. Como módulos externos solo usaremos “random” para los números aleatorios que necesitaremos.

Poco más queda por decir antes de empezar con el código, quizás aclarar que sera en modo consola, pero pondré al día mis conocimientos de pygame para próximos tutoriales, que si no hay cosas que se pueden hacer muy pesadas. Así que nos vemos en el siguiente artículo.

• IA en videojuegos – Persiguiendo y evadiendo I
• Algoritmos genéticos

Primero necesitamos una imagen que haga de bola, yo dejo la que uso a continuación, pero si no os gusta os hacéis una.

• Descargar ball.png

La clase Ball()

Antes que nada y como siempre creamos el archivo sp_ball.py y en el metemos los siguientes import que nos harán falta.

# -*- encoding: utf-8 -*-

import pygame
import config
import graphics
import math

El constructor

A continuación, pasamos a crear la clase y su constructor.

class Ball(pygame.sprite.Sprite):
    def __init__(self):
        pygame.sprite.Sprite.__init__(self)
        self.image = graphics.load_image(config.sprites+"ball.png", True)
        self.rect = self.image.get_rect()
        self.rect.centery = config.height/2
        self.rect.centerx = (config.width-140)/2
        self.speed = [0.4, 0.4]

Muy parecido a la pala las diferencias, obviamente la imagen será la de la pelota y esta vez self.rect.centery vale config.height/2 o lo que es lo mismo que está justo en medio de la ventana.

como nuevo tenemos que self.speed es ahora una lista de dos valores, esto es así porque la bola al contrario que la pala se mueve tanto en el eje x como en el eje y.

El método update

En este método trabajaremos durante el juego bastante, pues será el encargado de detectar las colisiones de la bola con todos los elementos y actuar en consecuencia. De momento vamos a programarlo para que rebote contra las paredes y contra la pala que son los elementos que tenemos.

Dejo el método entero y lo explicamos paso a paso.

def update(self, time, pallet):
    self.rect.centerx += self.speed[0] * time
    self.rect.centery += self.speed[1] * time

    # Colisiones con las paredes.
    if self.rect.left <= 10:
        self.rect.left = 10
        self.speed[0] = -self.speed[0]
    if self.rect.right >= 490:
        self.rect.right = 490
        self.speed[0] = -self.speed[0]
    if self.rect.top <= 10:
        self.rect.top = 10
        self.speed[1] = -self.speed[1]
    if self.rect.bottom >= 470:
        self.rect.bottom = 470
        self.speed[1] = -self.speed[1]

    # Colisiones con la pala.
    if pygame.sprite.collide_rect(self, pallet):
        if self.rect.centerx <= pallet.rect.centerx:
            dist = pallet.rect.centerx - self.rect.centerx
            self.speed[0] = -math.sin(math.radians(dist))/1.25
        elif self.rect.centerx > pallet.rect.centerx:
            dist = self.rect.centerx - pallet.rect.centerx
            self.speed[0] = math.sin(math.radians(dist))/1.25
        self.speed[1] = -self.speed[1]

Como diría Jack el Destripador, vamos por partes. Lo primero es calcular la posición de la pelota con respecto a la velocidad y el tiempo como hacíamos con la pala solo que esta vez en dos ejes son las líneas 2 y línea 3 respectivamente.

Colisiones con las paredes

Solo con lo de arriba ya tendría movimiento nuestra pelota, pero ahora hay que hacer que rebote contra los bordes y contra la pala. Esto lo conseguimos jugando con los valores de la velocidad. Por ejemplo, si la pelota se mueve a la velocidad de 0.4 en el eje y significa que va hacia abajo ya que pongamos que la pelota tienen su posición y en el pixel 300 si transcurridos 20 milésimas de segundo calculamos cuando se ha movido sería 0.4*20 que daría 8 por lo que estaría en el pixel 308, por tanto se estaría moviendo hacia abajo (recuerda que la coordenada (0, 0) está en la esquina superior izquierda). Entonces cambiar el sentido de la velocidad bastaría con ponerle un signo menos delante, entonces tendríamos -8 y la posición sería 300-8=292 por lo que habría subido.

Esta explicación que parece obvia y es una cosa básica es buena tenerla en cuenta para los que anden despistados. Jugando con esto vamos a programar los rebotes contra la pared.

# Colisiones con las paredes.
    if self.rect.left <= 10:
        self.rect.left = 10
        self.speed[0] = -self.speed[0]
    if self.rect.right >= 490:
        self.rect.right = 490
        self.speed[0] = -self.speed[0]
    if self.rect.top <= 10:
        self.rect.top = 10
        self.speed[1] = -self.speed[1]
    if self.rect.bottom >= 470:
        self.rect.bottom = 470
        self.speed[1] = -self.speed[1]

Primero comprobamos si ha chocado con la parte izquieda, para ello comprobamos si la parte izquieda de la pelota (self.rect.left) es menor que 10 que es donde se encuentra el borde izquierdo. En caso de que así sea primero establecemos la parte izquieda de la pelota justo en 10. Esto lo hacemos por si llegara a vale 9 u 8 no se vea encima de la pered, recuerda que no dibujamos hasta el final. a continuación cambiamos la dirección de la velocidad del eje x.

Exactamente lo mismo se aplica a la parte derecha, la parte superior y la inferior. Solo que para la superior e inferior lo que variamos es la velocidad en el eje y. Como vemos la velocidad al chocar contra las paredes permanece constante y solo cambia la dirección de la misma.

Colisiones con la pala

Para la pala no nos vamos a limitar a cambiar simplemente la dirección de la bola, sino que vamos a darle más juego y según con la parte que golpeemos consigamos un efecto u otro. Lo que he hecho es que entre más con el extremo de la pala golpees más inclinada salga la pelota hacia el lado con el que le das y si le das con el centro justo de la raqueta salga vertical hacia arriba. Así el jugador tendrá control para decidir a que parte de la pantalla mandar la pelota.

La pala mide de ancho 60px, por lo que del centro a los extremos hay 30px exactos. Lo que vamos a hacer es calcular la diferencia que hay entre el centro de la pelota y el centro de la pala a la hora de golpear. La distancia podra ir desde 0 (cuando le da en el centro justo) hasta 30 (cuando le da con el extremo de la pala). Para obtener la velocidad nos basta con obtener el seno de la distancia resultante ya que el seno de 30 es 0.5 y el seno de 0 es 0 nos da que si le damos con el extemo de la pala saldria a una velocidad de 0.5 en el eje x y si le damos con el centro la velocidad en el eje x sería 0 por lo que saldría hacia arriba sin cambiar de dirección (recuerda que estamos variando el eje x, el eje parmanece intacto). 0.5 por las pruebas que he hecho es algo rápido para jugar bien por lo que es mejor que la velocidad máxima sea 0.4, esto lo conseguimos dicidiendo entre 1.25.

Así explicado puede que maree un poco, veamos el código.

# Colisiones con la pala.
    if pygame.sprite.collide_rect(self, pallet):
        if self.rect.centerx <= pallet.rect.centerx:
            dist = pallet.rect.centerx - self.rect.centerx
            self.speed[0] = -math.sin(math.radians(dist))/1.25
        elif self.rect.centerx > pallet.rect.centerx:
            dist = self.rect.centerx - pallet.rect.centerx
            self.speed[0] = math.sin(math.radians(dist))/1.25
        self.speed[1] = -self.speed[1]

Lo primero de todo es detectar si la pelota está colisionando con la pala. Para ello usamos las funciones que nos provee pygame.

if pygame.sprite.collide_rect(self, pallet):

Recibe dos sprites y devuelve verdadero si están colisionando en nuestro caso le pasamos la bola misma (self) y la pala (pallet) fijaos que la pala se la pasamos como parámetro el metodo update junto con time. Lamentablemente esta función solo comprueban si están colisionando y no en que punto esta colisionando, por lo que tendremos que hacerlo a mano.

Primero detectamos si está colisionando a la izquierda o a la derecha de la pala. Esto es importante para saber en que dirección mandamos la pelota, si la golpeamos con la parte izquierda de la pala la mandaremos hacia la izquierda y si la golpeamos con la derecha la mandaremos a la derecha. Comprobarlo es tan fácil como:

if self.rect.centerx <= pallet.rect.centerx:

Es decir, si el centro de la bola es menor o igual (el igual puede ir tanto a la derecha como a la izquieda ya que la velocidad en x valdrá 0 y da igual si es positiva o negativa) que el centro de la pala. En cuyo caso calculamos la distancia que separa el centro de la pala con el centro de la bola (nos dará un valor entre 0 y 30)

dist = pallet.rect.centerx - self.rect.centerx

Por último le damos el nuevo valor a la velocidad en el eje y que explicamos arriba.

self.speed[0] = -math.sin(math.radians(dist))/1.25

dist tiene un valor entre 0 y 30. La función seno de la biblioteca math recibe los parámetros en radianes así que convertimos dist a radianes con math.radians(dist). Luego atención a la división entre 1.25 que limita la velocidad un 25 por ciento para que no vaya tan rápido. También atención al signo – (menos) que hace que la dirección sea hacia la izquierda.

Para la derecha es exactamente lo mismo, pero sin el signo menos, haciendo que la pelota vaya hacia la derecha.

Por último y como final, también después de colisionar debemos cambiar la velocidad del eje y para que vaya en sentido contrario, lo hacemos con:

self.speed[1] = -self.speed[1]

El método draw

Como en todos los sprites no nos olvidemos de un método para dibujarlo, en este caso es idéntico al de la clase de la pala.

def draw(self, screen):
        screen.blit(self.image, self.rect)

Dejo el archivo entero, para el que se haya perdido.

# -*- encoding: utf-8 -*-

import pygame
import config
import graphics
import math

class Ball(pygame.sprite.Sprite):
    def __init__(self):
        pygame.sprite.Sprite.__init__(self)
        self.image = graphics.load_image(config.sprites+"ball.png", True)
        self.rect = self.image.get_rect()
        self.rect.centery = config.height/2
        self.rect.centerx = (config.width-140)/2
        self.speed = [0.4, 0.4]

    def update(self, time, pallet):
        self.rect.centerx += self.speed[0] * time
        self.rect.centery += self.speed[1] * time

        # Colisiones con las paredes.
        if self.rect.left <= 10:
            self.rect.left = 10
            self.speed[0] = -self.speed[0]
        if self.rect.right >= 490:
            self.rect.right = 490
            self.speed[0] = -self.speed[0]
        if self.rect.top <= 10:
            self.rect.top = 10
            self.speed[1] = -self.speed[1]
        if self.rect.bottom >= 470:
            self.rect.bottom = 470
            self.speed[1] = -self.speed[1]

        # Colisiones con la pala.
        if pygame.sprite.collide_rect(self, pallet):
            if self.rect.centerx <= pallet.rect.centerx:
                dist = pallet.rect.centerx - self.rect.centerx
                self.speed[0] = -math.sin(math.radians(dist))/1.25
            elif self.rect.centerx > pallet.rect.centerx:
                dist = self.rect.centerx - pallet.rect.centerx
                self.speed[0] = math.sin(math.radians(dist))/1.25
            self.speed[1] = -self.speed[1]

    def draw(self, screen):
        screen.blit(self.image, self.rect)

Poniendo una bola en nuestro juego

Una vez creada, vamos a darle vida. Lo primero es crear una instancia en el constructor de SceneGame, como siempre.

self.ball = Ball()

A continuación solo debemos añadir el método update de la bola al método on_update de la escena, ya que al contrario que la pala, la bola no precisa de ningún evento para moverse.

self.ball.update(self.time, self.pallet)

Y por último en el método on_draw le decimos que se dibuje.

self.ball.draw(screen)

Con esto ya tenemos una pelota que rebota contra las paredes y la pala y con esta podemos dirigir hacia donde queremos mandarla. Dejo scene_game.py completo por si no lo véis.

# -*- encoding: utf-8 -*-

import pygame
import scene
import config
import graphics
import load_levels

from sp_pallet import Pallet
from sp_ball import Ball

class SceneGame(scene.Scene):
    """Escena inicial del juego, esta es la primera que se carga cuando inicia"""

    def __init__(self, director):
        scene.Scene.__init__(self, director)
        self.back = graphics.load_image(config.menus+"back_game.png")
        self.pallet = Pallet()
        self.ball = Ball()

    def on_update(self):
         self.time = self.director.time
         self.ball.update(self.time, self.pallet)

    def on_event(self):
        keys = pygame.key.get_pressed()
        if keys[pygame.K_LEFT]:
            self.pallet.update(1, self.time)
        if keys[pygame.K_RIGHT]:
            self.pallet.update(2, self.time)

    def on_draw(self, screen):
        screen.blit(self.back, (0,0))
        self.pallet.draw(screen)
        self.ball.draw(screen)

• Arkanoid IV – Creando la pala
• Arkanoid III – Diseñando la pantalla de juego
• Arkanoid II – Gestionando escenas
• Arkanoid I – Empezando y configurando
• Juego de la serpiente paso a paso. Parte 2

El sprite pala

La pala del juego Arkanoid es el sprite que maneja el usuario, se encuentra en la parte inferior de la pantalla y el jugador debe moverla de izquierda a derecha para evitar que la bola caiga. En un principio vamos a hacer que la pala se mueva con el teclado, pero cuando empecemos añadirle extras daremos la opción de manejarla con el ratón.

Bien lo que vamos a hacer es crear un sprite parecido a los que creamos para el pong. Así que creamos un nuevo script de Python llamado sp_pallet.py he decidido poner el prefijo sp_ a los scripts de sprites para diferenciarlos.

Como casi todo sobre la creación de sprites se vio en el tutorial del Pong, pongo aquí el sprite entero que es pequeño y lo comentamos.

# -*- encoding: utf-8 -*-

import pygame
import config
import graphics

class Pallet(pygame.sprite.Sprite):
    def __init__(self):
        pygame.sprite.Sprite.__init__(self)
        self.image = graphics.load_image(config.sprites+"pala.png", True)
        self.rect = self.image.get_rect()
        self.rect.top = 420
        self.rect.centerx = (config.width-140)/2
        self.speed = 0.5

    def update(self, dir, time):
        if dir == 1:
            if self.rect.left >= 15:
                self.rect.x -= self.speed*time
        elif dir == 2:
            if self.rect.right <= 485:
                self.rect.x += self.speed*time

    def draw(self, screen):
        screen.blit(self.image, self.rect)

Lo primero que vemos es la importación de los módulos necesarios, como casi siempre la biblioteca pygame, el archivo config y las funciones de graphics. Luego tenemos la clase Pallet, que hereda de la clase Sprite como ya explicamos en el tutorial de Pong. Cargamos, la imagen de la pala y el rect.

Por cierto, en el artículo anterior puse una pala con el fondo transparente, a veces suelen dar porblemas porque la función de cargar imágenes tiene definido que tome como color transparente el pixel (0,0) de la imagen y al ser este ya transparente pues Pygame a veces se lía. Por eso yo siempre prefiero ponerles un color que haga de colorkey así que resubo la pala con el nuevo fondo.

• Descargar pala1.png

Recuerda renombrarla a pala.png antes de ponerla en la carpeta o dará error al cargar.

Bien siguiendo con el código obtenemos el rect, si no sabes lo que es por enésima vez te remito al tutorial del Pong. A continuación con self.rect.top modificamos a que altura de la ventana del juego esté la parte superior de nuestra pala. En nuestro caso en la posición 420 que es casi pegada a la parte inferior, pero dejando un espacio.

con self.rect.centerx más o menos lo mismo, pero la situamos en el centro del área de juego, para calcularla cogemos el ancho de la ventana (config.width que es 640) le restamos la parte del menú (que mide 140px) y lo dividimos entre 2 por lo que tendremos el centro de la pala del eje x (rect.centerx) en el centro del área de juego.

Por último con self.speed establecemos una velocidad de movimiento para la pala hemos elegido provisionalmente 0.5, pera ya veremos si es adecuada o no cuando el juego tenga todos sus elementos.

El método update

El método update como siempre se encarga de actualizar la posición de la pala. Recibe dos parámetros: dir que puede tener los valores 1 y 2. El valor 1 representa el movimiento a la izquierda y el valor 2 representa el movimiento a la derecha, según que valor le pasemos se moverá en una dirección u otra como vemos con el if dir == 1 y el elif dir == 2, nada complicado. Luego tenemos dos if más que limitan el movimiento, veamoslos.

if self.rect.left <= 15 nos dice que solo se ejecute las sentencias de su cuerpo si la parte izquierda del rect es mayor o igual que 15 esto es así porque si nos fijamos en el fondo que hemos puesto tiene un borde derecho de 10px más 5px que dejamos de margen. Lo mismo se aplica a self.rect.right <= 485 esto nos da el límite de la parte derecha del área del juego, sería un poco absurdo tener la pala sobre la barra lateral.

por ultimo usamos física básica para hacer el movimiento de la pala, todos sabemos que E = v*t o lo que es lo mismo espacio es igual a la velocidad por el tiempo. Pues bien cogemos la posición que tiene la pala (self.rect.x) y le añadimos el movimiento que viene dado por la ecuación, la verlocidad (self.speed) por el tiempo (time).

El parámetro time es el otro que teníamos y que no hemos explicado, viene del objeto director y el reloj que allí creamos y ahora veremos como se lo pasamos a la pala.

Por último tenemos el método draw que se encarga de dibujar el sprite, como vemos solo recibe el parámetro screen y hace un blit de la imagen tomando su rect como referencia, nada que ya no hayamos visto.

Poniendo la pala en la escena

Ya tenemos nuestra pala creada, es hora de colocarla en nuestro juego. Para ello vamos al archivo scene_game.py. Lo primero es crear la pala en el constroctor de la clase.

self.pallet = Pallet()

A continuación vamos a obtener el tiempo transcurrido desde la última actualización de pantalla, esto lo hacemos en el método on_update con la siguiente línea.

self.time = self.director.time

como vemos obtenemos el tiempo desde el objeto director y lo almacenamos en self.time para tener disponible en todo la escena, es importante que esté en on_update y no en el constructor porque es una variable que tiene que obtener su valor en cada paso del bucle para saber cuanto tiempo ha pasado.

Por último solo nos queda mover nuestra pala que lo haremos, en principio, con el teclado, con las flechas de dirección izquierda y derecha. Pulsar una tecla se considera un evento por lo que irá en el método on_event. En realidad da igual colocar las cosas en on_event o en on_update, pero mejor ser ordenados y cada cosa en su lugar.

Por lo que el método on_event nos quedaría así.

def on_event(self):
        keys = pygame.key.get_pressed()
        if keys[pygame.K_LEFT]:
            self.pallet.update(1, self.time)
        if keys[pygame.K_RIGHT]:
            self.pallet.update(2, self.time)

Obtenemos las teclas pulsadas y las almacenamos en keys. Luego comprobamos si está pulsada las flechas de dirección izquierda o derecha. Según la que esté pulsada llamamos al parametro update de pallet con el valor de dir en 1 o en 2. También le pasamos el valor del tiempo transcurrido.

Por último solo nos queda dibujar la pala en pantalla. Para ello añadimos la siguiente línea al metodo on_draw.

self.pallet.draw(screen)

Y listo, podemos ejecutar nuestro juego y ver nuestra pala en acción.

• Arkanoid V – Creando la bola
• Arkanoid III – Diseñando la pantalla de juego
• Arkanoid II – Gestionando escenas
• Arkanoid I – Empezando y configurando
• Juego de la serpiente paso a paso. Parte 2

La pantalla de juego

La pantalla más importante de nuestro juego va a ser la del juego en sí, otras como los menús, puntaciones y demás son pantallas del juego, pero no son tan importantes ya que el jugador se pasará la mayor parte del tiempo en la pantalla de juego. Es por eso que es la primera que vamos a diseñar.

En un principio vamos a diseñar algo básico que marque la ubicación y estructura de los elementos, más adelante se puede cambiar por gráficos más elaborados. Bueno abrimos nuestro programa de diseño gráfico ya sea GIMP, Photoshop o el que queráis.

Mi idea del juego es que tenga una resolución de 640x 480 con una barra lateral donde poner datos como la puntuación, el nivel, las vidas y más información útil.

Como vemos nada del otro mundo, pero que nos ayudará a tener claro a la hora de programar donde esta definida el área de juego, los puntos, los bloques, la pala, etcétera. Luego ya nos curraremos una estadísticas mejores y unos gráficos molones.

La estrategia que vamos a seguir es conseguir un juego funcional y luego poco a poco ir añadiendole extras. Me explico, en principio el objetivo es conseguir con la pala destruir todos los ladrillos, pero más adelante podremos hacer que ciertos ladrillos dejen caer ciertas bonificaciones al romperse o extras como hacer crecer y encoger la pala o darte más vidas.

Vamos a desglosar esta imagen que tenemos como referencia, para usarlas en nuestro juego. Cogemos es el fondo y lo guardamos en formato png en la carpeta de menús ya que todos los elementos de la interfaz irán a esta carpeta.

• Descargar back_game.png

Luego la pala, los ladrillos, la pelota y demás elementos interactivos irán a la carpeta sprites, pues son los que van a poseer propiedades físicas o de movimiento.

• Descargar brick_green.png
• Descargar pala.png

El archivo graphics.py

Antes de seguir vamos a crear un archivo auxiliar con algunas funciones útiles como load_image o text que ya vimos en el tutorial del Pong y sirven para cargar imágenes y texto. A este archivo lo llamaremos graphics.py y en el colocaremos funciones que se encarguen de manipular y crear gráficos.

# -*- coding: utf-8 -*-

"""Módulo para implementar el manejo de gráficos y superficies"""

# Módulos
import pygame

# Carga una imagen transparencia y color tranasparente opcionales.
def load_image(filename, transparent=False, pixel=(0,0)):
    "Carga una imagen al formato interno de pygame"
    try: image = pygame.image.load(filename)
    except pygame.error, message:
            raise SystemExit, message
    image = image.convert()
    if transparent:
            color = image.get_at(pixel)
            image.set_colorkey(color, pygame.RLEACCEL)
    return image

def text(texto, posx, posy, color=(0, 0, 0), tam=25):
    "Crea una imagen con texto pasado y su rect"
    fuente = pygame.font.Font("../images/DroidSans.ttf", tam)
    salida = pygame.font.Font.render(fuente, texto, 1, color)
    salida_rect = salida.get_rect()
    salida_rect.centerx = posx
    salida_rect.centery = posy
    return salida, salida_rect

Si no entiendes estas funciones revisa el tutorial del Pong básico.

Colocando el fondo

Ya podemos colocar el fondo de nuestro SceneGame ya que este no variará y será lo primero que se dibuje siempre.

Cargamos la imagen en el constructor de la escena.

self.back = graphics.load_image(config.menus+"back_game.png")

Previamente debemos hacer los imports tanto de config como de graphics para usar las funciones que contienen. Podéis ver como config.menus en realidad equivale a “data/graphics/menus/” por lo que si algún día decidimos cambiar la ruta solo con cambiar esta variable bastará.

Una vez carga solo debemos hacer que se dibuje en método on_draw de la escena con la siguiente línea.

screen.blit(self.back, (0,0))

Debe ser siempre la primera cosa a dibujar ya que es el fondo que va debajo y todo lo demás tiene que dibujarse encima si queremos que sea visible. Por si os habéis perdido dejo el archivo scene_home.py completo.

# -*- encoding: utf-8 -*-

import scene
import config
import graphics

class SceneGame(scene.Scene):
    """Escena inicial del juego, esta es la primera que se carga cuando inicia"""

    def __init__(self, director):
        scene.Scene.__init__(self, director)
        self.back = graphics.load_image(config.menus+"back_game.png")

    def on_update(self):
        pass

    def on_event(self):
        pass

    def on_draw(self, screen):
        screen.blit(self.back, (0,0))

Por favor dejad vuestra opinión sobre si está bien explicado o no, si debería dar mas detalles o cualquier sugerencia para futuras entregas.

• Arkanoid V – Creando la bola
• Arkanoid IV – Creando la pala
• Arkanoid II – Gestionando escenas
• Arkanoid I – Empezando y configurando
• Juego de la serpiente paso a paso. Parte 2

El archivo director.py

Es el archivo que contiene el objeto director que es en última estancia el que llevará el bucle de nuestro juego y que gestionará las diferentes escenas.

# -*- encoding: utf-8 -*-

# Módulos
import pygame
import config

class Director:
    """Representa el objeto principal del juego.

    El objeto Director mantiene en funcionamiento el juego, se
    encarga de actualizar, dibuja y propagar eventos.

    Tiene que utilizar este objeto en conjunto con objetos
    derivados de Scene."""

    def __init__(self):
        self.screen = pygame.display.set_mode((config.width, config.height))
        pygame.display.set_caption(config.name)
        self.scene = None
        self.quit_flag = False
        self.clock = pygame.time.Clock()

    def loop(self):
        "Pone en funcionamiento el juego."

        while not self.quit_flag:
            self.time = self.clock.tick(60)

            # Eventos de Salida
            for event in pygame.event.get():
                if event.type == pygame.QUIT:
                    self.quit()

            # detecta eventos
            self.scene.on_event()

            # actualiza la escena
            self.scene.on_update()

            # dibuja la pantalla
            self.scene.on_draw(self.screen)
            pygame.display.flip()

    def change_scene(self, scene):
        "Altera la escena actual."
        self.scene = scene

    def quit(self):
        self.quit_flag = True

A destacar ver como importamos el archivo config y lo usamos para cargar la resolución o el nombre del juego. Lo demás viene explicado en el artículo de la gestión de escenas.

El archivo scene.py

Representará una escena abstracta del juego y será heredada por las escenas de nuestro juego.

# -*- encoding: utf-8 -*-

class Scene:
    """Representa un escena abstracta del videojuego.

    Una escena es una parte visible del juego, como una pantalla
    de presentación o menú de opciones. Tiene que crear un objeto
    derivado de esta clase para crear una escena utilizable."""

    def __init__(self, director):
        self.director = director

    def on_update(self):
        "Actualización lógica que se llama automáticamente desde el director."
        raise NotImplemented("Tiene que implementar el método on_update.")

    def on_event(self, event):
        "Se llama cuando llega un evento especifico al bucle."
        raise NotImplemented("Tiene que implementar el método on_event.")

    def on_draw(self, screen):
        "Se llama cuando se quiere dibujar la pantalla."
        raise NotImplemented("Tiene que implementar el método on_draw.")

SceneGame

Aunque cuando nuestro juego esté acabado la escena inicial será SceneHome en un principio vamos a crear y a cargar SceneGame mientras desarrollamos el juego ya que el menú principal lo desarrollaremos más adelante. Esto solo afecta a la escena que cargaremos en primer lugar y luego cambiar a SceneHome será tan fácil como sustituirla en el archivo main.

La clase que representan a las escena he decidido llamarlas SceneName donde Name es el nombre de la escena y el archivo que las contiene se llamará scene_name donde otra vez name es el nombre de la escena.

Por tanto creamos un archivo llamado scene_game.py y dentro creamos nuestra escena SceneGame:

# -*- encoding: utf-8 -*-

import scene
import config

class SceneGame(scene.Scene):
    """Escena inicial del juego, esta es la primera que se carga cuando inicia"""

    def __init__(self, director):
        scene.Scene.__init__(self, director)

    def on_update(self):
        pass

    def on_event(self):
        pass

    def on_draw(self, screen):
        pass

Como vemos creamos la clase SceneGame como se explica en el tutorial, con el método init llamando al init de Scene y creando los tres métodos de actualizar, eventos y dibuhar de rigor. Que, de momento, estñan vacíos.

El archivo principal

Por último debemos crear el archivo main.py que será el encargado de ejecutar el juego. Por ahora main.py cargará SceneGame, pero cuando nuestro juego este listo pasará a cargar SceneHome.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

# Módulos
import pygame
import director
import scene_game

def main():
    dir = director.Director()
    scene = scene_game.SceneGame(dir)
    dir.change_scene(scene)
    dir.loop()

if __name__ == '__main__':
    pygame.init()
    main()

Con esto ya debemos poder ejecutar nuestro juego y tener una ventana en negro que en realidad es más que eso, pues está lista para ejecutar las ordenes dadas en SceneGame.

• Arkanoid V – Creando la bola
• Arkanoid IV – Creando la pala
• Arkanoid III – Diseñando la pantalla de juego
• Arkanoid I – Empezando y configurando
• Juego de la serpiente paso a paso. Parte 2

El juego, como viene siendo habitual en el blog será desarrollado sobre Python y Pygame ya que nos permite centrarnos en los conceptos del juego sin tener que pelearnos con el lenguaje de programación.

Requisitos previos

• Nivel aceptable de Python y control de la programación orientada a objetos.
• Manejarse con los conceptos básicos de Pygame. Si no tienes esta base, primero haz el tutorial del Pong.
• Controlar los conceptos básicos de la programación de juegos 2D. Parte 1, Parte 2 y Parte 3.
• Leer el tutorial de la gestión de escenas con pygame, pues lo usaremos.

Bueno esta vez no es un simple Pong, sino que queremos hacer algo más elaborado y completo. Crear un juego que conste de varios menús, puntaciones, niveles, dificultad, etc. Esto ya conlleva no hacer las cosas a la ligera y planificar mucho más que es lo que se va a hacer y como se va a abordar.

Es muy importante cumplir los requesitos previos, sino estarás algo perdido y te desmotivarás. No voy a volver a explicar conceptos de los ya mencionados arriba, porque están explicados de manera extensa en los artículos mencionados, nos vamos a centrar en utilizar lo ya aprendido y en algunas cosas nuevas para hacer un proyecto de más envergadura.

Preparándonos para trabajar

Lo primero como siempre es tener un directorio de trabajo donde irán los archivos de nuestro proyecto. Dentro de este yo lo tengo organizado de la siguiente manera:

• Directorio principal/
  • archivos .py
  • Data/
    • graphics/
      • backgrounds/
      • menus/
      • sprites/
    • audio/
      • music/
      • sounds/
    • fonts/
  • levels/

A grandes rasgos la estructura es los scripts de python van en la carpeta principal, luego hay un directorio Data que contiene 3 directorios graphics, audio y fonts y a su vez estos tienen varios subdirectorios para según el contenido. Luego hay otra carpeta llamada levels que contendrá los niveles del juego. Esta es la estructura inicial que yo tengo puede que necesitemos algún directorio más en el proceso de creación, lo añadiríamos sin problemas.

Estructura del juego

Bien montado el chiringuito, antes de ponernos a escribir código vamos a ver de que partes consta nuestro juego. Es un juego clásico del Arkanoid, pero es nuestro Arkanoid y lo podemos hacer tan parecido o tan diferente como queramos. Lo primero es definir las escenas. Las escenas del juego son las diferentes pantallas que nos podemos encontrar. El menú principal, la pantalla de puntuaciones, un nivel del juego… Son diferentes escenas dentro del juego. Lee este tutorial para saber más sobre las escenas y saber como gestionarlas con Python y Pygame.

En principio nuestro juego va a constar de 3 escenas diferentes.

• SceneHome: Será el menú de inicio de nuestro juego y desde este podremos empezar una nueva partida, continuar, mirar las puntuaciones o salir.
• SceneGame: Será la escena de nuestro juego, donde se carguen los niveles y donde jugaremos. Será la escena más importante pues contiene el juego en sí.
• ScenePoints. Será una escena que contendrá las mejores puntuaciones de nuestro juego.

Veamos un esquema de nuestas escenas:

La escena principal (SceneHome) será la primera que se cargará al ejecutar el juego y desde la que podremos acceder a las otras dos como indica el diagrama. Como véis las flechas indican de que escena se puede ir a cual, por ejemplo desde SceneHome se puede acceder a SceneGame y ScenePoints y desde estas a SceneHome, pero desde SceneGame no se puede acceder a ScenePoints. Es decir, es SceneHome la encargada de comunicar a las escenas.

El archivo confi.py

El primer archivo de nuestro proyecto no va a ser el main.py que sería lo típico, sino un archivo llamado config.py, Este archivo contendrá información global del juego y parámetros de configuración globales que podrán ser accedidos desde todo el proyecto. Variables tales como la resolución, el nombre del juego o rutas de directorio los iremos poniendo aquí, de momento vamos a definir unas variables bases.

# -*- encoding: utf-8 -*-

""" Configuración general del proyecto """

# Nombre
name = "Arkanoid"

# Resolución
width = 640
height = 480

# Directorios
sprites = "data/graphics/sprites/"
backs = "data/graphics/backgrounds/"
menus = "data/graphics/menus/"
fonts = "data/fonts/"
music = "data/audio/music/"
sounds = "data/audio/sounds/"
levels = "levels/"

Hemos definido una variables básicas para la resolución y los directorios. La ventaja de tenerlos aquí es que si en algún momento deseamos cambiar el nombre de un directorio, la resolución o cualquier otro parámetro global, no hay que estar buscando donde lo hemos usado, sino que directamente editamos nuestro config.py.

• Arkanoid V – Creando la bola
• Arkanoid IV – Creando la pala
• Arkanoid III – Diseñando la pantalla de juego
• Arkanoid II – Gestionando escenas
• Juego de la serpiente paso a paso. Parte 2