Es el llamado GameLoop, este esquema es solo un concepto con los componentes más básicos, hay en medio luego siempre hay controles de tiempo, vsync, gestión de pausas, etc. Pero todo se basa en lo mismo actualizar todos los componentes (física, IA, etc), dibujarlos en pantalla según los nuevos datos, procesar los eventos (pulsación de teclas, cierre de una ventana, etc) y vuelta a empezar el ciclo. Esto en muchas bibliotecas se implementa por el medio de escenas, como puedes leer en este artículo.

El programador se debe de encargar de mediante tres métodos que se suelen llamar Event(), Update() y Draw() de implementarlos según requiera la escena en cuestión.

Hay una problemática común en el método de dibujado. Qué se debe dibujar y que no y en que orden.

Qué se debe dibujar

En la programación de videojuegos hay una regla de oro:

Nunca dibujar nada que no se vaya a ver en pantalla.

Esto es debido a que el dibujado de gráficos en pantalla es una de las operaciones más lentas. Imaginemos el siguiente escenario como el mapa de un juego donde el rectángulo rojo es la pantalla.

Obviamente el jugador solo está viendo los cuadros azulados ya sea en su totalidad o en parte, los cuadros grises son parte del mapa que no están a la vista y por tanto nunca hay que dibujarlos.

En qué orden se debe dibujar

Esto es otra cosa importante tengo mi mapa que contiene una superficie de terreno, un árbol y un héroe.

En la imagen de la izquierda está claro que primero se debe dibujar los tiles de terreno, luego el sprite que representa al árbol y por último a nuestro héroe. Sin embargo en la de la derecha las prioridades cambian ahora el árbol se debe “dibujar” después de nuestro héroe para que de la sensación de que está pasando por detrás.

Manejar todo esto manualmente es un engorro, tienes que montar todo un sistema para detectar si tal gráfico es visible o no y tener cuidado de en que orden dibujarlo. Lo ideal sería un sistema que detectara si un gráfico está o no en pantalla para saber si lo dibuja o no y también que a nuestros gráficos se les pudiera asignar un número Z que representara su “profundidad” para alterar fácilmente el orden de dibujado.

El problema: la estructura de clases de SFML

SFML tienes en principio 3 tipos de objetos dibujables en pantallas: Sprites, Textos y Figuras (Qué a su vez hay tres tipos Círculos, Rectángulos y figuras convexas). Estos tipos de objeto heredan de dos clases bases: Transformable y Drawable. La primera le da las propiedades de poderse transformar: escalarse, rotarse, moverse, etc. Y la segunda la capacidad de que sea un objeto dibujable en pantalla. Este es el esquema:

Podemos ver como todas heredan de Transformable y Drawable. El problema viene al que los tres objetos comparten la misma base (heredan de Transformable y Drawable), pero si se les quisiera añadir una propiedad común a todos ellos habría que añadirla por separado ya que no existen entre ellos ninguna relación.

Ahora viene nuestro ejemplo de antes en el que queremos también comprobar que otras cosas dibujables como textos y figuras se deban dibujar y en que orden, pues si son objetos dibujables y transformables igual que los sprites también tenemos que tener en cuenta esto que analizamos antes.

El problema viene que la idea es crea un objeto común llamado ObjectScene del que heredan Sprite, Shape y Text. Esta clase abstracta  herada de Drawable y Transformable así quedaría una relación entre todos ellos a las que se les podría añadir funcionalidades como un orden y la posiblidad de tratarlos como un conjunto. Este sería el esquema resultante:

Ahora cada vez que queramos añadir una propiedad común a todos los objetos que se dibujan basta con añadirla a la clase SceneObject y actomáticamente todos tendrán esa propiedad, además de tener una clase común que sirve para mediante métodos virtuales representar y dibujar como un todo a objetos de la escena.

1. GameDev

Una de las mayores comunidades de la red sobre desarrollo de videojuegos, en sus foros siempre encontrarás a alguien dispuesto a ayudarte con cualquier tipo de cuestión, hay gente muy experimentada en los foros. En su sección de artículos hay verdaderas joyas que merece la pena ver. Un lugar obligado para los favoritos de cualquier desarrollador de videojuegos.

• Enlace: http://www.gamedev.net

2. Gamasutra

Otra de las más grandes. En Gamasutra puedes encontrar siempre las últimas novedades de la industria y ver que se cuece tanto en las grandes compañías como en el panorama indie. Entres sus artículos también hay grandes obras de arte de obligada lectuta. No se centra solo en la programación sino también en diseño, gráficos, audio, producción y marketing.

