Mario Bros (Java Engine)
Un motor de juego en Java para Mario Bros desarrollado desde cero, aplicando concurrencia multihilo y patrones de diseño avanzados para lograr un código altamente extensible y limpio.
Recreación del clásico Super Mario Bros implementado en Java 17 con Swing. El proyecto destaca por la construcción de un motor físico y de colisiones propio estructurado bajo arquitectura MVC. Emplea concurrencia multihilo para separar el bucle del juego (game loop) del renderizado de la UI, y aplica patrones de diseño de nivel empresarial — como State, Visitor y Observer — para lograr desacoplamiento total entre la lógica del juego y los assets gráficos portables.
Desarrollado como proyecto integrador para la materia Tecnología de la Programación (TDP), cumpliendo con estándares de diseño orientado a objetos, entrega continua y documentación técnica de arquitectura.
Gameplay: movimiento, saltos, bolas de fuego y colisiones con enemigos.
Ingeniería de software
Tres pilares que sacan a este proyecto del molde de "juego de facultad".
Arquitectura Desacoplada (MVC + Observer)
La física del juego, las velocidades, aceleraciones y coordenadas de los enemigos no conocen la interfaz gráfica. Todo ocurre en un modelo lógico puro. Mediante el patrón Observer, los componentes visuales de Swing reaccionan a los cambios físicos actualizando los elementos gráficos del canvas en tiempo real, garantizando un acoplamiento mínimo.
Motor de Colisiones Limpio (Visitor & Double Dispatch)
Resolver colisiones en juegos suele llevar a cadenas infinitas de condicionales if (entidad instanceof Enemigo). En este motor se implementó el patrón Visitor con Doble Despacho. La interacción — Mario cayendo sobre un Goomba, o chocando con un hongo — se resuelve polimórficamente a nivel de compilador, eliminando el acoplamiento rígido y permitiendo agregar nuevas entidades fácilmente.
Físicas Fluidas y Multihilo
Para evitar parpadeos o congelamientos en la pantalla, el motor separa las físicas lógicas en múltiples hilos independientes (ManagerMovimientoMario, ManagerMovimientoEnemigos, ManagerMovimientoBolaDeFuego). Esto garantiza una tasa de refresco constante y un gameplay suave independientemente de la carga de procesamiento.
Skins Intercambiables (Abstract Factory)
Los assets gráficos están totalmente desacoplados de la lógica del juego. Un Abstract Factory permite alternar entre modo clásico (NES) y modo moderno sin tocar una sola línea de la física ni de las reglas del juego.
Aprendizajes y desafíos
Portabilidad de recursos y configuración
El desafío
El acceso directo al disco local para leer niveles y rankings rompía apenas se ejecutaba el juego en un entorno distinto al de desarrollo.
La solución
Refactorización completa del motor de lectura de niveles y rankings: se reemplazó el acceso directo al disco por carga por Classpath de recursos dinámicos. El sistema detecta si está en entorno de desarrollo o en producción y lee/escribe rankings de forma segura, permitiendo distribuir el juego como un único .jar ejecutable e independiente del sistema operativo.
Ficha técnica
Cómo está construido
Programación orientada a objetos avanzada, con diseño centrado en patrones desde el día uno.
Interfaz gráfica y renderizado 2D con Graphics2D, desacoplados del modelo lógico del juego.
Thread y Runnable para las físicas del juego, con el Event Dispatch Thread (EDT) de Swing completamente aislado del game loop.
MVC, State, Visitor (Double Dispatch), Observer y Abstract Factory, combinados para lograr un motor extensible y desacoplado.
Carga portable de recursos vía getResourceAsStream, permitiendo distribuir el juego como un único .jar independiente del sistema operativo.
¿Querés ver el código completo?
Todo el motor está en GitHub, con su arquitectura a la vista.
Repositorio público con el código fuente completo: patrones de diseño, managers de movimiento y motor de colisiones.