David Gutiérrez

Gameplay Programmer & Designer

dgutierrezn98@gmail.com

10 Second Boss Fight

Información del juego Game Information

Rol: Diseño y programación Tiempo en el proyecto: 1 día Género: Incremental Motor: Unity Plataformas: Windows
Role: Design & Programming Time spent on project:: 1 day Genre: Incremental Engine: Unity Platforms: Windows

Proceso de Creación Development Process

01. La idea 01. The Idea

El punto de partida fue un incremental centrado en una única pelea: un boss con muchísima vida al que derrotar mandando héroes desechables uno detrás de otro. El loop se definió antes de escribir ninguna línea de código:

  • Combate totalmente automático: el jugador no controla al héroe, solo observa.
  • Mejoras permanentes, sin prestigio ni reseteo de progreso.
  • Un final concreto: derrotar al boss termina la partida.

Al conocerse el tema de la jam, Count Down, el encaje fue directo: el temporizador de 10 segundos de cada héroe es la cuenta atrás central del juego.

The starting point was an incremental game built around a single fight: a boss with a huge amount of health, defeated by sending disposable heroes one after another. The loop was defined before writing a single line of code:

  • Fully automatic combat: the player doesn't control the hero, only watches.
  • Permanent upgrades, no prestige or reset system.
  • A concrete ending: defeating the boss finishes the run.

Once the jam theme was announced, Count Down, the fit was immediate: each hero's 10-second timer is the game's central countdown.

02. Diseño de sistemas 02. Systems Design

Con el combate automático, todo el peso jugable recae en la tienda entre rondas. Se definieron mejoras con funciones distintas para que no fueran todas "+daño": daño básico, daño mayor, tiempo de combate extra y un multiplicador de monedas.

El coste de cada mejora escala de forma exponencial, y la duración total de la partida (15-30 minutos) se ajustó jugando directamente en vez de calculando, la herramienta de balance más rápida con el tiempo disponible.

With combat fully automatic, all the gameplay weight falls on the shop between runs. Upgrades were designed with distinct roles so they weren't all just "+damage": base damage, heavy damage, extra combat time, and a coin multiplier.

Each upgrade's cost scales exponentially, and the target run length (15-30 minutes) was tuned by playtesting directly rather than calculating it, the fastest balancing tool available given the time constraints.

03. Implementación 03. Implementation

La arquitectura se resolvió con una máquina de estados simple gestionada desde un único GameManager, con paneles de UI activándose y desactivándose según el estado en vez de usar varias escenas.

Durante el desarrollo aparecieron varios problemas que se resolvieron sobre la marcha:

  • Precisión de floats: restar el daño directamente de una vida muy alta acumulaba errores de redondeo. Se resolvió calculando la vida como una única resta desde el valor al inicio de la ronda.
  •             
    private float bossHealthAtRunStart;
    
    void StartCombat()
    {
        // se guarda la vida al inicio de la ronda, no se sigue restando sobre el valor grande
        bossHealthAtRunStart = bossCurrentHealth;
        damageDealtThisRun = 0f;
        // ...
    }
    
    void DealHit()
    {
        damageDealtThisRun += heroDamage;
    
        // Antes: bossCurrentHealth -= dmgTick;  → acumulaba error de redondeo en cada resta sobre un valor muy alto
        // Después: una única resta desde el valor guardado al inicio de la ronda
        bossCurrentHealth = bossHealthAtRunStart - damageDealtThisRun;
    
        UpdateHealthUI();
    }
              
  • Golpes discretos: el daño pasó de aplicarse por frame a golpes espaciados en el tiempo, necesario para el balance y para enganchar feedback visual.
  • ScriptableObjects persistentes: los niveles de mejora no se reseteaban solos entre partidas, al vivir en assets del proyecto y no en la escena.

The architecture was built around a simple state machine managed from a single GameManager, with UI panels toggling on and off depending on the state instead of using multiple scenes.

A few problems came up during development and were solved on the fly:

  • Float precision: subtracting damage directly from a very high health value accumulated rounding errors. Solved by calculating health as a single subtraction from the value at the start of the run.
  • Discrete hits: damage moved from applying every frame to timed, spaced-out hits, needed both for balance and for hooking up visual feedback.
  • Persistent ScriptableObjects: upgrade levels didn't reset on their own between playthroughs, since they live in project assets rather than scene instances.

04. Arte y humor 04. Art & Humor

Con los recursos visuales limitados a un único sprite de personaje, la limitación se convirtió en parte del diseño narrativo: todos los héroes pertenecen a la misma familia, generándose con un nombre y un grado de parentesco al azar, con un chiste ocasional sobre lo idénticas que son todas entre sí.

With visual resources limited to a single character sprite, the constraint became part of the narrative design: every hero belongs to the same family, generated with a random name and degree of kinship, with an occasional joke about how identical they all look.

05. Cierre del jam 05. Wrapping Up the Jam

El tramo final se completó con poco tiempo de margen. La prioridad fue confirmar que el proyecto compilaba, generar el build y subirlo a itch.io antes que perseguir cualquier pulido adicional. El resultado incluye el loop completo jugable, sistema de mejoras, nombres generados y pantalla de victoria, sin efectos de sonido ni juice visual, que quedaron fuera por el plazo.

The final stretch was completed with very little time to spare. The priority was confirming the project compiled, producing the build, and uploading it to itch.io rather than chasing extra polish. The result includes the full playable loop, upgrade system, generated names, and a victory screen, without sound effects or visual juice, which didn't make it in time.

06. Próximos pasos 06. Next Steps

  • Más variedad de mejoras y una curva de progresión más larga.
  • Sonido y feedback visual: números de daño flotantes, screen shake, reacciones del boss.
  • Contenido posible tras la victoria, más allá del final único actual.
  • More upgrade variety and a longer progression curve.
  • Sound and visual feedback: floating damage numbers, screen shake, boss reactions.
  • Possible content after the victory, beyond the current single ending.