• Enlace: http://www.gamasutra.com

3. GPwiki

La idea es simple, crear una gran wiki sobre desarrollo de videojuegos. Hay muchos tutoriales y guías sobre diversos lenguajes de programación todo bien ordenado, seguramente encontrarás cosas muy útiles entre sus artículos. También cuenta con un foro con mucha actividad y donde podrás plantear tus dudas y porque no, colaborar tanto en los foros como ampliando la wiki.

• Enlace: http://www.gpwiki.org/

4. #AltDevBlogADay

Una joya de blog con artículos de primerísima calidad. En él escribe mucha gente que se dedica al desarrollo de videojuegos algunos con muchísima experiencia que trabajan en compañías de renombre. En el puede encontrar todo tipo de artículos desde reflexiones generales de la industria hasta grandes artículos de nivel técnico de alguna tecnología específica. Si no lo tienes añádelo ya a tu RSS o tus favoritos.

• Enlace: http://www.altdevblogaday.com/

5. Stratos

El único de la lista en español, ya sabemos que la industria habla inglés. Pero Stratos está aquí porque a mi criterio se lo ha ganado a pulso, una de las mejores comunidades en español por no decir la mejor sobre desarrollo de videojuegos. Sus foros están llenos de gente experimentada dispuesta a echarte un cable (siempre y cuando no quieras hacer un mmorpg definitivo). Además podrás encontrar ofertas de trabajo de la industria.

• Enlace: http://stratos-ad.com/

6. Gamedev tuts+

Perteneciente a la saga de blogs tut+ que se dedica a ofrecer blogs de tutoriales de varias ramas relacionadas con la informática. Gamedev tuts+ cuenta con muy buenos artículos tanto de programación, como de diseño o arte. El proyecto es relativamente nuevo, pero ya tiene bastante material interesante y se actualiza con frecuencia.

• Enlace: http://gamedev.tutsplus.com/

7. DevMag

Revista Sudafricana que cuenta con un gran blog sobre desarrollo de videojuegos. En el blog se puede encontrar todo tipo de artículos tanto de programación como de diseño. A parte los números de la revista también se pueden encontrar. Buenos artículos, buen material.

• Enlace: http://devmag.org.za/

8. AiGameDev

Sitio por excelencia donde entrontar artículos sobre inteligencia artificial enfocada a videojuegos, su único inconveniente es que es un sitio de pago, pero tiene muchos artículos muy interesantes de acceso gratuito, merece la pena tenerla en tus favoritos si estás programando inteligencia artificial.

• Enlace: http://aigamedev.com/

9. OpenGameArt

Una gran idea, una gran comunidad. La idea era un sitio donde publicar y recopilar ordenadamente arte libre para videojuegos, para que todo desarrollador tuviera un sitio donde encontrar gráficos para sus juegos o prototipos, hay mucho contenido y de mucha calidad tando gráficos en 2D como en 3D, incluso música y efectos de sonido.

• Enlace: http://opengameart.org/

10. 2D Game Art For Programmers

La salvación de los programadores que como yo somos unos negados para el desarrollo gráfico, en este blog aprenderás toda clase de trucos para desarrollar gráficos prototipos rápidamente aunque no tengas ni idea y tu línea más recta sea un círculo. Complementar con este artículo de Siondream.

• Enlace: http://2dgameartforprogrammers.blogspot.co.uk/

Seguro que echas de menos alguno y he cometido un sacrilegio al no ponerlo, ¡Adelante! Coméntanoslo en los comentarios.

Una de las cosas necesarios para RAGE es el leer y escribir archivos ini. Parseadores de este tipo de archivos existen muchos como por ejemplo inih. Aunque en Razón Artificial usaremos uno derivado del proyecto GQE que se adapta muy bien a SFML.

Generar ficheros ini

La cuestión es a la hora de crear estos archivos, generar un ini no he encontrado nada, supongo que por lo trivial y la simpleza que supone ya que no es más que generar un fichero de texto. Por tanto he implementado una clase que se encarga de generar ficheros .ini

Definición

class ConfigCreate
{
public:
	ConfigCreate();

	~ConfigCreate();

	void Open(const std::string& filename);

	void Close();

	void PutSection(const std::string& section);

	void PutValue(const std::string& key, const std::string& value);

