Hoy en día, Ducklas es un hecho. No será famoso, pero su demo ya está subida en itch.io y en este mismo sitio web. Lo cual se hace más interesante sabiendo que, en sus inicios, la idea partió de un enfoque inadecuado.
Para explicar esto, debo remontarme a cinco años en el pasado, cuando comencé a incursionar en la industria con intenciones de convertirme en desarrollador profesional.
Los videojuegos siempre fueron una pasión personal desde mi más tierna infancia, pero pasé la mayor parte de mi vida viéndome a mí mismo como jugador, no como creador. En buena parte porque, en mi ignorancia, asumía que el desarrollo consistía puramente en programación, una disciplina que siempre me pareció difícil.
No fue hasta después de un cuarto de siglo de existencia que, finalmente, comprendí que el mundo del gaming es mucho más amplio que eso. La programación, por supuesto, es elemental, pero si hay algo que caracteriza al rubro de los videojuegos es su alto nivel de interdisciplinariedad.
Comencé a informarme. Estaba determinado a convertir mi pasión en una profesión, pero necesitaba saber cómo.
La programación, de entrada, estaba descartada para mí, y tampoco puedo decir que sea bueno en el arte. Una parte de mí entendía que debía haber algo más, un elemento conector, una teoría de fondo, pero no sabía qué. Y fue así que, en esta búsqueda, di con un concepto crucial del que poco se habla pero que es fundamental, uno que encajaba perfecto con mi forma de ser y mis capacidades: el game design.
Comencé a adentrarme en tema, y pronto comprendí que todos los juegos que más me gustaban tenían un diseño excelente. Siempre tuve una tendencia a preferir a Nintendo por sobre otras compañías, pero ahora entendía por qué. Detrás de todos ellos, estaba la figura de Shigeru Miyamoto, de quien, hoy en día, soy un gran admirador.
Estaba decidido: yo también quería ser diseñador y desarrollar juegos que otros pudieran disfrutar. Así que decidí dar el siguiente paso y sumergirme en el rubro formalmente.
Me anoté en un curso de game design de la UTN (la Universidad Tecnológica Nacional), que complementé con otro sobre narrativa para medios audiovisuales en la misma institución y con cursos de dibujo en Internet para transmitir mejor mis ideas. Aprendí sobre mecánicas, dinámicas y estéticas; sobre el equilibrio ideal entre narrativa, historia y hardware; sobre la tríada de esferas esenciales que componen la programación, el arte y el diseño; sobre la importancia de la diferenciación; y sobre el rol del game designer como eje conector entre todos estos fundamentos.
Como asignación final del curso, desarrollé mi primer GDD. Se trataba de un juego en 2.5D llamado Free, una aventura gráfica inspirada en Limbo e Inside, en el que había interactuar con elementos del background para resolver puzzles y poder avanzar en la historia. Por supuesto, aunque no lo supiese aún, estaba asentando las bases de lo que, mucho más tarde, sería Ducklas.
La idea de Free me resultaba interesante desde un punto de vista académico, pero no lo suficiente como para continuar desarrollándola después de terminados los cursos. Tenía muchas ganas de diseñar un juego, pero uno que fuese estéticamente entrañable, como aquellos que jugaba en los años 90. Quería que fuese visualmente atractivo, y para ello necesitaba una mascota.
¿Recuerdan que dije que Ducklas se originó con un enfoque inadecuado? Bueno, es verdad. Como admirador de Miyamoto, sé perfectamente que la concepción un juego, en rigor, debería partir de sus mecánicas. Pero en aquel momento estaba muy entusiasmado con mis capacidades de dibujo recién adquiridas, y las ganas de crear un personaje fueron más fuertes.
Siempre tuve una afición especial por los animales antropomorfos, y quería crear uno que no se sintiese ni repetido ni como uno más del montón. La idea de un pato humanoide empezó a resonar con fuerza en mi cabeza, y finalmente comencé a hacer bosquejos.
En un principio, mi personaje se llamaba Duckie, y su historia, orientada a un público más adulto, era muy distinta a lo que fue en su versión final.
Duckie vivía en el planeta Ducktooine, en la ciudad de Duckland (en vez de Ducktown), y debía salvar a su novia Duckota y a todos los pollitos del planeta luego de que una banda de rock terrícola llamada Piss los secuestrase para hacer tours intergalácticos y matarlos en vivo.
Duckie tenía un sidekick, el único patito que escapó de la captura y que, curiosamente, se llamaba Ducklas.
El juego estaba concebido como una especie de hack and slash en 2D con un modo cooperativo, pero no tenía mucho más definido que eso. Nuevamente, estaba cometiendo un error al pensar en la historia antes que en las mecánicas, y la idea pronto dejó de convencerme. Estaba claro que el enfoque debía ser distinto.
Retrocedí unos pasos. La idea del pato antropomorfo me gustaba, y el nombre de Ducklas terminó calando más que el de Duckie. Tenía la base de un personaje que no quería descartar, pero era hora de pensar seriamente en las mecánicas del juego si quería que fuese viable.
Comencé a repasar lo que había aprendido en la UTN y recordé la mecánica principal de Free, que me parecía lo suficientemente interesante; pero, esta vez, decidí darle una pequeña vuelta de tuerca: no solo podrían los objetos del background afectar a los del plano principal, sino que el personaje también podría teletransportarse entre dichos planos. De ahí el nombre de la mecánica principal, “Back & Forth”, haciendo alusión al background y el foreground.
A raíz de esto, y siguiendo un poco la línea de lo pensado para Free, se me ocurrió que el juego debía estar orientado a la resolución de puzzles, aunque sin dejar de lado enfrentamientos con enemigos y la acción característica de los side-scrollers en 2D. Pero, a diferencia de estos, no se podría saltar ni atacar directamente, lo que fomentaría la resolución de puzzles de manera estratégica. Aunque, por supuesto, Ducklas necesitaría defenderse de algún modo, y fue así como surgió la idea del escudo.
La idea de activar objetos también fue reciclada. Es una especie de adaptación de la interacción con objetos de las aventuras gráficas pero trasladada al nuevo género. Y, finalmente, se pensó también en el rodado para darle un poco más de dinamismo a la propuesta.
La base ya estaba hecha, y esta vez sí era momento de crear una narrativa que fuese funcional a las mecánicas. Esto derivó en la historia que aparece tanto en la demo como en el GDD final del juego.
Ahora bien, ¿por qué crear un GDD? Bueno, porque el juego debía ser correctamente transmitido si pretendía tener una mínima chance de que se desarrollase. Ya poseía una experiencia previa haciendo GDDs, pero sentía que lo visto en el curso no iba a ser suficiente. Necesitaba ver documentos reales hechos por compañías establecidas que hubiesen publicado sus juegos exitosamente.
Encontrar estos documentos en línea fue más difícil de lo que pensaba, pero terminé dando con la página de un exempleado de LucasArts que conservó muchísimos documentos de la antigua empresa y los subió a su sitio web para preservarlos. Allí pude leer los documentos originales de juegos que aprecio mucho, tales como Star Wars: Shadows of the Empire para la N64 o Sam & Max: Hit the Road.
Este último, con dibujos de Steve Purcell y un excelente humor autorreferencial, me inspiró mucho para hacer el de Ducklas. También catapultó la idea de crear un juego parodia con un personaje que rompiese la cuarta pared. Porque, en realidad, los procesos de creación de la historia y del documento no estuvieron tan divididos, sino que se entrelazaron fuertemente entre sí.
Cuando finalmente completé el documento, tenía una hermosa sensación de logro. Pero pronto me encontré pronto con un nuevo e inesperado problema: el temor a mostrarlo.
No era un temor al fracaso o a la mala recepción; por el contrario, siempre confié en el potencial de la idea. Mi miedo, en cambio, pasaba por creer que a alguien podría gustarle demasiado, a punto tal de querer apropiárselo.
Tuvo que transcurrir un tiempo para que comprendiese que, en el mundo indie, el mayor riesgo no es ser copiado, sino pasar desapercibido. Me costó aceptar esta idea, pero alguien que me ayudó mucho a entenderla fue Javier Brunet, de la incubadora santafesina The Rabbit Hole, quien dio un seminario gratuito en colaboración con la UTN en el que presentó a la empresa y explicó lo que hacían.
A él le mandé mi GDD para ver qué posibilidades había de encontrarle un publisher al proyecto. Con mucha inocencia, creía que esto, con un documento solo, sería suficiente. Javier me dio feedback, pero me dejó en claro que una idea en papel, por más buena que sea, sigue siendo simplemente eso: una idea. Me dijo que no podía avanzar mucho más hasta no tener una demo jugable, y me sugirió fuertemente perder el miedo y mostrarle el proyecto todo quien pudiese.
Acepté la sugerencia. Pero nuevamente, con mucha ignorancia de por medio, pretendía que grandes estudios internacionales de renombre se interesasen lo suficiente como para desarrollar el juego.
Le pregunté a muchísimas compañías de diferentes partes del mundo si podía enviarles el GDD para ver si les gustaba la propuesta, pero, a pesar de recibir algunas respuestas, ninguna aceptó ver el documento, por razones que más tarde se me hicieron obvias.
En este punto, decidí detenerme.
Comencé a pensar que, quizá, el GDD había sido un lindo ejercicio de imaginación que reservaría para mí mismo como algo anecdótico. “Tengo un juego diseñado en papel”, podría decirle a alguien en alguna que otra reunión. Pero no llegaría más lejos.
Pasé medio año con Ducklas en un tercer plano en mi cabeza, por momentos incluso olvidado. Pero un día me propuse intentarlo de nuevo, pensando que tendría mejor suerte si seguía insistiendo.
Mi modus operandi fue básicamente el mismo, solo que esta vez me enfoqué en estudios hispanoparlantes y en game designers individuales. Las respuestas fueron, mayormente, similares a las anteriores, solo que esta vez obtuve una explicación: los estudios y diseñadores profesionales no suelen ver propuestas ajenas por el simple hecho de que, de estar ellos trabajando en un proyecto propio similar al de una idea externa, pueden llegar a meterse en un problema legal. De ahí la negativa a querer revisarlo.
Pero hubo una excepción a la regla. Luciano Musella, de Whiteboard Games, estudio argentino responsable de I See Red, aceptó ver mi GDD y me dio feedback. Y no solo eso, sino que, además, tuvo la amabilidad de mostrarme el documento oficial del juego que ellos mismos habían desarrollado.
Me recomendó estudiar una carrera para tener chances de hacerlo realidad. Fue así que, con más de treinta años encima, comencé a estudiar desarrollo de videojuegos en la Da Vinci.
El primer cuatrimestre fue excelente. Intenté volcar la idea de Ducklas en todas las materias que me fue posible. Lo dibujé a mano, realicé una tira de nivel, lo animé con Dragon Bones e hice una pequeña demo con Construct 2 que incluía la primera batalla contra Birdie. Me fue muy bien, a punto tal de ganar media beca por buen promedio.
Para cuando comenzó el segundo cuatrimestre, estaba más motivado que nunca a convertir a Ducklas en realidad. Ahora que tenía algo más que un GDD para mostrar, seguía intentando presentar el prototipo a potenciales desarrolladores interesados, sabiendo que las chances de que lo aceptasen eran bajas.
Pero un día, inesperadamente, recibí la grata respuesta de un gigante de la industria.
Dave Grossman, co-diseñador de los dos primeros juegos de Monkey Island y Day of the Tentacle, entre otras aventuras gráficas emblemáticas, me confirmó que, tal como era de esperar, no podía ver mi GDD por cuestiones legales, pero simpatizó con mi situación e intercambiamos una serie de mails en los que me dio palabras de aliento, y en donde me habló de sus experiencias durante el proceso creativo.
Fueron palabras solamente. Pero, para mí, significaron mucho más de lo que un simple correo electrónico suele transmitir. Y, gracias a ellas, conseguí algo esencial en la búsqueda de todo sueño: convicción.
Comencé a ver trabajos de estudiantes de la Da Vinci por el canal de Discord de la institución. Me contacté con una estudiante que mostraba su pixel art para la tesis y, a partir de ella, el equipo creció hasta incluir a dos artistas, un programador, el músico y yo mismo como diseñador.
La demo de Ducklas había comenzado, oficialmente, su desarrollo.
No todo fue color de rosas, claro. En paralelo, comencé a tener una seria crisis académica.
El segundo cuatrimestre no me estaba gustando tanto como el primero, y noté que el programa de la carrera, de ese punto en adelante, se orientaba mucho más a lo técnico, con lo artístico en un segundo lugar y el game design relegado a un plano marginal.
Me pregunté a mí mismo “¿qué harías para desarrollar tu juego una vez que obtengas el título?”. Y mi propia respuesta fue “probablemente lo mismo que estás haciendo ahora”. Yo me había inscripto con la intención de convertir a Ducklas en una realidad; y, ahora que lo estaba haciendo, tuve que cuestionarme si valía la pena seguir estudiando.
Finalmente, decidí abandonar la carrera. Dejaré a criterio del lector decidir si fue lo correcto.
En cuanto al desarrollo, el mismo se extendió algo más de seis meses, dado que no había deadlines y el equipo estaba conformado mayormente por estudiantes que debían enfocarse en la cursada e incluso en sus tesis. Esto, afortunadamente, no era algo que me molestase; por el contrario, nos permitía trabajar sin presiones, tal como afirmaba Dave en su correo.
A mitad de camino, decidí crear NovarArts como proyecto paralelo, sabiendo que algún podría mostrar lo hecho en mi propio sitio web y usarlo como portfolio.
Finalmente, la demo de Ducklas vio la luz el 29 de diciembre del 2025. Hubo un tropiezo inicial al subirlo con errores de programación de los que no nos habíamos percatado antes y al querer ajustarlo al formato web, ya que, en un principio, comenzamos el desarrollo en Unity pensando en exportarlo como un ejecutable.
La recepción fue buena. Desde la incubadora, que conoce el proyecto desde que era tan solo un GDD y que probó también el prototipo hecho en Construct 2, notaron un avance enorme, pero aclararon que la demo aún está lejos de ser un vertical slice que pueda ser mostrado a publishers potenciales.
Este es el estado actual del proyecto. Aún falta mucho camino por recorrer, pero resulta interesante ver todo lo que hay detrás de un videojuego. Y eso que, en este caso, hablamos de una demo que dura apenas unos pocos minutos.
Ahora bien, ¿qué pasará a continuación?
Lamentablemente, el equipo de desarrollo original ya no está disponible, pero el proyecto seguirá adelante de todos modos. Los assets y el código serán reutilizados por nuevas personas interesadas en expandir el juego hasta convertirlo en un vertical slice propiamente dicho.
Pero esa será otra historia.