Un juego que hice después de más de 20 años gracias al vibe coding: Mirror Break Out
(mirror-breakout-web.vercel.app)En el verano de 2004, mientras pasaba mis últimos meses en el servicio militar, me puse a pensar qué podía hacer en mi tiempo libre y empecé a planear un juego. En ese entonces mi hermano estaba estudiando diseño gráfico para videojuegos, así que pensé que cuando me diera de baja sería buena idea crear algo juntos. (Ah... yo soy un simple estudiante de humanidades. Cero técnica.)
Como era un intento amateur, quise hacer algo pequeño y sencillo. Tomé como base el clásico juego de romper ladrillos (Arkanoid) y le agregué una nueva forma de enfrentamiento. Ya era un juego del que muchísima gente había sacado nuevas versiones, pero no parecía haber una hecha como la mía.
Cuando salí del ejército, reuní a mi hermano y a unos amigos suyos y armamos un equipo con mucha ambición, pero no duró mucho: cada quien tuvo sus propios asuntos y el equipo se deshizo muy pronto. Pensé que lo haría cuando hubiera otra oportunidad, pero esa oportunidad nunca volvió. Con el paso de los años, de vez en cuando me volvía a acordar mientras hacía vida laboral, y hasta en una época en la que intenté aprender un poco de Python lo puse como objetivo, pero para mí era una tarea demasiado difícil.
Así siguió pasando el tiempo, y más de 20 años después, el verano pasado, al terminar una reunión salimos a cenar juntos y los directores de las empresas con los que me había reunido empezaron a decir que ahora se podían hacer demasiadas cosas con IA y que todos querían volver a emprender. Ese día me motivé, regresé a casa por la noche e instalé Claude Code, del que tanto había oído hablar. Y dos horas después... ¡pam!
Mientras pensaba qué pedirle a Claude Code como primer proyecto, retomé la idea de hace 20 años y se la fui describiendo. Unas dos horas después, frente a mis ojos, el paddle y la pelota ya se movían y rompían ladrillos. Qué sensación tan electrizante fue esa. Ahora este tipo de testimonios ya abundan, así que seguro les resulta familiar, pero medio año después ya no puedo vivir sin Claude Code.
Desde entonces fui puliendo el juego poco a poco, y ahora por fin llegó a un nivel en el que al menos me atrevo a presentarlo como demo, así que me animé a publicarlo. ¡Y nada menos que en GeekNews, donde siempre solo leía sin comentar! En un principio lo imaginé como un juego competitivo para dos personas, pero la función multiusuario era una barrera demasiado alta para mí, así que lo hice en formato de duelo contra la computadora.
Para presentarlo brevemente:
- Es para computadora. Todavía no tiene soporte para móvil.
- Es un juego de romper ladrillos donde dos jugadores compiten en el mismo espacio, de espaldas entre sí. Gana quien destruya primero todos los ladrillos.
- Si dejas caer tu pelota, esta pasa al área del rival. Si el rival la deja caer, vuelve a ti.
- Incluye conceptos de física del mundo real como peso, impacto, aceleración e inercia. Es más difícil de lo que parece.
- Como es una versión demo, puedes seguir jugando reiniciando después de cada partida.
- Como en las salas de arcade de antes, si haces un récord puedes grabar tu nombre.
Si tuviera que escribir algunas lecciones del proceso de desarrollo:
- ¡Refactorizar! ¡Refactorizar! ¡Refactorizar!
- Entendí qué era eso de la refactorización del que tanto se habla, y hasta llegué a pensar que quizá existe algo llamado el infierno de la refactorización.
- Al principio, lleno de ilusiones y soñando con Battle.net, dividí funciones por todas partes y fui inflando el proyecto, pero terminé resetéandolo todo en medio de una avalancha de bugs; luego lo volví a dividir, lo volví a unir... Eso fue antes de que saliera Opus 4.5.
- Si incluso hacer algo tan pequeño implica todo esto, terminé desarrollando un gran respeto por quienes son programadores.
Por suerte, ahora ya entendí un poco mejor mis propios límites, y me convertí en alguien que divide el trabajo en partes pequeñas, crea documentos de flujo de trabajo y lleva con cuidado los logs de desarrollo y los commits de Git. Lo más valioso que saqué de todo esto es que ahora tengo muchísimas más ganas de intentar hacer cosas. Estoy pensando con empeño en crear por mi cuenta herramientas que necesito para mi trabajo.
Ahora mismo no sé bien qué hacer con este juego. En mi situación actual me cuesta dedicarme a desarrollarlo en serio, pero al mismo tiempo me da pena simplemente dejarlo guardado. Ojalá pueda convertirse en un juego que los niños disfruten mucho.
Siempre aprendo mucho de las noticias de GeekNews y las sigo con gratitud. Muchas gracias.
14 comentarios
El concepto es divertido, pero la sensación de control es muy mala. No me parece una buena idea aplicar inercia a los controles en un juego así. Creo que es un tema distinto de la dificultad.
Gracias por tu opinión. Revisé los puntos que mencionaste y reduje la inercia a la mitad para que sea un poco más fácil de controlar. Yo había priorizado el concepto físico que tenía en mente, pero esto me hizo pensar más en la jugabilidad y en cómo debería manejarse cuando hay colisiones. Voy a seguir corrigiéndolo. (Como he estado más ocupado con mi trabajo principal, tardé en reflejarlo.)
Quién será FURY... dejó una puntuación increíble.;;
En el mundo real existen conceptos físicos como peso, impacto, aceleración e inercia. Es más difícil de lo que parece.
Da la impresión de ser un comentario que deja ver una comprensión algo limitada de la física en los videojuegos, así que estaría bien pulirlo un poco.
Por favor, púlanlo ustedes mismos jaja, y no se hagan los importantes frente a alguien de humanidades.
Gracias por preocuparse por el corazón de alguien de humanidades. Jaja ^^
La razón por la que me resulta difícil ayudarte a pulir la redacción es que no he visto el código que hiciste, así que no sé de qué manera implementaste el motor de física.
Me disculpo por la parte en la que hice una observación no deseada.
Mucha gente promociona sus productos, pero a menudo los promocionan con IA o adjuntan explicaciones inapropiadas, así que dejo comentarios en esos casos. No era un comentario escrito para hacer enojar a nadie.
Gracias por el interés. Para nada me molestó. Siempre agradezco los consejos. Más bien, no entendí qué parte habría que corregir ni de qué manera, así que agradecería una explicación un poco más detallada.
Para explicar un poco más lo de haber aplicado física realista: por lo general, estos juegos suelen implementar solo una detección de colisiones y rebotes muy simples. Pero yo quería que, igual que en un pinball real, al chocar la pelota o los ladrillos se sintiera la energía del impacto según el peso y la velocidad reales, así que busqué y terminé usando Planck.js, que me pareció más preciso que una librería común para juegos. Hice que, cuando la pelota golpea un ladrillo, este se empuje y gire por el impacto. Además, en la configuración se pueden cambiar cosas como el peso de la pelota, el peso de los ladrillos, la atenuación de la energía de colisión y la resistencia, para que según la configuración se obtenga una experiencia distinta.
(Hay una configuración a la que yo llamo modo loco: si subes al máximo el peso de la pelota y bajas al mínimo el peso de los ladrillos, el juego se vuelve muy dinámico).
El código también está en GitHub.
https://github.com/gogodevelop2/mirror-breakout
Sí, para comentar,
primero, parece que dedicaron más esfuerzo al diseño de colisiones, al ajuste del coeficiente de restitución y otros aspectos.
Y, en particular, las colisiones terminan ocurriendo a partir de cálculos hechos con la masa y el coeficiente de restitución de cada objeto; pero si hablo de las partes que difieren de lo que buscaban,
en realidad, como cosas como la masa o la velocidad del
paddleo delbricksolo afectan al momentum de laball,en esencia, se acerca más a haber tomado inspiración de un modelo físico para
programar de forma distinta cada colisión entre la pelota y (los ladrillos, el paddle y la pared).
Por lo tanto, más que decir que es física realista, parece mejor explicarlo como que tomaron elementos de un motor de física para diseñar de manera dinámica las colisiones y los cambios de momentum.
En particular, como el proceso de colisión es poco realista y por eso cambia el momentum, aplicaron una corrección de velocidad; y eso, desde el punto de vista de la sensación de control, puede percibirse como algo oculto, o también como algo bastante poco amable para el jugador.
Para explicarlo de una manera un poco más sencilla,
se usaron fórmulas físicas y métodos de cálculo, pero en términos de resultado es un
modelo que no es realista, y se incluyeron muchos ajustes para bloquear de forma jugable los problemas que surgen en esas partes poco realistas (velocidad infinita, detención, control de dirección, etc.).
Muchas gracias por la explicación tan detallada. Me ayudó mucho a entenderlo. Como es la primera vez que intento hacer un juego, no conocía bien el mundo de la física de juegos ni el uso adecuado de la terminología, así que lo redacté de una manera que podía prestarse a malentendidos. Después de escuchar la explicación, creo que ahora entiendo un poco mejor con qué nivel evalúan los resultados quienes trabajan en esto profesionalmente. No pude encontrar cómo editar el texto principal... lo voy a revisar y lo corregiré. Gracias.
Gracias. Jaja, ¡yo también apoyaré las actividades de pasatiempo!