Hola,
 
Bueno, os explico esa duda o medio duda que me ha surgido así de pronto, a ver si me se explicar bien.
 
Imaginemos un juego que se compone de centenares o miles de objetos, todos con unas determinadas características que me permiten por un lado crearlos fácilmente de una una docena de familias de prefabs y por otro lado agruparlos para controlarlos en un único objeto en determinadas circunstancias, de forma que no necesito esa sobrecarga de miles de objetos arriba y abajo por todo el juego (para hacernos una idea, como los ejércitos en el Total War, que en el plano estratégico son una sola pieza y no es hasta descender al plano táctico que cada unidad toma entidad, o por poner otro ejemplo, una flota de centenares de naves, que tomando la velocidad y el destino, no necesitas las naves individuales hasta que se encuentran con una flota enemiga)
 
Así que la idea es generar un pool de unidades/naves o lo que toque, y moverme en el plano general con unos pocos GameObjects que contendrán la información de conjunto (numero de naves/tropa, total de cada subtipo, velocidad de conjunto, salud promedio y cosas así) y en el momento que sea necesario tomar los GameObjects necesarios del Pool y alimentarlos con los datos para darles la entidad.Hasta aquí el planteamiento en sencillo. Creas uno o más diccionarios para guardar todos los datos de las naves/unidades simuladas, y en el momento necesario en que una agrupación/flota/ejercito pasa al plano táctico, seleccionas de los diccionarios los objetos involucrados a través de LINQ y pasas los datos adecuados a cada uno de los objetos activados del pool. Hasta aquí todo bien. Pero aquí se me plantea la duda.
 
Los objetos guardados han de ser "puros" o heredados de MonoBehaviour.
 
En el caso de objetos puros, puede que necesiten tener referencias a GameObjects y otros elementos particulares de Unity. Pueden tener objetos que no hereden de MonoBehaviour referencias a Objetos propios de Unity?
 
En el caso de heredar de MonoBehaviour, bastaría con añadir directamente el componente seleccionado al Prefab instanciado, pero al hacerlo, no estaré sobrecargando el sistema con datos innecesarios? Tener miles de Componentes con MonoBehaviour, incluso para clases sencillas de un par o tres de datos, puede ser en si mismo una burrada por toda la cola que puede traer el MonoBehaviour? Puede tener efectos secundarios por la acumulación?
 
Reflexionando sobre ello, me he dado cuenta de mi ignorancia al respecto, y buscando tampoco he sabido encontrar nada que me indique como es mejor encarar el tema...
 
Muchas gracias a todos.

http://answers.unity3d.com/questions/999455/difference-between-monobehaviour-and-scriptable-ob.html

Hola, q preguntita jaj.
 

Cita de: Tizon date=1489432186En el caso de objetos puros, puede que necesiten tener referencias a GameObjects y otros elementos particulares de Unity. Pueden tener objetos que no hereden de MonoBehaviour referencias a Objetos propios de Unity?
   

Lo que te puedo decir es que "Monobehaviour" es un "Behaviour" quie es un "Component" que es un "Object", en teoria es un Objeto mas de Unity, como transform, meshrenderer, scirpts, etc. Si creas tu clase "pura" como decis, ya no seria ningun objecto de Unity, es decir que dentro de dicha clase no podrias referenciar nada. Podes verlo como que tenes los nombres pero no la funcionalidad. Fuera de dicha clase (en monobehaviour) podes referenciar los datos de la clase pura. Pero creo que no es de mucha utilidad, la clase pura la utilizarias como una clase de datos, como cuando guardas una partida o algo parecido.
 
 
 

Cita de: Tizon date=1489432186En el caso de heredar de MonoBehaviour, bastaría con añadir directamente el componente seleccionado al Prefab instanciado, pero al hacerlo, no estaré sobrecargando el sistema con datos innecesarios? Tener miles de Componentes con MonoBehaviour, incluso para clases sencillas de un par o tres de datos, puede ser en si mismo una burrada por toda la cola que puede traer el MonoBehaviour? Puede tener efectos secundarios por la acumulación?
   

Tener muchos monobehaviours nunca es recomendable, no pensaste en emplear un ScriptableObject para mantener los datos de las unidades y demas, es super util sobretodo si tenes pensado hacer un RTS.
 
Saludos

Cita de: GSG3D date=1489438392http://answers.unity3d.com/questions/999455/difference-between-monobehaviour-and-scriptable-ob.html
   

 
 

Cita de: lightbug date=1489438592Hola, q preguntita jaj.
   
   
      Lo que te puedo decir es que "Monobehaviour" es un "Behaviour" quie es un "Component" que es un "Object", en teoria es un Objeto mas de Unity, como transform, meshrenderer, scirpts, etc. Si creas tu clase "pura" como decis, ya no seria ningun objecto de Unity, es decir que dentro de dicha clase no podrias referenciar nada. Podes verlo como que tenes los nombres pero no la funcionalidad. Fuera de dicha clase (en monobehaviour) podes referenciar los datos de la clase pura. Pero creo que no es de mucha utilidad, la clase pura la utilizarias como una clase de datos, como cuando guardas una partida o algo parecido.
   
   
       
   
   
      Tener muchos monobehaviours nunca es recomendable, no pensaste en emplear un ScriptableObject para mantener los datos de las unidades y demas, es super util sobretodo si tenes pensado hacer un RTS.
   
   
      Saludos
   