	void PutComment(const std::string& comment);

	void PutBlankLine();

private:
	std::ofstream file;

}; // class ConfigCreate

Implementación

ConfigCreate::ConfigCreate()
{
}

ConfigCreate::~ConfigCreate()
{
}

void ConfigCreate::Open(const std::string& filename)
{
	file.open(filename);
	file.clear();
}

void ConfigCreate::Close()
{
	file.close();
}

void ConfigCreate::PutSection(const std::string& section)
{
	file << "[" << section << "]" << std::endl;
}

void ConfigCreate::PutValue(const std::string& key, const std::string& value)
{
	file << key << "=" << value << std::endl;
}

void ConfigCreate::PutComment(const std::string& comment)
{
	file << "# " << comment << std::endl;
}

void ConfigCreate::PutBlankLine()
{
	file << std::endl;
}

por último su tilización no puede se más sencilla.

ConfigCreate c;
c.Open("prueba.cfg");
c.PutSection("window");
c.PutValue("width", "640");
c.PutValue("height", "480");
c.PutComment("Activa la pantalla completa");
c.PutValue("fullscreen", "0");
c.PutBlankLine();
c.PutSection("Otra");
c.PutComment("lalalalala");
c.PutValue("djd", "edjie");
c.Close();

Esto generaría el siguiente fichero llamado prueba.cfg.

[window]
width=640
height=480
# Activa la pantalla completa
fullscreen=0

[Otra]
# lalalalala
djd=edjie

• Inicializar y Cerrar la aplicación.
• Inicializar los componentes necesarios.
• Crear y gestionar la ventana de la aplicación.
• Crear y gestionar el log de la aplicación.

Vamos a pasar a analizar cada uno de ellos por separado.

Inicialización y cierre de la aplicación

En algo importante en un sistema como este, se encarga de inicializar el Game Engine, establecer el punto de entrada y por último se encarga de las operaciones de cierre como liberación de memoria y cierre de ficheros.

En motores más complejos contendría la reserva y gestión de memoria, pero es algo no necesario en nuestro engine.

Inicializar los componentes necesarios

RAGE es un software basado en componentes, es decir, varias piezas que se unen para formar un sistema. Hay algunos de estos componentes que se consideran esenciales para el funcionamiento del Engine y son los siguientes.

File System

Se encarga de definir un sistema de archivos confiables para la aplicación. Sirve para acceder a rutas de recursos y directorios donde guardar archivos. Debe ser independiente de la plataforma y sencillo de usar.

La idea es poder usar un sistema sencillo que defina rutas relativas al ejecutable de la aplicación.

Scene Manager

Se trata de un sistema de escenas. Los juegos están basados en escenas diferentes como una pantalla de inicio, un video de introducción, un menú o una pantalla de puntuaciones. Todo esto es mejor gestionarlo por escenas o estados, en otro artículo hablaré más extendidamente del Scene Manager.

Asset Manager

Se encarga de la gestión de recursos. Carga los recursos necesarios buscando en los directorios definidos, evita la carga duplicada de recursos, debe tener varias formas de cargar un recurso.

Log System

El sistema de Log me he basado en el principio KISS (Keep it Simple, Stupid). Así que en lugar de usar logs complicados será un simple ofstream de la STL redirigido a un fichero.

Estos serían los sistemas básicos a inicializar, pero dependen de otros componentes.

Componentes auxiliares

Strings Utils

Se ha de crear una colección de funciones para el manejo eficiente de cadenas, conversión rápida y eficiente, así como un método de hash para una comparación rápida.

Executable dir

Se debe de obtener un método para obtener la ruta del ejecutable que es con la que opera el sistema de ficheros y a través de este el gestor de recursos para la carga de archivos desde una memoria secundaria (discos duros, cds, dvds, etc).

INI Parser

El Engine se basará en archivos .ini para su configuración por lo que se necesita poder poder leer este tipo de ficheros así como crearlos si no existen.

Todo esto no es más que componentes básicos que se necesitan desde un principio y no los únicos, se ha hecho un repaso por arriba, en futuros artículos hablaremos de cada uno de ellos en profundidad.

Lo ideal sería que los juegos solo dependieran de RAGE, pero esto supondría crear toda una capa de abstracción sobre SFML que no es necesaria pues SFML es una biblioteca muy bien diseñada y con clases muy útiles. Así que desde este momento RAGE queda ligado a SFML y no se podría cambiar el “motor multimedia” por así decirlo, puesto que si fuera una capa de abstracción en un futuro podríamos definir SDL u otros sin que afectara al Engine.

