Programación orientada a Componentes [Unity]

Postmortem #1 Jul '15

Buenas, este verano estoy abordando varios proyectos en Unity, entre ellos uno en esta misma comunidad por colaboración gratuita, y como siempre, me gustaría abordar el diseño del código de la manera más eficiente posible, al comienzo se planteó un diagrama de clases UML tradicional, pero eso Unity no lo traga ya que no es demasiado familiar con la herencia, para que os hagáis una idea, tenemos la clase Entidad que posee la funcionalidad de moverse como entidad, tener vida, y luego tendríamos clases específicas hijas como jugador o enemigo

Buscando información al respecto, lo único que me ha quedado algo "claro" es que se intente modularizar todo lo posible, es decir, si algo se puede matar, crear un script "Killable" que permita poder matar al objeto de X manera, si se puede mover, el script "Movable".. pero no estoy del todo seguro como se aborda, y aquí planteo la cuestión

Vosotros, programadores, como abordáis el diseño del código? alguna información o link que estudiarse relacionado con el tema?

Un saludico

CrIpI #2 Jul '15 Penitente

Para modularizar mejor un objeto es preferible crear un script por cada cosa como has dicho.

Cyph3r #3 Jul '15

Usa composición nunca herencia.

VicoViper #4 Jul '15

#1 Personalmente, yo siempre he trabajado con scripts prácticamente individuales para cada cosa.

En el proyecto del que hablas, por ejemplo, tenemos Enemy.cs y EnemyIA.cs, pero es que llegado el momento, a mi personalmente no me parecería extraño separarlo también en EnemyAttack.cs y EnemyMovement.cs.
Tanto ocmo un script killable no, pero una variable boolean killable en el "enemy.cs" que sea leída por la función Death(), no me parece tan descabellado.

Y luego, haces una asignaciones al iniciar la pantalla, para que lean todos los scripts que hagan del gameobject y tira millas...

Srednuht #5 Jul '15 :psyduck:

#1 No veas lo jodido que es meter un diagrama de clases en un proyecto hecho con Unity xDDD sudé la gorta gorda para escribirlo para el TFG pero bueno, salió mas o menos bien. A fin y al cabo cada script sigue siendo una clase/objeto y no siempre hay que tirar de monobehaviour... no siempre es necesario.

Más que hacer una clase killable/movable/whatever-able lo que deberiais es hacer herencia como toca.

Haced una clase 'Entidad' como dices, con funciones virtuales que luega podais sobreescribir.

(ejemplo de wiki, C++ pero es lo mismo)

spoiler

Class Animal
{
public:
    virtual void come() { std::cout << "Yo como como un animal genérico.\n"; }
    virtual ~Animal() {}
};
 
class Lobo : public Animal
{
public:
    void come() { std::cout << "¡Yo como como un lobo!\n"; }
    virtual ~Lobo() {}
};
 
class Pez : public Animal
{
public:
    void come() { std::cout << "¡Yo como como un pez!\n"; }
    virtual ~Pez() {}
};
 
class OtroAnimal : public Animal
{
    virtual ~OtroAnimal() {}
};
 
int main()
{
    Animal *unAnimal[4];
    unAnimal[0] = new Animal();
    unAnimal[1] = new Lobo();
    unAnimal[2] = new Pez();
    unAnimal[3] = new OtroAnimal();
 
for(int i = 0; i < 4; i++) {
    unAnimal[i]->come();
}

for (int i = 0; i < 4; i++) {
    delete unAnimal[i];
}
return 0;
}

Luego lo que yo haría sería meterle un Enum para la entidad

 enum Tipo{
Enemigo,
 NPC,
Usuario
};

Y desde el editor tendréis una lista desplegable tal que así(con los valores de arriba, se entiende):

para poder seleccionar que tipo de entidad es el objeto que tiene dicho script.

Luego es generar clases que sobreescriban a dicha clase y modelar su comportamiento en función del valor que haya tomado 'Tipo'.

1 1 respuesta

sasher #6 Jul '15

#5 Pretender usar polimorfismo para luego tener un enum de tipos contra los que compruebas a la hora de hacer algo, es un síntoma de herencia muy mal usada. Y es que la herencia, en proyecto GRANDES puede llegar a ser un cáos por el acoplamiento que implica. Tampoco es que la composición sea la panacea, pero desde luego quedan diseños mucho más limpios, mantenibles y escalables.

1 respuesta

Srednuht #7 Jul '15 :psyduck:

#6 hablo de subtipos dentro de las clases heredadas creo que quedaba mas o menos claro. Es una muy buena forma de darle comportamientos distintos a lo que debería ser un mismo tipo de entidad.

El ejemplo que he puesto es para tipos de entidades pero lo del enum seria para tipos de enemigos,no para tipos de entidades. Suponiendo que las variaciones son mínimas(en teoría el proyecto de colaboración iba a ser simple no?),o únicamente tienes que variar entre un par de comportamientos.

Lo del enum es mas por ejemplo si tienes
Entidad
Heredado enemigo
Heredado elemental de fuego
Y aqui aplicar variaciones para generar unos cuantos distintos. También podría haber un nivel menos de herencia y directamente utilizar la enumeración para realizar variaciones de estados (buffs/debuffs)

No se su ha quedado claro,y si ha quedado claro y no es lo mas eficiente, puede ser,yo creo que por lo que he currado con unity,que se sale de la programación convencional,es una de las mejores opciones y de rápida implementación

Programación orientada a Componentes [Unity]

Usuarios habituales

Tags