Teoria del Engine

Muchas veces, al crear nuestros juegos queremos que sean lo más completo posible, tanto para nosotros mismos sentirnos satisfechos como para el público dirigido, ya que es muy gratificante cuando hacemos un buen trabajo y nos echan flores (a quién no le gusta eso? xD). Por ello buena parte de los proyectos prometedores, aparte de lucir gráficos propios, bonitos y elegantes (y algunos música propia también), además deciden implantar los archiconocidos minijuegos, sistemas de combate únicos, menús eyecandy, etc. Todo esto enblogando la idea de implementación de engines. Quizá muchos se sienten ya familiarizados con la realización de éstos (sobretodo los que saben programar en lenguaje real), pero todavía hay gente que escucha la palabra 'engine' y se sienten atravesados por 500 espadas. La idea aquí es mostrar que un engine, por monstruoso que parezca, si es "terrenal" (digamos, nada de inteligencia artificial ni similares >.> ), es factible hacerlo.

Un engine, como su palabra lo dice (motor), es un conjunto de instrucciones cuya finalidad es realizar una acción determinada. A grandes rasgos se podría ver como el cerebro del cuerpo o el procesador de un computador, puesto que el engine es la base de dicha acción.
Como me preguntaron por ahí, los engines no se baja como un script, sino que es, usando las funciones básicas de los rpg makers, poder hacer un proceso mayor. Un ejemplo de ellos puede ser desde el engine para abrir un cofre (estrictamente eso sí sería un engine, aunque parezca una estupidez xD) hasta los omnipotentes SBP.

Así como una mesa se compone de 4 patas y una cubierta, cuya unión y posicionamiento adecuado forma una mesa, un engine se compone de piezas más pequeñas. Pero para ello veamos una definición importante:

Algoritmo: Un algoritmo es un conjunto finito de instrucciones o pasos que sirven para ejecutar una tarea y/o resolver un problema. De un modo más formal, un algoritmo es una secuencia finita de operaciones realizables, no ambiguas, cuya ejecución da una solución de un problema en un tiempo finito.
(Fuente: Wikipedia [qué esperaban? ¬¬])

¿En qué se relaciona con lo anterior? Pues básicamente en que los engines se tratan por pedazos, estos pedazos representarán un problema, y lo que el creador del engine debe hacer es resolver este problema paso por paso hasta que el problema esté solucionado por completo. De la misma manera, un carpintero no hace las 4 patas y la cubierta y arma la mesa todo al mismo tiempo, ya que sería muy trabajoso y difícil. Mejor por pedazos, pata por pata, luego la cubierta, luego se unen los componentes, y tenemos una linda y hermosa mesa. ¿See?. Si aún no se entiende, veamos un ejemplo.

Por ejemplo: Quiero hacer que al pulsar el enter el prota lance una pelota que si impacta a algún chara, me de 20 de exp (basado en rm2k3)

¿Cómo se resuelve?
Vamos a ponerlo de la siguiente manera:
- Lanzamiento de la pelota
- Trayectoria de la pelota
- Impacto
- Bono

El lanzamiento de la pelota es el que verifica que la condición de lanzamiento se efectúe para poder llevar a cabo la acción.
- Algoritmos para resolver el problema: Recibir tecla, condición si la tecla es la correcta, lanzar pelota.

La trayectoria de la pelota es el movimiento de la pelota hacia el objetivo
- Algoritmos para resolver el problema: condición hacia dónde mira el chara, mover pelota, impactar.

El impacto verifica que la pelota haya dado a su objetivo
- Algoritmos para resolver el problema: obtener coordenadas x,y de la pelota, obtener coordenadas x,y de los objetivos, condición de comparación si algún x,y coincide con el de la pelota, obtener bono

El bono es le bonificación que se obtiene al impactar a la pelota
- Algoritmos para resolver el problema: sumar 20 experiencia

¡Listo! Ahí tenemos un engine sencillito. Ahora podríamos transformarlo a un minijuego, en el que tengas por ejemplo que lanzar pelotas a unas latas bajo un tiempo determinado, y ya hay un minijuego listo para incluir en el juego completo (recuerda dar gracias al Administrador por la idea xDDD)

Como se puede ver, el hecho de separar el problema hace que las cosas sean mucho más sencillas y más entendibles (como nota, es la forma que usan los científicos para resolver experimentos, y es un postulado de Descartes "separar las cosas hasta sus unidades más simples"...bueno, en fin xD)

Ahora, si queremos tener un engine óptimo, según yo, hay que considerar 3 aspectos que son fundamentales:

- Separar el engine en partes más pequeñas: Lo dicho arriba. Se hace la vida mucho más fácil cuando los problemas son más pequeños (relaciones con la vida real es pura coincidencia >.> ). Luego sumas las soluciones y voilá!, el problema gigante está resuelto. De otra forma es un caos saber por dónde empezar.