Estructura general del sistema

Una vez decidido el tipo de relación vamos a definir lo que sería RAGE a grandes rasgos y que aporta a SFML.

En el esquema se ve que SFML y Core System aislan al usuario de bibliotecas de terceros y al Sistema Operativo del usuario. En este contexto tenemos que los juegos están formados por escenas que hacen uso de todo lo que tiene SFML más lo añadidos del Core System que son los siguientes:

• App – Inicialización y cierra de la Aplicación así como la gestión de la ventana del juego.
• Scene Manager – Gestor de escenas.
• Strings Utils – Varia utilidades para trabajar con cadenas de textos, parseadores de cadenas y hash ID.
• Parser INI – Parseador de archivos .INI, .cfg, etc.. (Fallo en el gráfico de arriba pone Parser XML cuando es Parser INI).
• Parser TMX – Parseador para le formato de mapa de Tiled.
• FileSystem – Acceso seguro al sistema de ficheros del SO independiente de la plataforma.
• Log System – Sistema de Log de la aplicación.
• Asset Manager – Gestor de recursos.

Todo esto es a rasgos generales en próximos artículos iremos explicando cada componente de forma detallada y su función.

Una vez hecho esto se necesitaba definir un repositorio, una licencia y una estructura.

Licencia

El proyecto será software libre, licenciado bajo la licencia del MIT. La razón es que es un licencia muy poco restrictiva tanto para el que quiera usarlo para software privativo como para el que desee hacer software libre, además de ser una licencia pequeña, clara y concisa.

Repositorio

He decidido usar como control de versiones a GIT y como repositorio público a GitHub.

• https://github.com/adrigm/RAGE

Estructura

Una de las cosas que es importante definir al comenzar un proyecto es su estructura. Lo primero que hay que tener en cuenta es de que tipo de proyecto se trata. RAGE es un Game Engine, es decir un medio para construir videojuegos con él, los videojuegos son programas por tanto la estructura que le conviene a RAGE es de biblioteca.

Esta es la estructura de directorios que he decidido usar.

|- RAGE/
    |
    |- bin/
        |- ejecutable
        |- Data/
            |- ... 
    |- builds/
        |- codelite/
        |- vc2010/
        |- ...
    |- extlibs/
        |- headers/
        |- bin/
    |- include/
        |- RAGE/
    |- lib/
        |- Rage.lib / Rage.a
    |- src/
        |- RAGE/
        |- Test/
    |- .gitattributes
    |- .gitignore
    |- license.txt
    |- README.md

Como vemos en el directorio bin van los binarios generados, en nuestro proyecto irá el ejecutable del proyecto Test que es un protecto de prueba que usa el Engine.

En el directorio builds van soluciones para diferentes IDE como Visual Studio y Codelite que son los IDE que usaré en principio. Más adelante espero que sean sustituidos por Cmake.

En include meteremos todos los archivos de cabecera de nuestra biblioteca.

En extlibs meteremos los headers y binarios de otras bibliotecas externas que use el proyecto como SFML, Boost, etc.

En lib irá las bibliotecas generadas ya sea .lib, .a, .dll ó .so.

En el directorio src tenemos dos carpetas RAGE y Test. Dentro de RAGE irá todo el código fuente del proyecto y en Test irá el código fuente de la aplicación de prueba. Todo ello en una estructura de directorios coherente.

Esta será la estructura básica de directorios del Engine, siempre sujeta a cambios.

Hola David, ¿Qué tal?

Buenas. Muy bien, un poco de frío por aquí.

¿Qué tal la vida por Nottingham?

Genial, es una ciudad joven con dos universidades y tiene mucha actividad: conciertos, pubs, restaurantes, etc. Siempre hay algo que hacer, lo que compensa un poco el frío. No es Londres pero los precios son considerablemente más bajos, no me quejo.

Te fuiste a Londres a hacer un master en desarrollo de videojuegos, ¿Qué tal la experiencia?

Fantástica. Las instalaciones eran inmejorables, el laboratorio de videojuegos contaba con decenas de equipos potentes, Xbox y PSPs de desarrollo. Todo en perfecto estado disponible para el alumno fuera de horario de clases.

Además, tienen muchos contactos en la Industria del Videojuego y rara era la semana que no había una conferencia: Sony, Turbulenz, Splash Damage, Crytek.

