El Motor del Videojuego – III

Contexto

Si acabas de aterrizar en el Blog, te recomiendo que antes de continuar que te dejes caer por aquí:

Así mismo recomiendo leer también las 2 entradas que hablan sobre YokaiEngine – el motor que estamos creando para desarrollar Sticks & Stones:

Auto-cast de objetos

El artículo de hoy se va a centrar en lo que llamo auto-cast de objetos de Flash a C#.

Para que me sea más sencillo de explicar en qué consiste el auto-cast, voy a recurrir de nuevo a nuestro personaje de ejemplo Sigfrid – El Paladín.

Imaginemos que hemos creado una animación en Flash y la llamamos paladin:

paladin_instance

Tal y como hemos hablado en anteriores artículos, el motor es capaz de replicar todos los objetos Flash y sus animaciones de forma recursiva, y reconstruirlos tal cual en C#.

Sólo basta con definir en la Screen de juego una variable del tipo CustomSprite (propia del motor) con el mismo nombre que hemos usado en el Flash:

public class Screen PlayableScreen
{
      public CustomSprite paladin; 
}

Y obtenemos lo siguiente:

paladin

Imaginemos por un momento que queremos acceder a cualquier parte de la animación, por ejemplo a la espada. Para ello deberemos realizar los siguientes pasos:

  1. Dar un nombre identificativo al objeto Flash
  2. Crear jerarquía de clases C# para definir padres-hijos

Vamos a asignar un nombre al objeto de la espada, en este caso le llamaremos weapon.

weapon_instance

Clases tipadas

Sigfrid, nuestro paladin, va a dejar de ser una clase del tipo CustomSprite (que es genérica) para pasar a tener su propia clase – PaladinCharacter. Lo que nos va a permitir poder definir dentro contenido propio:

public class Screen PlayableScreen
{
      public PaladinCharacter paladin; 
}
public class PaladinCharacter CustomSprite
{
      public CustomSprite weapon;
}

De esta manera ya podríamos tener acceso al arma a través del objeto paladin, y por ejemplo hacerla desaparecer:

public class Screen PlayableScreen
{
    public void RemoveWeapon()
    {
        paladin.weapon.Visible = false;
    }

no_weapon

Cuando el motor recrea los objetos del Flash, lo que hace es crear instancias automáticamente al tipo indicado en la definición de la variable. En nuestro caso:

  • paladin lo castea al tipo PaladinCharacter
  • sword lo castea al tipo CustomSprite

Recursividad

Esta técnica de auto-cast es recursiva y puede comprender todos los niveles que se necesiten. Profundizando más en el mismo ejemplo, podríamos tener la siguiente estructura:

public class PaladinCharacter CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
}
public class Weapon CustomSprite
{
      public Blade blade;
      public Grid grip;    
      public CrossGuard crossGuard;
}
public class GripCustomSprite
{
      public Handle handle;
      public Jewel jewel;    
}

Listas

El auto-cast también funciona con listas. En el caso que tengamos más de un objeto del mismo tipo, por ejemplo los brazos (en este caso 2), en el Flash los identificamos con el mismo nombre acabado en número  (arm0 y arm1):

instance_arm

Ahora solo basta con tiparlo como una lista y ya:

public class PaladinCharacter CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
      public List<Arm> arm;
}

Generar cualquier estructura jerarquizada de objetos es muy útil para poder realizar animaciones complejas y aún así tener el control total de acceso a cualquier objeto (para poder realizar la transformación).

 

¡Si te ha gustado compártelo! :]

El Motor del Videojuego – II

Hace unas semanas publiqué el artículo – El Motor del Videojuego – I, en el que explicaba:

  • El uso de un motor propio para el desarrollo de Sticks & Stones
  • Y la facilidad para ajustar el arte en cualquier etapa de desarrollo

El artículo de hoy pretende profundizar un poco más sobre las virtudes del motor, y más concretamente, lo que yo llamo: Transformación de objetos en tiempo real.

Vamos allá.

Una de las grandes aportaciones del motor, es la capacidad de replicar las animaciones de Flash al videojuego, sin que se requiera añadir una sola linea de código.

paladin

FLASH

Cuando realizamos animaciones en Adobe Flash, es altamente recomendable usar siempre objetos separados, tanto para dibujar como para animar. En nuestro caso, y continuando el ejemplo del anterior artículo, vamos a usar el Paladín, asignando a cada parte un nombre distinto.

paladin

paladin2

JUEGO

Ahora, desde cualquier punto del código, podríamos acceder a estos objetos mediante su nombre, y poder transformarlos como queramos.

Para que podáis ver cómo se aplican estas transformaciones en tiempo real, he grabado unos vídeos con la ejecución del juego, dónde voy aplicando transformaciones mediante accesos rápidos:

INTERCAMBIO

Permite poder sustituir un objeto por cualquier otro.

intercambio

 

TRANSPARENCIA

Se le puede asignar un % de transparencia a cualquier objeto.

transparencia

 

ROTACIÓN

Podemos rotar cada una de las partes 360º.

rotation

ESCALA

Se puede aumentar o reducir la escala de cualquiera de los objetos.

escala

VELOCIDAD ANIMACIÓN

Podemos indicar mediante un % la velocidad de reproducción de las animaciones.

velocidad

COLOR

Se puede tintar el color original de las texturas.

color

Como podéis ver, estas transformaciones nos abren las puertas a casi cualquier posibilidad y combinación que nos imaginemos…