Hola, gracias a los dos por las respuestas. Digo poco, miles de gracias.
 
Es por esto que me gusta hacer preguntas retóricas, siempre aprendo cosas que ni sabía que existieran.
 
Llevo toda la semana leyendo la documentación, viendo el Training y haciendo pruebas y la verdad es que se adapta como un guante a lo que necesito. Es una pasada, prácticamente se puede armar el juego ahí, estructurando los datos a la perfección.
 
Aún así siento que hay cosas que me pierdo, quizá por qué no domino el inglés tanto como quisiera y busco documentación y veo que hay bastante poca al respecto. Es como si fuera una parte que no todo el mundo conoce o que no acostumbren a usar... 
 
Si por un casual alguien conoce algún tutorial completito lo agradecería. Y si es en castellano, ya hago un monumento!!!
 
Nuevamente, miles de gracias.

Hola, con respecto a los ScriptableObject no conozco buenos tutoriales y en español mas alla de los hay en Unity oficial (ingles), seguro en youtube vas a encontrar en cantidad. No hay demasiada ciencia, son derivados de una clase que no estan ligados a ningun Monobehaviour (Objeto con ciertas funcionalidades puramente del gameplay), El uso de estos objetos, por lo que he visto pueden ser muy variado, para lo que yo los uso/usaria por lo menos seria:
 
- contenedor de datos global: Por ej mi juego tiene un max de "maxPlayers" cada uno con un maximo de "maxHealth", valor de ataque "Attack" , y un nivel de aleatoriedad "Randomness", capa de deteccion de snipers "sniperLayerMask" , etc.. . Quiero que todos estos valores sean fijos para todas las entidades, entonces creo un sola SCO con los datos necesarios y listo. Evito que multiples objetos puedan usar distintos valores de algo determinado. Por ej tengo uno para Juego, Enemigos, Jugador, etc..
 
- descriptor de comportamiento: Puedo tener un SCO llamado "inteligencia", y en mis assets creo, "Genio", "Promedio" e "Idiota" cada uno con sus variables, metodos que sean y quizas mi componente monoBehaviour pueda tener una "inteligencia" ligada, le asigno la que quiero y magia...
 
Recientemente hice un TileMap editor 2D/3D, y cada monobehaviour tiene un "profile" asociado (que es un SCO), es decir que con tan solo cambiar el profile asociado mi nivel pasa de ser un desierto caliente, a ser un mundo de hielo por ej, ya q fuera del Juego fui cargando de forma orgaanizada todo. Tambien podes crear tus propios Inspectors para los ScriptableObjects. Un ejemplo asi es el ultimo Stacks de efectos de Unity (Cinematics Effects) que usa varios profiles para lograr distintos efectos.
 
- Enums flexibles (este lo vi en un video, nunca lo use asi): Supone que necesitas una listas con distintos enums, si tuvieras 500 enums en la listita, seria totalmente agobiante/imposible elegir, ahora si en vez del enum tenes un SCO, llamado por ejemplo "Item_Enum", creas 500 assets distintos con solo un nombre (equivalente al nombre del elemento del enum) y lo arrojas al casillero del inspector. Obviamente no es lo mismo que tener el enum, estas creando instancias del SCO, versus tener un enum que es mucho mas barato, pero en un caso totalmente retorcido como este supongo que tiene sentido.
 
tus inspectors van a quedar super limpios

En mi caso, hasta ahora, creaba un GameObject ControlDeJuego, el cual guardaba todas las referencias de los objetos en diferentes diccionarios y se encargaba de las interactuaciones entre ellos (así las quitaba del Update y en vez de hacerlo en cada Frame, lo hacia cada X tiempo). La verdad es que los prototipos funciona estupendamente, el problema estaba cuando se empezaban a multiplicar los objetos, caía el rendimiento en picado. Por eso pensaba de segmentar para no tener siempre todos los objetos y tener sólo una representación de las agrupaciones de los mismos. De ahí mi duda de como hacerlo del modo más conveniente. Así pues ahora usaré ScriptableObject como Base de Datos para guardar todos los datos del juego, ya que la estructura invita a ello, y cargaré los GameObjects a través de prefabs y los alimentaré de datos desde el ScriptableObjects según convenga. Aún hay algunos puntos que no veo bien como resolver, pero el conjunto lo tengo más que claro.
 
La verdad es que inglés aunque lo entiendo tengo la sensación de estar perdiéndome cosas... Y en castellano no encuentro nada de nada... Pero bueno, poco a poco de ir viendo como hacen me voy quedando con la copla y espero no perderme mucha información esencial...
 
Nuevamente muchas gracias.