Cuando construyes un juego en JavaScript, llega un punto donde la lógica inicial ya no te alcanza. Pasar de jugar por vidas a jugar por victorias te obliga a repensar variables, condicionales y la forma en que actualizas el DOM. Si estás aprendiendo JavaScript con proyectos prácticos, este cambio te enseña a manipular arreglos, validar combinaciones y reflejar el estado del juego en HTML.

Por qué cambiar de vidas a victorias en la lógica del juego

El juego original funcionaba con un sistema de vidas en decremento: cada derrota restaba una vida hasta llegar a cero. Ahora la dinámica se invierte. Las victorias van en incremento y gana quien acumule más triunfos al final de la partida.

Este cambio no es solo cosmético. Implica reescribir validaciones, ajustar el HTML inicial y renombrar (o resignificar) funciones como revisarVidas, que pasa a comportarse más como una revisión de victorias.

¿Qué es la lógica de victorias en un juego JavaScript? Es un sistema donde cada acierto suma un punto al contador del jugador o del enemigo, en lugar de restar vidas. Gana quien tenga el número más alto cuando termina la secuencia de ataques.

Cómo declarar las variables de victorias en JavaScript

El primer paso es ir a la zona de variables globales y crear dos contadores nuevos. Ambos arrancan en cero porque nadie ha ganado todavía [01:58].

• victoriasJugador = 0 para llevar el conteo del jugador.
• victoriasEnemigo = 0 para el contador del oponente.
• Inicialización en cero porque la partida comienza sin triunfos acumulados.

Con estas dos variables ya puedes reemplazar el decremento de vidas por un incremento de victorias dentro de cada bloque condicional.

Cómo validar combinaciones de ataques con if y else if

La lógica de combate usa una cadena de if y else if que compara los ataques del jugador y del enemigo dentro de sus respectivos arreglos, accediendo por index [00:32].

Qué validaciones necesitas dentro de cada condicional

Cada bloque revisa una combinación específica entre los elementos de ambos arreglos:

• Si el ataque del jugador es igual al del enemigo, se declara empate.
• Si la combinación favorece al jugador (por ejemplo, fuego contra tierra, agua contra fuego, tierra contra agua), suma victoriasJugador++.
• Si ninguna condición se cumple, el else final asume que ganó el enemigo y ejecuta victoriasEnemigo++.

Dentro de cada bloque también se llama a una función que guarda los índices de ambos oponentes para poder mostrar después qué eligió cada uno.

Cómo actualizar el innerHTML al sumar una victoria

Antes el código hacía vidasEnemigo-- y luego pintaba ese valor en pantalla. Ahora el patrón es opuesto: incrementas el contador y reflejas el nuevo número en el span correspondiente con innerHTML [03:10].

javascript victoriasJugador++; spanVidasJugador.innerHTML = victoriasJugador;

Este mismo patrón se repite en cada else if donde gana el jugador, y la versión equivalente con spanVidasEnemigo se usa cuando gana el oponente.

Cómo revisar el resultado final con tres escenarios

La función que antes se llamaba revisarVidas ahora maneja tres escenarios posibles, no dos. Puedes mantener el nombre o renombrarla a revisarVictorias para que el código sea más legible [04:55].

• Empate: si victoriasJugador === victoriasEnemigo, imprime un mensaje de empate.
• Victoria del jugador: si victoriasJugador > victoriasEnemigo, muestra el mensaje de ganaste.
• Derrota: el else final asume que ganó el enemigo.

¿Por qué necesito un tercer caso para el empate? Porque al jugar por puntos acumulados, ambos contadores pueden terminar con el mismo número. Sin esa validación, el código siempre asignaría la victoria a uno de los dos.

Cómo ajustar el HTML para mostrar el contador desde cero

En el HTML donde antes mostrabas las vidas iniciales, ahora debes cambiar ese número a cero, tanto para el jugador como para el enemigo [05:48]. Ya no empiezas la partida con un stock de vidas, sino con un marcador limpio que irá creciendo.

Este detalle es fácil de olvidar y rompe la coherencia visual del juego si lo dejas con el valor anterior.

Qué errores comunes aparecen al refactorizar la lógica

Durante la prueba salieron dos bugs clásicos que vale la pena revisar porque son típicos en cualquier refactor.

Por qué imprimía el ataque equivocado

El primer error fue confundir variables al imprimir resultados: el código asignaba el índice del jugador a la variable ataqueEnemigo, lo que mostraba datos cruzados [07:00]. La solución fue revisar cada asignación y confirmar que cada variable recibiera su propio índice.

Por qué el contador de victorias quedaba en cero

El segundo error fue más sutil. Al actualizar el innerHTML del enemigo, el código apuntaba por equivocación a spanMascotaEnemigo en lugar de spanVidasEnemigo, lo que reescribía el nombre de la mascota con un número y dejaba el contador visible siempre en cero [08:30].

¿Cómo encuentro este tipo de errores en JavaScript? Revisa qué selector estás modificando con innerHTML. Si un elemento de la pantalla cambia cuando no debería, casi siempre es porque escribiste el nombre de variable equivocado al apuntar al DOM.

Qué aprendiste al construir un juego dinámico con objetos

Pasaste de un juego con valores hardcodeados en HTML y JavaScript a uno donde los objetos guardan la información de las mascotas, sus imágenes y sus ataques. Tomas esa información, la imprimes en el DOM y validas las jugadas para asignar empates, victorias o derrotas.

Este tipo de proyecto te entrena en habilidades concretas: manipulación de arreglos, uso de index, condicionales encadenados, manejo de variables globales y actualización del DOM con innerHTML. ¿Qué parte de esta lógica te costó más resolver? Cuéntalo en los comentarios.