Espero vuestros comentarios, y en futuros artículos iré detallando otras funcionalidades del motor.

¡No nos dejéis de recomendar! 😀

El Motor del Videojuego – I

Siempre que nos preguntan -¿Y qué motor estáis usando para desarrollar Sticks & Stones? muchas veces antes de que podamos contestar, añaden una segunda pregunta Unity supongo… ¿no?

Pues no.

Sé que en el mercado actual del desarrollo indie, se está usando como primera opción el de-sobras-conocido motor Unity, ya sea por su facilidad de uso, su documentación, su store o por su comunidad…

Pero en nuestro caso hay varios factores, que os iremos explicando más adelante, por los que nos decantamos a usar un motor propio – llamado YokaiEngine – basado en el Framework de Microsoft – XNA.

Sinergia Adobe Flash y YokaiEngine

El leitmotiv de YokaiEngine, es poder usar objetos Adobe Flash como si fueran nativos en C#.

Todo su potencial reside precisamente en este factor, que aunque parezca algo trivial, veremos más adelante que no lo es en absoluto.

En nuestro caso, con Sticks & Stones, usamos Adobe flash en una gran parte del arte, sobre todo para elaborar el diseño de personajes y sus animaciones.

Para entender la mecánica más básica del motor y de cómo incorporar dibujos y animaciones a nuestro proyecto, vamos a verlo mediante un ejemplo visual y sin entrar en la parte técnica (aún).

Lo primero que haremos será crear una animación en Adobe Flash:

En este caso, he recuperado una vieja animación de Sigfrid, un Paladín que hice hace algún tiempo, que me va a servir para explicar todo el proceso.

Para poder incorporar la animación de Sigfrid a de nuesto juego, bastará con:

  1. Añadir el fichero compilado que genera Adobe Flash (.swf) a nuestro proyecto
  2. Crear una clase C# indicándole la ruta de este fichero
  3. Ejecutar el juego

YokaiEngine detectará este fichero Adobe Flash (.swf) como nuevo y realizará de forma automática los siguientes pasos:

  1. Leer todos los objetos incluidos en el .swf
  2. Generar las texturas de todos los objetos
  3. Crear un fichero XML con las instancias, animaciones y metadatos necesarios

export

El resultado una vez ejecutado el juego es el siguiente:

Como podéis ver, incorporar animaciones Flash al juego es realmente sencillo, pero tampoco nada super-awesome. Vamos a indagar más en qué es lo realmente potente de dicho motor…

Las claves del YokaiEngine

A continuación nombraré algunos de los que podríamos considerar puntos fuertes de YokaiEngine:

  • Facilidad para ajustar el arte en cualquier etapa de desarrollo
  • Transformación de objetos en tiempo real
  • Auto-cast de objetos
  • Agrupación de todos los assets y texturas en un único fichero (.swf)

Hoy vamos a desarrollar el primero de ellos.

Facilidad para ajustar el arte en cualquier etapa del desarrollo

Por mucha experiencia que tengamos desarrollando videojuegos, los cambios a nivel de arte siempre van a estar presentes a lo largo de todo el desarrollo. Ya sea que el tamaño de un personaje es desproporcionado una vez colocado en un escenario, la paleta de colores va evolucionando o simplemente hay que realizar ajustes estéticos.

Supongamos que ya tenemos incorporadas en nuestro juego algunas animaciones de Sigfrid: como la de correr, saltar y atacar. Y por alguna razón, tenemos que modificar el aspecto actual del casco. ¿Os imagináis modificar todas y cada una de las animaciones y fotogramas para realizar dicho ajuste? Dependiendo de cómo las hayamos realizado (¿pixel art?), puede ser una tarea titánica, ¿verdad?

Por suerte, en nuestro caso no nos llevará más de unos pocos segundos, y esto es gracias a cómo gestiona los objetos y símbolos Adobe Flash.

ajustesarte_0

Bastará con acceder al elemento casco, realizar cualquier modificación (color, forma, tamaño, …) y guardar los cambios (generando así un nuevo .swf). En nuestro caso hemos ampliado ligeramente el tamaño del casco (aumentando la sensación de cartoon) además de añadir una estrella decorativa. El resultado es el siguiente:

ajustesarte_2

Al ejecutar de nuevo el juego, YokaiEngine detectará estos cambios y volverá a generar de nuevo texturas y el XML con la información (vemos que en realidad sólo ha generado la nueva textura del casco).

exportb

Ya tenemos todas las animaciones de Sigfrid de nuevo incorporadas al juego sin tocar una sóla línea de código:

Poder realizar cualquier ajuste a nivel de arte en cualquier etapa del desarrollo del juego, y además de una forma tan inmediata, es uno de los factores clave del motor.

Además, hemos de tener en cuenta que esta necesidad de ir ajustando el arte, se acentúa más aún si somos noveles en esto de desarrollar videojuegos, ya que muchas veces al inicio de éste, no sabemos cómo será el resultado final. Poder disponer de una herramienta que nos ayude a ajustar esto de forma casi transparente es un win-win.

Otro factor a tener en cuenta en esto, es que al tratarse de dibujo vectorial, se puede escalar, rotar y alterar cualquier textura sin perder nada de calidad (doble win-win).

 

Espero que os haya gustado el artículo. Me gustaría saber vuestra opinión sobre esta elección de usar un motor propio. ¿Creéis que es acertada?