Entrevista a JOOKITOOZ: caídas y risas en el nacimiento de A-RED Walking Robot
Hoy tenemos la suerte de charlar con David Kampa, más conocido como Jookitooz, creador de A-RED Walking Robot. Antes que nada, queremos agradecerle el tiempo y la cercanía con la que ha compartido su experiencia como desarrollador indie.
Este título marca su debut en el sector y llega con una premisa tan simple como endiablada: controlar a un pequeño robot de cuerda que intenta caminar sin desplomarse en escenarios llenos de trampas y desafíos. Dentro de lo sencilla que parece la propuesta, nos encontramos con un juego difícil, en el que vamos a morir unas cuantas veces a lo largo del trayecto.
Y como él nos lo ha puesto complicado, nosotros también le lanzamos una buena batería de preguntas, que podríamos dividir en dos grandes bloques: unas más centradas en el proyecto y otras en su experiencia como desarrollador. Eso sí, quedaos hasta el final, porque nos ha dejado caer de lo que tratará su siguiente juego…
El reto de dar forma a A-Red
¿De dónde nace la idea de que caminar sea el núcleo del juego?
Llevo muchos años haciendo 3D para postproducción, y Edu, uno de mis amigos, cuando le expliqué que quería ponerme a hacer un juego me dio la idea de crear uno de un robot de cuerda que fuera por una mesa: controlar el típico juguete inestable.
Me pareció un juego que sería sencillo, aunque requeriría bastante cantidad de escenario. Me puse a ello pensando que tardaría relativamente poco… qué iluso.
¿Qué referentes tenías en mente al empezar con el proyecto?
Busqué referencias de robots a cuerda antiguos para inspirarme, pero todos tenían una estética un poco estirada. Al final acabé haciendo una versión un poco funko de esos primeros robots vintage.
¿Por qué un robot de cuerda y no otro tipo de personaje?
Bueno, al final la idea del juego es hacer un «simulador» de robot de juguete, así que tiré por ahí.
¿Cuánto tiempo te llevó desde el primer prototipo hasta tener algo jugable?
El prototipo del robot funcionando lo tuve en aproximadamente una semana. Después dije: “voy a hacer un poco de menú”, ¡y ahí tardé tres semanas! Este es mi primer juego y no tenía ni idea de toda la cantidad de cableado interno que tiene un juego y que el usuario no ve, por sencillo que sea.
La primera demo la colgué en Steam al cabo de un mes y medio, y después empecé con el material de marketing. Ahí me di cuenta de que debería hacer un Vertical Slice, así que rehice toda la demo para mostrar todas las mecánicas en una partida corta. Luego vinieron tráileres, imágenes de promo, etc. (odio hacer marketing…).
¿Qué aspecto fue el más difícil de ajustar: físicas, controles, niveles…?
Había bastantes cosas con dificultad, sobre todo técnica, pero la más difícil en cuestión de diseño fue el tema de las cámaras. Probé de todo: la primera versión era una cámara que siempre estaba en la misma posición y seguía al robot con el mismo encuadre. Funcionaba más o menos, pero era aburrida y a veces las perspectivas se complicaban.
Después probé a dejar una cámara libre, como en la mayoría de juegos 3D, en los que mueves la cámara con el ratón o con otras teclas. Pero el juego requiere demasiada precisión como para tener que ajustar la cámara: ahí te caías muchas veces más, además de que obligaba a tener casi todo el escenario cargado en el juego siempre.
Probé también con una cámara que orbitaba al robot y pasaba lo mismo que antes. Al final llegué a la solución de distintas cámaras scripteadas y olvidarse de controlar la cámara, lo que me daba la posibilidad de ajustar cada encuadre para cada zona y componer las escenas con lo que quería que se viera.
No encontré mejor solución y sé que es una de las cosas criticables del juego, pero necesitaba un punto intermedio que funcionara.
Otro punto duro fue el jetpack. Al ser un juego basado en físicas es difícil hacer un control amigable: por ejemplo, cuando el robot cae, si le aplico la misma fuerza siempre cuesta recuperar el vuelo. Así que en código hago que, cuando el robot está cayendo, se aplique el doble de fuerza hasta que empieza a subir, y ahí es más fácil controlar la altura.
También tiene el control de estabilización (rotar el robot adelante/atrás e izquierda/derecha). Para la versión normal eliminé la rotación izquierda/derecha porque a algunos testers les liaba que se girara el robot, cuando en realidad no hacía falta para completar el juego. Lo dejé en la versión difícil, que también te da más posibilidades de control.
¿Cómo equilibraste el reto entre frustración y diversión?
A-RED es un juego que, desde el principio, trataba de caerse mucho (mucho más que ahora). Al inicio puse pocos checkpoints y muy controlados: debías hacerlo todo bien para llegar al siguiente.
Los comentarios de algunos testers (casi todos amigos que venían a casa y yo observaba jugar sin explicar nada, lo cual es difícil para no morderse la lengua) me indicaron que debía poner más checkpoints y hacer una versión algo más fácil.
Le amplié los colliders de los pies, aumenté el peso del robot, di más tiempo con cada checkpoint, reduje el gasto de fuel del jetpack y las penalizaciones por disparo, pero sin pasarme. La idea del juego sigue siendo la fragilidad del robot: con A-RED se pueden hacer cosas locas, pero el control es delicado.
Uno de los testers que más rápido pilló lo del jetpack fue LordOkami, que sabe pilotar drones y me superó mi speedrun de la demo.
¿Cómo gestionaste los límites de tiempo y recursos siendo un proyecto indie?
Pues los gestioné fatal, la verdad. He hecho el juego tirando de ahorros, y se ha alargado más del doble de lo que yo imaginaba al principio. Pero como estoy solo, tampoco tenía que ir pagando sueldos a nadie, solo sobrevivir yo.
JOOKITOOZ, la persona detras del simpatico robot
¿Trabajaste solo o tuviste colaboradores puntuales?
Hice todo el juego solo excepto la música, que es de Atsushi Moriya (DJ Guinzy). Y para el rodaje de la cinemática de intro me ayudó Edu, el amigo que me dio la idea, y Javi, que me dejaron usar su impresora 3D y su estudio para grabar allí.
¿Qué parte del desarrollo has disfrutado más: prototipado, diseño, programación…?
Pues no sabría decirte, me ha gustado prácticamente todo. Sobre todo me he quedado muy pillado al ponerme a programar cosas que necesitaba. Vengo de 25 años de hacer 3D y en esos programas la programación se usa muy poco, y muchas veces echaba en falta herramientas o pequeñas utilidades que, al desarrollar en un motor de videojuegos, puedes crear tú mismo.
He disfrutado con todo excepto con dos cosas: hacer los menús y preparar material de marketing. Eso me ha dado más sufrimiento que otra cosa…
¿Hubo momentos en que pensaste abandonar el proyecto?
No pensé en abandonarlo ni casi he tenido bajones. La verdad es que, después de tanto tiempo trabajando en 3D para publicidad (con tiempos supercortos y exigencia muy alta), poder trabajar a mi ritmo y a veces liarme con chorradas o haciendo herramientas me ha dado la vida.
¿Tienes alguna “manía de desarrollador” que creas que solo haces tú al crear videojuegos?
Pues ni idea. Como no he trabajado con otros desarrolladores no sé qué cosas hago yo que puedan ser raras, ¡pero seguro que hay!
¿Cómo recibes las críticas: te sirven para ajustar cosas o prefieres mantener tu visión original?
Hay que escucharlas: al final el juego no es para ti, es para los demás. El desarrollador tiene una visión muy viciada de su propio juego, y de tanto jugarlo pierdes la visión fresca, te sabes todos los trucos y caminos, etc.
Aunque también hay que filtrar y ver qué críticas son factibles de cambiar y si van a mejorar la experiencia. Yo intenté implementar casi todo lo que me dijeron, excepto cuando lo que pedían significaba que querían un juego distinto del que yo estaba haciendo.
¿Qué no volverías a hacer igual si volvieras a repetir el desarrollo?
Pues un montón de cosas, sobre todo de programación. Tengo algunos scripts básicos del juego con demasiadas líneas de código, cuando se podrían haber separado en varios scripts más fáciles de mantener.
¿Estás contento con los resultados?
Sí, la verdad es que estoy orgulloso de cómo ha quedado. Le he intentado pulir todos los flecos que he podido y creo que está bastante bien acabado. Evidentemente le cambiaría cosas hasta el infinito, pero hay que hacer el release en algún momento y cerrar el proyecto, que si no te puedes volver loco y no parar de añadir cosas.
¿Alguna cosa que nadie te pregunta, pero tienes ganas de contar?
Pues no mucho. Bueno, que la vida del solo dev es gratificante por la libertad que tienes, pero a la vez es un poco solitaria. A ratos echo de menos trabajar con más gente que te airee las ideas.
Hasta empecé a ir a los encuentros de los Barcelona Game Devs que se hacen una vez al mes para relacionarme un poco con otros frikis del videojuego, ¡y me iba muy bien para la cabeza!
Después de esta experiencia ¿Habrá futuros proyectos?
Sí, ya estoy con el prototipo del siguiente juego. Por ahora es un título relajante de puzles en el que controlas un cubo que cambia de color. La idea es hacer un juego corto que pueda sacar a final de año.
Al terminar la entrevista, solo podemos agradecer a JOOKITOOZ la sinceridad y el tiempo que nos ha dedicado. A-RED Walking Robot es un debut que demuestra hasta dónde puede llegar la creatividad cuando se mezcla con paciencia y cariño. Le deseamos lo mejor en esta aventura y estaremos atentos a sus próximos proyectos… que, por lo que nos ha adelantado, no tardarán en llegar.
La entrada Entrevista a JOOKITOOZ: caídas y risas en el nacimiento de A-RED Walking Robot se publicó primero en DeVuego Blog.
from DeVuego Blog https://ift.tt/b7Fhq8R
via IFTTT