Aunque el nivel de programación no es muy alto allí, aprendí muchísimo ya que todo estaba orientado a proyectos. También hice muchos contactos, algo imprescindible.

De ahí a trabajar en Crytek, ¿Cómo se consigue que una de las grandes se fije en uno?

Diría que son muchos factores. Lo primero y más importante es construirse un porfolio online y llenarlo de proyectos en los que hayas trabajado. No tienen porqué ser juegos complejos, lo imprescindible es acabarlos. Publicar el código fuente ayuda a esforzarse en mejorar, hacer comunidad y a que los demás puedan ver tu trabajo.

Ser realista, empezar con juegos asequibles e ir subiendo. Se valora mucho saber optimizar, así que el tener algo para móviles está bien.

Después conviene moverse un poco en el sentido de conocer gente tanto en persona como a través de Internet. Asistir a eventos, ser social, involucrarse en comunidades… Así se aumentan las posibilidades de estar en el sitio adecuado en el momento oportuno.

¿Cómo es trabajar en Crytek?

Muy emocionante. Estás trabajando junto a los mejores profesionales de la Industria en proyectos de una envergadura mastodóntica, son juegos triple A. El reto hace que aprendas constantemente.

El ambiente de Crytek UK es estupendo, la oficina es moderna, luminosa y tiene un plan abierto, lo que facilita la comunicación entre equipos. Se trabaja duro y con fechas ajustadas pero de forma cómoda. La atmósfera es de colaboración estrecha y los compañeros son geniales.

Después del trabajo nos relajamos jugando al fútbol o con un pub quiz.

¿Alguna novatada o esas cosas no se llevan por Crytek?

Jaja, no, en casi un año en Crytek, yo no he visto ninguna. Hay mucho respeto y desde el primer día fui uno más del equipo.

¿Nos puedes contar en que juego estás trabajando y cuáles son tus funciones?

Soy programador de IA en Homefront 2.

Cuéntanos si puedes que tecnología usas a grandes rasgos, ¿Su usa casi todo propio o se utilizan bibliotecas o frameworks consolidados?

En Crytek trabajamos con CryEngine, un motor propietario desarrollado “in-house” cuya versión con fines no comerciales es de uso gratuito. Otras compañías pueden licenciarlo si quieren.

CryEngine está mayoritariamente escrito en C++ así como parte del código de cada juego. El scripting se lleva a cabo con Lua, XML y Flowgraph. Éste último es un sistema de scripting visual con el que trabajan los diseñadores en el Sandbox Editor de CryEngine. Por supuesto, contamos con muchas más herramientas auxiliares.

Tu equipo tiene permiso para añadir o modificar el CryEngine o es una herramienta que viene de otro equipo que solo podéis usar, ¿Cómo funciona este tema si se necesitan nuevas funcionalidades?

Nosotros somos los que desarrollamos CryEngine. Cuando necesitamos una nueva funcionalidad, la añadimos, así es como evoluciona. Posteriormente, es posible que se añada de forma oficial en la siguiente actualización.

Si algún día uso el CryEngine y me falla ya se ha quien echar la culpa.

Bueno, antes de que se publique una versión oficial del SDK hay un fuerte proceso de testeo constante. Seguramente, lo que uses de CryEngine ya habrá sido utilizado de forma intensiva en muchos juegos de la compañía.

No obstante, no existe un sistema tan complejo 100% libre de bugs. Es un proceso iterativo.

Nos has hablado de un portafolio y contactos para hacerse un hueco en la industria. Supongo que das por hecho otras cosas como un nivel de inglés, de programación, etc. Cuéntanos la clave, ¿Qué se necesita para trabajar en la industria referente a conocimientos?

Es imprescindible contar con una base fuerte de programación. Si bien es cierto que muchas empresas (sobre todo móviles) están utilizando tecnologías como Unity, C++ sigue siendo el lenguaje por antonomasia.

Hay que saber manejar y diseñar estructuras de datos, tener fundamentos de algoritmia, dominar C/C++ a bajo nivel. Principalmente como se organizan los objetos en memoria y sus consecuencias, por qué es mejor utilizar un algoritmo antes que otro en un caso determinado etc. Ser eficiente y escribir código legible es muy importante.

En un proyecto tan grande necesitas saber leer código ajeno y comprenderlo así como ser capaz de ampliarlo o corregirlo. Saber depurar también es muy relevante.

