Sistema de vida reutilizable en Unity

Un sistema de vida claro y reutilizable marca la diferencia en proyectos Unity. Aquí verás cómo estructurar una clase de vida genérica para jugador y enemigos, usando propiedades con getter y setter, un field privado con SerializeField y lógica preparada para el umbral de muerte. Todo con un enfoque limpio, escalable y fácil de mantener.

¿Cómo crear un sistema de vida genérico en Unity con C#?

La idea clave: una única clase controla la vida de personajes y enemigos. Se define una propiedad pública con getter y setter para encapsular el acceso, y un field privado para almacenar el valor real. Gracias a SerializeField, el valor puede modificarse desde el Editor de Unity sin perder encapsulación.

• Una clase, dos usos: mismo código para jugador y enemigos.
• Encapsulación: control seguro con getter y setter.
• Edición en editor: SerializeField permite ajustar vida sin tocar código.
• Extensible: el setter centraliza reglas y reacciones a cambios.

¿Por qué usar propiedades con getter y setter en la vida?

• Control del estado: el setter decide qué pasa cuando cambia la vida.
• Reglas claras: se pueden limitar rangos o disparar eventos.
• Consistencia: todos modifican la vida a través de la misma puerta.
• Legibilidad y mantenimiento: nombres como HealthPoints facilitan la intención.

¿Qué estructura básica tiene el script de vida?

Este esqueleto resume la implementación descrita: field privado serializado, propiedad pública con getter y setter, y sin Update (no hace falta). Se deja un TODO para gestionar la muerte.

using UnityEngine;

public class Health : MonoBehaviour
{
    [SerializeField] private float healthPoints = 100f; // Almacenamiento real, editable en el editor.

    public float HealthPoints
    {
        get { return healthPoints; } // Acceso controlado.
        set
        {
            healthPoints = value; // Asignación centralizada.

            if (healthPoints <= 0f)
            {
                // TODO: gestionar la muerte del personaje/enemigo
                // (destruir, aplicar gravedad, animaciones, etc.).
            }
        }
    }

    void Start()
    {
        // Preparación futura si se necesita.
    }

    // void Update() { } // Eliminado: no es necesario para este sistema.
}

Puntos a notar: - La propiedad HealthPoints en PascalCase y el field healthPoints en camelCase. - El parámetro implícito del setter es value: representa el nuevo valor asignado. - El field es private y serializado: editable en el editor, inaccesible desde fuera por código.

¿Qué decisiones de diseño mejoran el control de la vida?

La combinación de propiedad pública y campo privado permite validar, reaccionar a cambios y mantener el estado consistente. El setter es el lugar natural para aplicar reglas como el umbral de muerte.

¿Cómo ayuda SerializeField en el editor de Unity?

• Permite ajustar puntos de vida iniciales desde el inspector.
• Mantiene la encapsulación: no se expone el field como público.
• Facilita pruebas rápidas sin recompilar código.

¿Cómo y cuándo reaccionar a umbrales de vida?

• Comprobar en el setter: if (healthPoints <= 0f) { ... }.
• Preparar la gestión de muerte: destruir enemigo, aplicar gravedad o animaciones.
• Dejar el TODO visible: ayuda a integrar lógica específica más adelante.

¿Qué viene después para completar el sistema de combate?

La siguiente pieza es un script de daño que reduzca HealthPoints de forma segura usando el setter. Así toda modificación pasa por la misma lógica y se activan las reacciones necesarias.

¿Qué conviene preparar para el script de daño?

• Referenciar el componente Health del objetivo.
• Modificar vida solo a través de HealthPoints (nunca el field privado).
• Definir cómo se aplica el daño: golpes puntuales o decrementos progresivos.

¿Tienes dudas o ideas para ampliar la lógica de muerte o efectos al bajar de ciertos porcentajes de vida? Cuéntalo y seguimos construyendo juntos.