Saludos::
 
Les ha pasado que cuando el proyecto se va volviendo mas pesado, empieza a quedar una ensalada de código y de referencias que uno mismo termina se termina perdiendo?.. llevo 9 años con esto de la programación de videojuegos, y aún no logro pillar un modelo de programación que sea escalaBle y que permita mantener ordenado el código cosa que uno no tenga que perderse...

 
 
Por ejemplo, tengo ahora mismo una disyuntiva, si colocar los eventos de colisión en la clase jugador, o colocarlos en un controlador de escena, o colocarlos en la clase que tiene el objeto con el que colisionó el jugador...   
 
1)Si los eventos van en la clase jugador, ésta clase se volverá un caos, pues hay muchos tipos de reacciones diversas que tendrá el jugador dependiendo de con qué objeto colisione.


ej:
 
     OnCharacterControllerCollisionHit(Collider elOtroObjeto)
 
             si elOtroObjeto es un muro, hacer esto...

             si elOtroObjeto es un enemigo que se mueve, hacer esto otro....

             si elOtroObjeto es un enemigo que no se mueve, hacer esto otro....
 
             si elOtroObjeto es una bola gigante, hacer esta otra cosa...
 
             ......
 
             si elOtroObjeto numero554, hacer esta cosa...     (imaginen que hay un centenar de objetos, no los podría controlar a todos dentro de esta clase).



2)Si los eventos van en un controlador (una clase que mani*** los objetos de la escena) siento que este modelo (muy similar a MVC) sería bastante redundante:
 
 
 
ej:
 
       objeto colisionado: oye controlador, mándale este mensaje al jugador, dile que chocó conmigo.

       controlador: vale, yo le doy el recado.

       controlador: oye jugador, el objeto con el que colisionaste te envía este mensaje, dice que has chocado con el.
 
       jugador: ya, gracias, recibido...      (aquí recién está reaccionando a la colisión)


 
 
3)Si los eventos de colisión van en la clase que contiene el objeto colisionado (OnTriggerEnter u OnCollisionEnter) podría ser un poco mas ordenado, pero se pierde el sentido de la POO, ya que el evento estaría en el objeto colisionado y no en el jugador, es decir, el objeto estaría controlando al jugador para que reaccione según ese objeto colisionado.
 
 
 
Como lo hacen ustedes, van programando al vuelo como salga y luego utilizan un modelo de programación, o usan alguna plantilla?...  No se si existe o no algún libro o tutorial sobre como organizar mejor tu proyecto y el código...quizá no he revisado lo suficiente, pero sería muy bueno encontrar algo, no digo algo directamente enfocado a Unity, sino en general...
 
     
 
 
 
 
 
 
 
 
 
 
 
 

Cita de: digimikeh date=1541168880Como lo hacen ustedes, van programando al vuelo como salga y luego utilizan un modelo de programación, o usan alguna plantilla?...  No se si existe o no algún libro o tutorial sobre como organizar mejor tu proyecto y el código...quizá no he revisado lo suficiente, pero sería muy bueno encontrar algo, no digo algo directamente enfocado a Unity, sino en general...
   

En mi caso pienso al evento (en sí no es un evento más bien un mensaje, supongo que a eso te referís con los OnTrigger ... OnCollision etc) como una funcionalidad más de la entidad de turno, por ej: si estamos hablando de hacer daño con un proyectil, quien lleva el mensaje OnCollision en el código? el proyectil o las entidades (en general player, NPC, pared, silla, etc) con las que colisiona? la respuesta lógica para mí sería que sea el proyectil ya que el proyectil daña, dicho esto, el proyectil interactua con objeto "dañables", sea el player, un NPC o una silla, entonces meterle este mensaje a la silla y al player principal queda medio raro y feo, lo ideal sería que quien hace la funcionalidad sea quien lo lleve, a parte te queda mucho más prolijo visto desde la matriz de colisiones (hablando en este caso de colisiones). Ni hablar que si eliminás al portador del mensaje -> fin del procesamiento de esta función, en cambio si fuera alrevés siempre todos los posibles objetos tendría esa funcionalidad aunque ya no exista el portador principal de la misma.
 
Así que en lo personal iría a 1).
 
Si uso alguna plantilla o cosa por el estilo? NO, lo primero que tenés que simular en tu cabeza es que tenga sentido y que sea escalable por vos y por cualquiera, por ej 2) para mí no tiene tanto sentido (como decía arriba) y 3) puede tener sentido (si estuvieras haciendo tu propio sistema de colision y tu propo Update) pero ya estás probablemente usando un Update (monobehaviour) en tus objetos que interactuan en la colision, tener un manager a parte para gestionar todo es redundante como decís, podrías llegar a usarlo para administrar mejor algunas cosas pero no me termina de cerrar para esta situación. La parte física del motor hace algo como 3) , evalúa todos los objetos que se encuentren dentro de un volumen dado , que tengan la propiedad de colisionar con otro y que estén habilitados para hacerlo (por eso la matriz de colision es importante), si se da y X objeto tiene su mensaje (por ej OnTriggerEnter) se disparará, osea que el tema de las colisiones funciona parecido a 3) pero lo administra la misma parte de las físicas por defecto.
 
 
 
Saludos

Lo he pensado y puede funcionar, lo lógico es que los eventos vayan en el mismo Jugador, al final es él el que está colisionando, tendría que verlo desde ese punto de vista real, pero aún así, será un poco engorroso acumular tantos eventos en una sola clase.... Lo intentaré.
 
 
 
Saludos y gracias.

Cita de: digimikeh date=1541189769Lo he pensado y puede funcionar, lo lógico es que los eventos vayan en el mismo Jugador, al final es él el que está colisionando, tendría que verlo desde ese punto de vista real, pero aún así, será un poco engorroso acumular tantos eventos en una sola clase.... Lo intentaré.
   

Pero tampoco hay por qué meter la gestión de todas las posibles colisiones en la clase Player.
 
El código de Player puede llamar al objeto colisionado para que haga su parte...
 

public class Player : MonoBehaviour {
void OnCollisionEnter2D(Collision2D coll) {
   // El jugagador hace lo suyo. Ej:
   //   1) reproducir un sonido.
   //   2) perder vida
   // Ahora informamos al objeto impactado
   GameObject other = coll.otherCollider.gameObject;
   // Opcion 1: si hay una clase genérica que pueda implementar la funcionalidad (ie un método Hit)   
   MyGameClass myGameObject = other.GetComponent<MyGameClass>();
   if (myGameObject != null) myGameObject.Hit(coll);
  
   // Opcion 2: usar SendMessage
   other.SendMessage("Hit", coll, SendMessageOptions.DontRequireReceiver);             
}
}

 
(Lo he escrito un poco de memoria, a ver si te sirve de inspiración).