En el plano matemático y físico es recomendable tener conocimientos de geometría, álgebra lineal y cinemática.

Inglés es el lenguaje oficial de la mayoría de estudios, incluso aquellos localizados en países no angloparlantes. Sobra decir que hay que dominarlo a nivel profesional, la comunicación con el equipo es fundamental.

¿Especialización o un poco de todo, qué pide el sector?

Para un puesto de programador junior no se suele pedir una especialización. Sí es necesario que demuestres tus conocimientos de programación de videojuegos a través de tus proyectos.

Estaría bien que entre todos cubrieras los aspectos básicos de áreas como gameplay, AI y rendering. Un poco de todo.

¿Sigues trabajando en otros proyectos por amor al arte?

Sí, sobre todo para fortalecer lo que ya se y aprender cosas nuevas. También porque me gusta.

Actualmente utilizo Java y el fantástico framework libre y multiplataforma libgdx. Trato de seguir game jams y eventos similares.

¿Cómo ves la industria de los videojuegos?

Es un mundo apasionante que evoluciona extremadamente rápido y conduce parte del avance tecnológico. Esto provoca que muchos estudios no sepan adaptarse y deban cerrar, lo cual es triste. Eso sí, siempre hay nuevas compañías y modelos que van surgiendo.

¿Qué te parece el boom del desarrollo Indie que ha surgido?

Creo que es un poco la respuesta a dos situaciones: pocas compañías pueden permitirse el disparatado coste de un triple A y un sector de los jugadores quiere experiencias nuevas.

Es genial porque le abre las puertas a mucha gente y crea diversidad. Tampoco creo que sea la panacea. No cualquiera puede tener éxito en el mundo indie, la cantidad de trabajo es un equipo pequeño es monstruosa si se quiere lanzar algo pulido, aunque sea simple. Quien no lo crea, ahí tiene Indie Game The Movie.

Danos un último consejo a todos los que queremos seguir tus pasos y trabajar en la industria.

Es posible, no es algo tan inalcanzable pero hay que trabajar muchísimo para conseguirlo. Día tras día, incluso cuando la motivación decaiga.

Hacer juegos y terminarlos, parece sencillo y lo he dicho antes pero es lo más importante, con diferencia.

¿Algo más que nos quieras comentar David?

Nada, muchas gracias por la entrevista y seguimos en contacto a través de nuestros blogs o cualquier otro medio.

Muchas gracias a ti por tu tiempo.

Después de mucho tiempo desarrollando lo que primero se llamo Basic Game Engine (BGE) y luego Generic Game Engine (GGE), ahora pasa a llamarse Razón Artificial Game Engine (RAGE) y se reestructura por completo.

Lo que venía siendo el GGE aunque no haya terminado de ver la luz una versión estable me ha ayudado a aprender mucho acerca del desarrollo de de aplicaciones en General y Desarrollo de videojuegos en particular, pero eso ha conllevado fallos de diseño y estructuras incosistentes que hacen que no sea un buen sistema con el que seguir. Así que he decidido Re-Comenzar el proyecto y contar la experiencia así que allá vamos

Qué es

Razón Artificial Game Engine (RAGE) es un Game Engine para el desarrollo de videojuegos 2D de propósito general y multiplataforma. Escrito en C++ sobre la biblioteca gráfica SFML y haciendo uso de otras bibliotecas consolidadas como la STL, Boost, PugiXML, etc.

Características iniciales

• Multiplataforma (Windows, Linux, OSX)
• De ámbito general. Sirve para desarrollar cualquier tipo de juego 2D.
• Basado en SFML 2. Que a su vez se basa en OpenGL. (Aceleración por Hardware).
• Gestor de Escenas
• Gestor de Recursos. Soporte de los siguientes recursos:
  • Formatos de imágenes comunes. (bmp, dds, jpg, png, tga, psd).
  • Formatos de audio comunes. (ogg, wav, flac, aiff, au, raw, paf, svx, nist, voc, ircam, w64, mat4, mat5 pvf, htk, sds, avr, sd2, caf, wve, mpc2k, rf64).
  • Formatos de fuentes comunes. (ttf, cff, pcf, fnt, bdf, pfr, sfnt, type 1, type 42).
  • Archivos de configuración (.ini, .cfg, etc).
  • Formato TMX (Tiled Map Editor).
  • Formato propio para animaciones 2D.
