tengo un par de cosas que decir con respecto a catbox, y procedo a comentarlas a continuación.
cuando empecé a escribir el motor catbox, pensé que la mejor forma de enfrentar un motor planeado para escribir cualquier tipo de historia para un juego de plataformas era hacer algo lleno de, ehm, burocracia. esto es muy importante, porque es vital para entender algunos de los comentarios que voy a hacer luego.
catbox funciona, esencialmente, haciendo llamadas entre objetos. por ejemplo, el script que maneja el movimiento de personaje y el script que maneja las pulsaciones de teclas son dos scripts diferentes e independientes. ¿por qué? porque así puedo usar el mismo script de movimiento para todos los objetos que sean actores en el juego, ya sean el personaje principal, NPCs, enemigos, sidekicks y cuanta cosa se me ocurra. esto es muy agradable, porque ya que son scripts diferentes, puedo escribir diferentes scripts para mover actores con la misma batería de variables. el script que le da movimiento al personaje simplemente le cambia el valor a variables de verdadero a falso, entonces puedo escribir más scripts que le cambien el valor a esas mismas variables pero con otras condiciones, además de ser mucho más lógico que la orden de moverse a la derecha sea una variable con dos condiciones (verdadero y falso) a órdenes como moverse cierta cantidad de pixeles en cierta dirección. el problema es que esto es muy muy engorroso para hacer debugging: muchos scripts diferentes que funcionan en conjunto terminan siendo muy dificiles de manejar cuando algo falla, y hay que revisar script por script condición por condición qué es lo que no está funcionando. meh.
ahora estoy peleando con el sistema de diálogos. no se en dónde está fallando, pero la variable que hace perder el control del personaje por algún motivo no cambia, y no se si el error está en el script de las acciones del personaje, en el de pulsaciones de teclas para el personaje, en el de manejo básico del juego o en algún otro lado. es caótico, porque puedo hacer arreglos baratos y darle valores manualmente a la variable en lugar de un set de condiciones que decida cuándo quitarle y cuándo darle el control de nuevo al juego, pero eso sólo colaboraría a ensuciar el código y dejarlo ilegible. estaba usando un script que escribió un muy buen amigo dominicano por allá por el año 2004, y decidí reescribirlo con código propio. reduje el código de unos scripts larguisimos a algunos que no tienen más de 20 líneas. un logro, pero reescribirlo rompió algunas cosas, y en eso estoy, arreglando pedazos de código que ya no pegan bien. aprovecho de limpiar un poco el código, sintetizarlo y hacerlo más legible (en vez de if y elses, por ejemplo, ahora aprovecho que comparar valores entre variables o que se cumplan ciertas condiciones devuelve 1 o 0, true o false, entonces escribir variable=condicion ahorra de 6 o 5 líneas a una sola, hace el código más legible y mucho más mantenible a lo largo del tiempo, cosa que necesito si tengo una cantidad tan grande de scripts)
surge la pregunta ¿es necesario escribir un motor así? digo, si quiero hacer un juego, me ahorro mucho tiempo escribiendo un motor específico para ese juego, y es cierto: yo ya tengo un motor de plataformas bastante decente y los conocimientos suficientes como para escribir lo que se me venga en gana (mientras sea 2d y no use superficies), pero yo lo veo como un aporte a largo plazo. veran, los motores disponibles para game maker no son lo suficientemente buenos, o sea, yo encuentro que son demasiado específicos y localizados, funcionan más como ejemplos que como motores completos. cuando termine éste motor, quiero liberarlo y que sea un aporte a la comunidad, que sea un buen piso para que cualquiera escriba un juego de plataformas sin necesidad de escribir todo lo que necesita desde cero. el muro que evitará que el motor caiga en mal uso es que para hacer algo con el motor tienes que entenderlo. yo te entrego un sistema de objetos, uno de dialogos, otro de menus, otro de scripting de enemigos, pero para hacer algo tienes que, por lo menos, revisar los scripts y leer los comentarios.
estaba pensando en qué juego puedo hacer con el motor. mi forma de trabajo es, por un lado, diseñar los juegos sin pensar mucho en el motor, preocuparme de la historia y de la mecánica del juego a grandes rasgos. esto funciona cuando estás trabajando en juegos con un enfoque más narrativo y menos arcade. trabajando así no he terminado nada todavía (jujuju) pero he empezado hartas cosas. lo importante de los proyectos personales, por sobre terminarlos, es no abandonarlos nunca. uno de mis proyectos ya tiene 4 años y ha sufrido muchas transformaciones a lo largo del tiempo. lamentablemente perdí todo lo que había escrito sobre éste proyecto porque lo hice en los blogs de la CGM, instancia que desapareció. hay otro proyecto que se me ocurrió este año que me gusta mucho pero requiere mucho esfuerzo (y por qué no, capital humano) como para comenzar a escribirlo en serio. yo dibujo, pero no soy muy bueno haciendo diseño de personajes y bosquejos para ilustrar las ideas, y esto es infinitamente necesario para empezar con un trabajo en serio. el juego en cuestión me gusta mucho como idea. ninguno de estos dos proyectos es el que voy a hacer primero con éste motor, y para empezar, creo que voy a hacerlo con un proyecto que también se me ocurrió este año.
es básicamente un juego de aventura con vista lateral, como simon's quest o como adventure of link. es un juego de exploración en el sentido de pokémon más que en el sentido de metroid. la historia está situada en un universo paralelo futurista donde robots y humanos convivieron alguna vez en paz pero hoy mantienen una guerra, y el desarrollo de la historia está estructurada básicamente como una road movie, como un viaje largo lleno de anécdotas pequeñas no necesariamente vinculadas entre sí: uno llega a un pueblo al paso, conoce a los habitantes del pueblo, algo está sucediendo en el pueblo mismo o cerca de él, uno interviene, aprende algo nuevo y sigue su camino. a medida que el juego avanza, los sucesos son más relacionados con el núcleo de la historia, que es una forma de vida robot superior a la creada por el hombre, va descubriendo cosas, va encontrando gente que tiene los mismos objetivos que tu, ganas aliados, conoces a tus enemigos y entiendes sus motivos, etc. el juego estaría dividido en tres partes, la introducción, que funciona como una road movie y que debe ser principalmente entretenida sin ser sobreexigente, una segunda parte que funciona como si fuese megaman, con un número de "mazmorras" con jefes a derrotar y un final con tiempo en contra.
suena ambicioso porque lo es, pero todavía tengo que reescribir el motor base, y para cuando eso esté listo voy a estar en la universidad estudiando con personas que eventualmente puedo conocer y proponerles unirse a éste proyecto, que es básicamente lo que necesito. esto de ser un one man army no va conmigo.
edit: adivinen quién reescribió y modificó el motor de diálogos. pista: también fui yo.
tengo lo básico por ahora, todavía me falta implementar las líneas de texto que ejecutan código, marcadores y esas cosas. dado que ahora mi código del control de pulsaciones de teclas para el sistema de diálogos es bastante más claro que el que tenía anteriormente, no me cuesta nada pensar en un sistema de marcas para pausar el texto y cosas así. se me tiene que ocurrir una forma de que no escriba los caracteres que uso de marca (dejo anotado acá: puedo usar @, ^, ¨, ´, ¬ y | como marcas, y las marcas que necesito implementar que se me ocurren ahora son pausa c/botón y pausa temporal)
