Entiendo que el título puede sonar extraño, y claramente lo es: no era mi intención 🤣. Acompañame a este viaje que inició hace casi un mes, fruto de las necesidades de mis proyectos personales.
Desarrollar juegos será divertido, decían. La vas a pasar muy bien, decían.
Siempre estoy desarrollando un juego en mis tiempos libres, sea por incluirlo en una de mis clases o simplemente porque así le saco todo el potencial a la herramienta que estoy utilizando.
Eric Barone quería aprender C# y como excusa creó Stardew Valley. A mi me pasa lo mismo con cada lenguaje o tecnología con la que me enfrento: desarrollar un juego es el equivalente a dispararte el pie. Tres veces.
No se desesperen queridos/as lectores, en unos minutos me voy a poner serio. O no.
La cuestión es que aprendí muchísimo mediante esta técnica, y la sigo aplicando con éxito. El problema es que me lo tomé en serio.
Maldito Cookie Clicker
Esto no es una imagen que encontré por ahí: es mi partida actual, en el momento en el que estoy escribiendo este artículo.
Cookie Clicker es y será el mejor clicker incremental de la historia, sin discusión. Es un clásico que sigue en desarrollo continuo por nueve años.
Y también es un tipo de droga que no fue registrada porque nadie quiere admitir que no hay tratamiento alguno. Este es el resultado de unas 287 horas y contando. Por supuesto, la mayoría son en segundo plano, mientras hago mis cosas.
La cuestión es que decidí meterme en el género y crear mis propios clickers. La idea es innovar en una industria que no para de sacar ideas nuevas cada segundo, por lo cual va a ser un desafío interesante. Pero hablemos de la parte técnica.
Clon de Cookie Clicker
Antes de meterme en un proyecto gigante, quería ahorrarme las frustraciones y crear un MVP de un juego ya creado, el cual tenía algunas de las mecánicas principales que iba a implementar en mis propios proyectos.
Este es el resultado final! 💩
En mi cabeza sonaba mejor. Aún así, lo considero un proyecto bañado en oro, por eso del famoso efecto IKEA. Lo hice con amor, sudor y sangre.
También lo hice para ustedes, hermosa comunidad, y lo pueden clonar desde mi repositorio en GitHub!
Los motivos
Cuando nos juntamos con Fran para empezar a darle forma al primer proyecto que vamos a desarrollar, sorteamos varios engines como Unity y PyGame.
Pero nos encontramos con un problema fundamental: en ambos no teníamos tanta libertad para manejar el aspecto visual en un layout. En el caso de PyGame, los layouts en si no existen, es puro código y hay que acomodar cosas por axis. En el de Unity, tienen su propio sistema y una gestión un poco extraña de la UI. Además de que es un engine enorme para el tipo de juego que queríamos armar.
También Godot fue un motivo de conversación, pero Fran lo detesta por alguna razón que todavía no descubro. Aún así, en este engine existe un metalenguaje llamado GDScript, el cual es similar a Python; y no me convencía tampoco.
También probamos Tkinter y PyQT. El problema eran las animaciones, las cuales no ibamos a poder manejar como queríamos, conjunto de la optimización.
La presencia de Python en nuestro stack era importante porque lo tomamos como el lenguaje core del juego. En este punto, decidimos que Django funcionaría como un administrador y generador de un dataset en SQLite, el cual contendría una serie de tablas que vendrían a definir gran parte de las reglas de nuestro clicker.
Pero la parte frontend seguía siendo un tema complicado: hasta que se me ocurrió apuntar a web.
React fue mi primer opción
Antes que nada, quiero aclarar que jamás toqué React y tengo un gran rechazo a Javascript. Aún así, no estoy ciego, y veo como el mercado pide más desarrolladores React de los que pueden nacer en el mundo.
Además el paradigma reactivo y los videojuegos se llevan muy bien, dado que estos son un gran conjunto de eventos que interaccionan entre sí todo el tiempo.
Por otro lado, yo empecé desarrollando web, por lo cual tenía un roadmap mental de la dirección que debíamos tomar.
El plan
Antes de iniciar un proyecto, hay que armar un plan para entender los alcances y los pasos necesarios para progresar sin encontrar sorpresas muy grandes en el camino. Este era el plan:
- Aprender Javascript (Fran)
- Comprender React a fondo
- Usar Electron para generar un ejecutable
- Crear una cuenta de desarrollador en Steam
- Publicar en Steam
- Mantener este juego por unos 8 años
Con las bases del plan definidas, empezamos el viaje.
Etapa de aprendizaje y adopción
Voy a contar mi camino, y quizá en el futuro, Fran escriba un artículo sobre el suyo.
Como ya sabía Javascript, salté directamente a la librería de React. Miré muchos videos en YouTube, pero considero que aprendí mucho más con este:
Pude entender parte de su potencial; y armé algunos proyectos simples para asentar las bases. Luego investigué sobre Electron y empezaron los problemas.
Electron es la librería que permite generar un ejecutable en base a un proyecto web. El problema es que soporta una versión más antigua que no tiene este tipo de facilidades:
from algo import './un_archivo.js'
Entendí que la clave era cambiar las importaciones. Intenté hacerlo, pero el error persistía. Por supuesto, mucha gente había pasado por esto, y brindaban varias soluciones utilizando templates.
Decidí probar uno, pero me di cuenta que estaban en TypeScript. No conocía este lenguaje, así que tuvimos que agregarlo a nuestro plan y buscar cursos.
Me vi estas 8 horas de video en dos o tres días, y luego empecé a practicar en el editor Visual Studio Code. Al principio no me sentí muy cómodo con este lenguaje de programación (que en realidad es un superset de Javascript), pero luego de utilizarlo en un proyecto con React, me empezó a gustar.
Su fuerte tipado evita los desastres que se podían cometer en Javascript; al mismo tiempo ayuda al editor a entender cuáles son los atributos de un determinado tipo y también a advertir errores si estamos pasando valores erróneos.
Luego de la comprensión, llegó la unión de conceptos, y pude crear un proyecto con un template de Electron, Vite, TypeScript y React. Fue un Hello World, pero estaba feliz porque todo se había encastrado y funcionaba perfecto.
Conclusiones
Considero que este artículo me está quedando gigante, y voy a dejar el desarrollo en detalle del clon de Cookie Clicker para una segunda parte. No obstante, espero que les haya podido trasmitir mi experiencia en el camino del desarrollo y puedan tomarlo de ejemplo para sus emprendimientos.
Si les gustó, compartan, y déjenme un comentario, los leo!
Top comments (4)
La pregunta sería porque TS y no regular Js.
porque JS es un horror, su tipado dinamico te permite hacer cualquiera y eso te genera muchisimo código con resultados poco predecibles. Por suerte, se habla de que las prácticas en TS van a ser implementadas en el futuro en las próximas versiones de ECMAScript, o eso habia escuchado por ahí.
JS es un amor y TS es el horror. Pero bueno cada uno tiene sus gustos así como hay gente que prefiera la piña en la pizza y otros que no.
pero dame un argumento más solido sobre esto jaja