• Configuración fácil a través de archivos tipo ini.
• Gestión eficiente de recusos.
• Gestión eficiente de dibujado
• Soporte para SpriteSheet y Animaciones
• Sistema de Colisiones 2D basado en Rectángulos, Circunferencia y Pixel Perfect.
• Sistema de creación de Interfaces Gráficas del usuario (GUI).
• Soporte para dibujar mapas ortogonales e isométricos basados en Tiled.

Futuras ampliaciones

• Soporte para física a través de Box2D.
• Módulo con algoritmos de Inteligencia Artificial (Pathfinding, FMS, MinMax, etc).
• Soporte de Scripts en Python.

Como novedad iré comentando todas las decisiones y pasos importantes del proyecto en el blog.

Adentrarse en el desarrollo de videojuegos por primera vez puede ser emocionante a la vez que confuso. Un gran consejo sería: sólo haz juegos. Haz cosas y punto. A menudo me he encontrado a mí mismo investigando tecnologías que se adapten mejor a mis necesidades. Como si necesitase las cosas hechas a medida. El miedo a encontrarme en un punto muerto era tan poderoso como contraproducente. Dicho enfoque es un desperdicio de tiempo.

¿Cuál es el mejor Framework para empezar a desarrollar videojuegos? ¿Debo aprender un nuevo lenguaje para hacer juegos?

¡Alto!

Ni que decir tiene, que podrás cometer errores en el camino y que eso no es un es un estigma del que nos vayamos a deshacer a corto plazo. Cuando estaba trabajando en mi proyecto final de carrera, muy a menudo tenía que reescribir un subsistema completo desde cero (cara triste), pero eso es parte del proceso de aprendizaje. Pasar semanas mirando características de Frameworks avanzados lo más probable es que no entiendas muchas cosas. Toma esto como consejo para mantenerse enfocado en lo que realmente importa, la creación de juegos.

KISS (Keep It Simple, Stupid) (N.T. Hazlo simple, estúpido), es un principio de vida.

La curva de aprendizaje de este campo ya es suficientemente empinada como para tratar de complicar las cosas más aún. Si ya conoces un lenguaje de forma aceptable, no trates de aprender uno nuevo con el único proposito de usar un engine específico. ¡ Cuidado! Es muy fácil caer en esto.

Un par de búsquedas en Google o en Stack Overflow es suficiente para descubrir un game engine adecuado para el lenguaje que uses. Casi seguro va a ofrecer todo lo que necesitas y más. Si piensas que utilizar los últimos algoritmos gráficos disponibles es importante, te equivocas. Tetris, R-Type, Snake y similares son los recomendados como primeros proyectos y no necesitan ser un lujo en todo. Una vez más, deje todo un lado y sigue a delante para completar el juego.

Después de terminar un par de pequeños proyectos lo que debes preguntarte es lo siguiente: ¿Lo hago por diversión? En caso de que sí, puedes seguir con el entorno y lenguaje que te sientas más cómodo. Puedes hacer todos los juegos que quieras sin presión. Sin embargo, es posible que el objetivo sea vivir de ello. Cuando se aplica esto último debes aprender nuevos lenguajes y ampliar tus habilidades, teniendo en cuenta que el dominio de C++ es primordial.

En resumen, a menos que programes en Brainfuck , hay un montón de herramientas válidas que le proporcionará más poder que el que necesitas para desarrollar videojuegos.

• C: SDL
• C + +: SFML
• Python: PyGame
• Java: libgdx
• Ruby: OSU
• Flash: Flashpunk
• Lua: Love2D
• PHP: ¿me estás tomando el pelo?

¿Sigues escéptico?  Examina el foro de cada uno de ellos, te sorprenderá.

En realidad lo único que te debe preocupar es que el candidato elegido esté bien documentado y si cuenta con una comunidad activa o no. Cuidado con nichos y tecnologías crípticos.  Afortunadamente esos son fáciles de detectar mediante una ojeada rápida a su plataforma en línea. Excelente, ahora podrás disfrutar de las maravillas de tener un grupo de compañeros programadores que te pueden ayudar cuando te quedes atascado.

Terminando, ¿Sigues buscando desesperadamente la panacea final? No te preocupes demasiado, simplemente acaba de hacer juegos.

Comienza 2013 y Razón Artificial cumple 3 años. Fue en 2010 cuando comencé este blog y desde entonces ha cambiado un montón de veces de diseño y tipo de contenido (sí, he vuelto a cambiar el diseño). Pero siempre he procurado escribir guías y tutoriales útiles nunca limitarme a copiar y pegar de otros sitios.

