Joined! NeoParty es un videojuego de fiesta para múltiples jugadores desarrollado en Unity como Trabajo de Fin de Grado del grado en Diseño y Desarrollo de Videojuegos. Lo que lo diferencia: los controladores son físicos, diseñados en Fusion 360 y programados desde cero con Arduino IDE.
El objetivo era explorar hasta qué punto el hardware puede cambiar la experiencia de juego. En lugar de un mando estándar, cada jugador sostiene un controlador dedicado que responde a su mecánica específica — cambiando completamente la forma en que se percibe y juega cada minigame.
🏆 El proyecto tuvo la oportunidad de estar presente en un stand del SAGA 2025, una feria catalana de videojuegos, gracias al apoyo de la Xarxa Accescat. También di una charla sobre el proceso de desarrollo del proyecto.
Tráiler oficial
Momento de la charla
Momento de la charla
Stand en SAGA 2025
Stand en SAGA 2025
Gente probando NeoParty
Gente probando NeoParty
Decisiones de arquitectura y los sistemas que dan vida al proyecto.
Sistema de comunicación serial entre los controladores Arduino y Unity. Cada controlador envía eventos en tiempo real que Unity procesa y traduce a inputs de gameplay, con latencia mínima para no romper el game feel.
Arquitectura modular que permite añadir minigames de forma independiente. Cada minigame es una escena autocontenida con su propia lógica, reglas y condición de victoria, cargada y descargada dinámicamente.
Pipeline completo de hardware: modelado en Fusion 360, impresión 3D, ensamblaje de componentes electrónicos (botones, joysticks, sensores) y programación del firmware en Arduino IDE.
Las fases del proyecto: desde la idea hasta el resultado final.
01 — Concepto
El punto de partida fue una pregunta: ¿puede el hardware cambiar fundamentalmente cómo se siente un juego? Empecé explorando referencias de juegos de fiesta con periféricos (Buzz! Juniors, 1-2-Switch) y decidí que el TFG tenía que demostrar eso de forma tangible.
02 — Prototipado hardware
Antes de tocar Unity, el reto era conseguir que un Arduino enviara datos a Unity de forma estable. El primer prototipo era una caja de cartón con un botón. Cuando funcionó la comunicación serial, supe que el proyecto era viable.
03 — Diseño de minigames
Cada minigame se diseñó pensando en qué podía hacer el controlador, no al revés. Eso implicó iterar mucho: algunas mecánicas que parecían obvias no eran divertidas con el hardware físico y hubo que descartarlas.
04 — SAGA 2025
Presentar el proyecto en SAGA fue el mayor test de usuario posible. Ver a gente que nunca había tocado el juego coger los controladores y entender cómo usarlos en segundos validó muchas de las decisiones de diseño.
Los obstáculos más interesantes del proyecto y cómo los resolví.
La comunicación serial entre Arduino y Unity introducía latencia variable que rompía el game feel en minigames de reacción rápida.
Implementé un buffer de eventos en el lado Unity y ajusté el baudrate y la frecuencia de polling hasta conseguir una latencia consistente por debajo de los 16ms — imperceptible para el jugador.
Los controladores físicos diferían ligeramente entre unidades (tolerancias de impresión, resistencias de botones) lo que hacía que la misma acción se registrara diferente en cada mando.
Añadí una capa de calibración en el firmware de Arduino que normaliza los valores de entrada por controlador, y expuse esos parámetros al editor de Unity para ajuste fino.
Trabajar con hardware físico obliga a pensar en el fallo como algo normal: los componentes se rompen, las conexiones fallan. Diseñar con eso en mente desde el principio ahorra mucho tiempo.
El game feel en juegos de party game es casi más importante que las reglas. Una mecánica mediocre con buen juice se siente bien; una mecánica brillante con mala respuesta se siente horrible.
Presentar en SAGA me enseñó más sobre UX en 2 días que meses de testeo propio. El primer contacto de un jugador nuevo con el proyecto es irremplazable.