- Usa todos los componentes que estén a mano: Este es un tanto obvio, pero lo menciono de todas maneras. No trates de economizar pasos ni recursos si no dan una mejora real, puede que te enredes más y acabes por no entender lo que hiciste. Si tienes 5000 interruptores/fases y 5000 variables, ¡ocúpalas! (sin derrochar), puede que algo te salga más sencillo con más recursos a costa de un poco más de memoria. Pero recuerda no usarlos inapropiadamente.
Lo otro: ¡los comentarios son tus amigos! Son muy útiles para saber qué demonios estás haciendo xDD

- Optimiza tu engine: Esto supongo yo que es para gente más experimentada, ya que requiere algo de experiencia (y puede que a más de algún pr0 se le pase en algún engine): trata de mejorar tu engine reemplazando pasos innecesarios, pues puede que algún pc viejo te lo agradezca . Por ejemplo, si tienes 3 condiciones que se excluyen entre sí (o sea, sólo una al mismo tiempo puede cumplirse), en vez de poner <> es mejor poner <> ¿la diferencia? Si la primera condición se cumple, no necesitará leer las otras dos puesto que obviamente no cumplirán la condición. Si analizamos mejor y peor caso, en la primera instancia tenemos mejor caso (sólo se cumple la primera condición): 3 lecturas, y peor caso (sólo se cumple la última condición): 3 lecturas también. En la segunda instancia, mejor caso: 1 lectura, y peor caso: 3 lecturas. Por lo tanto se obtiene una mejora en el mejor caso. Así se evita que el programa haga lecturas no necesarias, y por consiguiente, un ligero ahorro de memoria. Puede que en engines chicos no surta tanto efecto, pero cuando tienes muchas condiciones que necesitan verificarse repetitivamente, ayuda mucho.

[Como anécdota, les cuento que estaba haciendo un SBL, y no se me ocurría un algoritmo para comenzar los turnos, por lo que pregunté en los foros de hellsoft. Ahí un usuario me dio una solución, que era algo así como 'súmale a cada chara y enemigo un valor de velocidad, y el último que alcance será el primero (claro, porque el con más velocidad partiría primero); resetea las velocidades y hazlo de nuevo para los siguientes' (no era exactamente así pero ya no me acuerdo ). Bueno, la cosa es que lo probé y funcionaba bien, pero al principio de la batalla producía un lag considerable (además que cada turno tenía que hacer la verificación, porsi alguien hacía un hechizo que alterara velocidad), por lo que luego me cranié en optimizarlo, y en vez de sumarle a cada personaje, le sumé a una variable independiente +1 por cada loop (en un ciclo), y la primera velocidad que igualara, sería el último, luego la siguiente velocidad sería el penúltimo, y así...y fíjense que funcionó de maravilla...¡y desapareció el lag!]

Bueno, esos 3 puntos considero que hay que tomar para hacer un buen engine (el que quiere puede hacer igual un buen engine y pasarse esta guía por la zona no mencionable, igual se puede). Pareciera que en parte el punto 2 y 3 se contradijeran, pero lo que quise decir es "no ahorres componentes innecesariamente, pero tampoco abuses de ellos". Úsalos adecuadamente, total nadie se dará cuenta que usaste 5 variables más

Además, ensayo y error van a ser tus compañeros de trabajo. De hecho, es casi imposible (calculo yo que con probabilidad cercana a 0) que apenas termines un engine te funcione todo de perlas, ya que (casi) siempre se va a colar un bug que nos va a poner de mañas ¬¬*. En lo posible, trata de corregir los errores lo antes posible y no una vez que esté todo terminado, ya que mientras más grande sea el engine, puede que genere 'efectos secundarios' en otra parte, lo que será más trabajoso corregir.

Espero que les sirva como referencia para que se les quite el miedo a hacer engines, es cosa de meter mano noma' a los componentes, de hecho, con interruptores/fases, variables y condiciones/efectos tienen todo lo necesario para hacer el 'cerebro' del engine. Por cierto, esto de "teoría de engines" también es aplicable en rmxp con el lenguaje ruby, de hecho me basé en mi experiencia en ramos de programación de la universidad. Además, si no sabes programar, pero sabes hacer buenos engines, no creas que estás muy lejos para aprender programación de lenguajes.

Para finalizar, los temidos SBL no son tanto como parecen. Si lo dividen en los trozos adecuados, aparecen problemas que no son difíciles de resolver (tampoco voy a decir que son fáciles, pero con un poco de ingenio salen). Por ejemplo: selección de turnos, turno de héroes, cálculo de daño de héroes, turno de enemigos, selección de objetivo, ataque de enemigos, cálculo de daño de enemigos, condición de muerte de héroes, condición de muerte de enemigos, condición de derrota, condición de victoria. Si saben resolver esos problemas, ya tienen un SBL hecho (faltan detalles por afinar, como los estados x ej., pero eso ya queda a criterio de uds.