En 2012 calló el ritmo de publicación y son pocas las aportaciones que he podido hacer al blog, este año espero que la cosa cambie y vuelva el ritmo de años anteriores. Con el nuevo año llegan los nuevos propósitos, así que aquí van los propósitos míos con respecto al desarrollo de videojuegos y Razón Artificial.

• Publicar más artículos en Razón Artificial, por lo menos uno a la semana.
• Terminar una versión usable del Generic Game Engine.
• Crear algunos juegos simples multiplataforma con el Generic Game Engine.
• Comenzar el desarrollo de un macroproyecto. Posiblemente un juego de estrategia en tiempo real (RTS).
• Buscarle un mejor nombre al Generic Game Engine.

Como veis la cosa gira entorno a mejorar el Framework de desarrollo de videojuegos que he venido realizando y luego crear un proyecto con él posiblemente un juego de estrategia (sobre todo por la IA). Sobre el último punto se aceptan sugerencias ya que Generic Game Engine es como el mismo nombre dice muy “Genérico” busco algo que lo identifique con Razón Artificial.

¡Feliz Año!

La web ha sido diseñada utilizando HTML 5 y CSS 3 así como el framework de desarrollo Bootstrap de Twitter.

Durante unos días puede que haya enlaces rotos o páginas que no funcionen bien, esperamos que esté todo 100% operativo en unos días.

He encontrado un material bastante interesante para los interesados en la progrmación de videojuegos, se trata de el curso de expertos en desarrollo de videojuegos. Se trata de un curso de programación de videojuegos completo.

Lo más interesante del curso es que dispone de todo el material para descargarlo gratuitamente, esto incluye 4 estupendos libros que abordan la programación de videojuegos desde niveles básicos hablando sobre herramientas, técnicas y consejos. Dejo los cuatro libros del curso que es el material más interesante.

1. Arquitectura del Motor. En este primer libro se estudian los aspectos esenciales del diseño de un motor de videojuegos, así como las técnicas básicas de programación y patrones de diseño.
2. Programación Gráfica. El segundo libro de la colección se centra en los algoritmos y técnicas de representación gráfica y optimizaciones en sistemas de despliegue interactivo.
3. Técnicas Avanzadas. En este tercer volumen se recogen ciertos aspectos avanzados, como estructuras de datos específicas, técnicas de validación y pruebas o simulación física.
4. Desarrollo de Componentes. El último libro está dedicado a ciertos componentes específicos del motor, como la Inteligencia Artificial, Networking, Sonido y Multimedia o técnicas avanzadas de Interacción.

Podemos encontrar ejemplos y código fuente en la web oficial del curso: http://cedv.morcy.es

Vamos a hablar de las tecnlogías usadas para los juegos de navegador. De estos juegos hay muchos están los típicos minijuegos Flash, los juegos de estrategia online del estilo Ogame o incluso  juegos de casino o poker donde ganar algo de dinero.

Las tecnologías usada para estos juegos de navegador se dividen en dos grandes grupos en los últimos tiempos:

Juegos Flash

La archiconocida tecnología propietaria de Adobe, tiene un lenguaje de programación propio como es ActionScript aparte de un editor visual donde realizar diferentes diseños y animaciones. Tiene a favor su extendido uso y documentación y que casi todo el mundo lo tiene instalado en sus ordenadores. En contra tiene que es tecnología propietaria y cerrada y un pésimo soporte en Linux.

Juegos en HTML5

Es el nuevo estándar que cada dia gana más adeptos, basado en javascript y en CSS3 con los actuales navegadores parece que será el punto fuerte en los próximos años. Tiene la ventaja de estándares abiertos y de que está en auge el mercado por su contra solo es soportado por navegadores modernos y aún tiene que madurar.

En definitiva la elección dependerá de si te interesa más utilizar estándares que funcionarán en todas las plataformas aunque aun esté algo verde o prefieres una tecnología más madura pero propietaria y con soporte dependiendo de una empresa.

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.

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.

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/

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

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.

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.

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.

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.

¿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,

|- 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.

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.

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.

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.

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.

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.

[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.

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/

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/

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

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.

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

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.

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

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

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/

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

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

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.

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.

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.

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.

• Ver charla

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.

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

¡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.

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

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

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

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.

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.

¿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.

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.

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.

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.

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.

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