Una técnica útil para detectar anomalías

Aviso: antes de que sigas leyendo, me gustaría avisar que esta entrada es de un tema puramente técnico, por tanto, si estás leyendo este blog queriendo ver "algo nuevo del juego", ni te molestes en leer lo que voy a contar de aquí en más, porque como ya dije, es puramente técnico.

Estos días estuve trabajando mucho en cosas que tal vez sean un poco aburridas de mostrar. Básicamente estuve corrigiendo muchos casos de borde, ajustando aspectos finos de la jugabilidad y agregando nuevas funcionalidades a los fondos (por ejemplo, objetos animados y capa con efecto "overlay" entre otras cosas).

Aún así, hay algo que me resulta interesante contar acerca de la dinámica de trabajo que estoy teniendo.

Tal vez hayan notado en la animación de la entrada "Profundizando un poco en el gameplay", que hay un pequeño número en la parte inferior, que va creciendo frame a frame. Bueno, ese número es simplemente un contador de frames... pero alguien se preguntó alguna vez "¿para qué?"... ¿que utilidad tiene eso para mí? Justamente... ese es el tema de esta entrada.

En mi framework, cuento con un sistema propio de "replays", lo cual me permite reproducir partidas enteras a mi antojo. Esto es particularmente útil a la hora de encontrar anomalías en el juego. ¿Para que utilizo un contador de frames entonces? La respuesta es muy simple: Para ir directo a los momentos cruciales de una partida. Un ejemplo: Digamos que yo estoy probando mi juego, y sucede algo extremadamente extraño, un personaje se comporta de una manera inesperada, etc... Si no hubiese grabado un replay, no podría ver con exactitud lo que pasó, por tanto tendría que comenzar a suponer muchos casos que pudieron generar dicha anomalía... en cambio, al contar con replays, cada vez que veo una anomalía o simplemente algo "sospechoso", miro el frame en el que estaba... y reproduzco el último replay guardado unos frames antes del momento en el que detecté algo (básicamente, hago que mi framework avance los frames anteriores rápidamente y vaya directo al frame que interesa). De esta forma puedo ver varias veces (o incluso debugear) casos en los que se producen anomalías (muchos de esos casos, por suerte, fueron solo sospechas).

Debo aclarar también, que estos "replays", son más precisamente "input replays", osea que la información que guardan, es solo el input de cada frame, teclado, mouse y joysticks. De esta forma, su peso es bastante ligero... puedo correr el juego desde el principio en un modo especial, que en lugar de obtener el input desde los dispositivos reales, lo obtenga desde el replay mismo, reproduciendo exactamente lo sucedido. Esta técnica es muy usada en emuladores que graban partidas enteras, y yo creo que es prácticamente esencial a la hora de programar videojuegos... además, su implementación es muy sencilla siempre que se haga sobre un framework propio.

Trabajando en el editor de niveles

   Esta semana estuve trabajando en el editor de niveles... pero no en el de la física ni la parte gráfica, sinó en el editor de "la parte jugable del nivel", osea, las oleadas de enemigos y posicionamiento de objetos.

   Tuve muchas dudas a la hora de decidir como hacerlo, dado que existen muchísimas maneras, y si seguía pensando en todas las posibilidades de cosas que "me gustaría que puedan ocurrir en un nivel"... no lo iba a terminar nunca. Así que me decidí por un modelo sencillo pero medianamente fácil de extender.

   También estuve trabajando un poco más la AI de los personajes con el fin de mejorar la experiencia del juego.

   Pronto planeo seguir avanzando en el diseño de personajes... crear más enemigos, etc, pero estos días estuve implementando muchas cosas técnicas que... si bien, puede que no den mucho contenido interesante a este blog... es algo muy necesario y es en lo que estuve trabajando esta última semana. =)

Un poco sobre los editores personalizados

   Hoy voy a mostrarles varios editores que hice y estoy usando en el desarrollo de  Fight Against Mutant Revenge.

   Una particularidad de los editores que mostraré a continuación, es que son todos "ingame", es decir, se ejecutan en el juego mismo. De esa manera, me permiten ver los resultados en tiempo real.

Editor de física de escenario

   Este editor es muy simple, pero muy útil, dado que me permite definir los relieves y posiciones de todo un escenario. Es bastante básico, pero tiene todo lo que necesito para definir la forma de cada zona.

Editor de fondos

   Este editor es un poco más complejo, y me permite armar una especie de "collage", usando capas, cada una con varias imágenes, pudiendo cambiar parámetros tales como color, blend, parallax y otros más.

Editor de script

   Como dije hace un tiempo, estoy usando un lenguaje de script propio ("sebascript"), principalmente para definir cosas básicas del juego. Muchas veces también es útil cambiar cosas mientras el juego está corriendo. Para hacerlo de forma más amena, uso un editor propio de mi script (con coloreado de sintaxis y todo). Tal vez, este editor no sea tan indispensable como los otros, pero es bastante más útil de lo que parece a simple vista (sobre todo a la hora de calibrar parámetros gameplay).

   Todos estos editores funcionan solamente con teclado, simplemente porque me parece más simple y más preciso que sea de esa forma. Yo soy de los que opinan que hacer videojuegos es un arte, y de la misma forma que para dibujar usamos programas hechos a medida, como photoshop... creo que también en lo posible es mejor usar programas que se ajusten a nuestras necesidades, para ahorrarnos bastante trabajo tedioso y así poder concentrarnos en lo más importante de una forma amena.

   Actualmente existen muchas herramientas que ofrecen soluciones genéricas, pero yo creo firmemente, que la mejor herramienta suele ser aquella que está definida por y para uno mismo, porque además, se puede ir ajustando según nuevas necesidades que se vayan creando en el desarrollo mismo de un juego.

Hacer juegos lleva tiempo

   Si alguien pasa por mi blog personal, notará que ya no lo actualizo con frecuencia... esto se debe a una razón muy sencilla: "Hacer ciertos juegos, puede llevar mucho tiempo" (incluso mas si los desarrollas solo). En pocas palabras: si yo, en esta etapa de mi vida, actualizara mi blog solo cuando termino un juego... pasaría años sin dar signos de vida. (De hecho, es justamente lo que está sucediendo.)

   Por otra parte, en estos últimos años he creado muchas cosas: mi propio lenguaje de script, un editor de animaciones, un editor de niveles, un framework multiplataforma, un editor de texto in-game, solo por nombrar algunos. Se puede decir que estas cosas nunca "vieron la luz", pero no por eso son menos importantes. (Creo que cuando uno apuesta por hacer juegos "no tan simples", utilizar herramientas personalizadas es esencial.) Lo cierto es que el tiempo es finito y desarrollando herramientas, prácticamente dejé a un lado la creación de juegos pequeños para dar lugar al desarrollo de un juego mayor. Y es ese el motivo de esta entrada. Porque a partir de eso, es cuando la tarea de desarrollar un juego comienza a extenderse en el tiempo.

   Me gustaría contarles que hace poco más de un año, estoy desarrollando (no continuamente) un juego del género Beat'em up. Aún me queda mucho trabajo por delante pero el juego me está gustando mucho, por eso, tomé la decisión de publicar noticias sobre el desarrollo, explicando aspectos de la programación y el diseño, mostrando imágenes del juego, animaciones, personajes, fondos y tal vez incluso algunas músicas.

   Espero que a muchos de ustedes les sea ameno y les resulte entretenido acompañarme en esta aventura!