Creo de @Arthure no entendió o yo me mal exprese en el sentido de cómo estaba interpretando el mensaje, la idea era dar como una "MALA IDEA" de cómo centralizar un poco las aplicaciones.   
 

Cita de: lightbug date=1502376038public delegate void PlayerDeadDelegate (); public static event PlayerDeadDelegate PlayerDead;
   

Esto puede estar bien, o mal, dependiendo de cuántos jugadores estén dentro del juego, pero no por eso deja de ser una buena idea o solución.
 
Por lo general en el desarrollo de un juego se centralizan todos los eventos, esto hace que el "DEBUG" sea más sencillo, la recopilación de información sea más ordenada. ¿Como sabrás cuantas veces murio el jugador? o ¿Cuantos enemigos has matado? ... 

 
 

Cita de: Arthure date=1502364702En mi mundo un evento (accion) lo ejecuta un objeto, y otros objetos capturan estos eventos ... en tu caso coges y llevas tanto la accion como la captura de dicha accion a una clase estatica, dices que asi hay que hacerlo porque evitas utilizas MonoBehaviour y te quedas tan ancho

¿Cómo lo implementamos mis preguntas basándonos en tu teoría?, ¿Eventos estáticos? - ¿Referencias? ... Pienso, no es mejor una clase "estática" que se encarge de obtener todos estos eventos, es decir, si muere el jugador llama a una función dentro de mi clase GameEvents y esta llama a un evento... El evento es capturado por quien quiera, pero la llamada tambien, eso se llama "Centralización" - ¡No creo que este mal este punto! Quizás el ejemplo no es el correcto, pero este mismo método de implementación utiliza VmWare para VCenter y dudo que ellos no sepan lo que hacen -
 
Sigamos en base a tu aclaración ... ¿Y si quiero simular 3000 muertes de enemigo?¿Debería entonces crear 3000 enemigos y matarlos?, ¿No existe la remota posibilidad de realizarlo con un comando? ... Mejor aún, vamos al Networking ... Como sincronizo todo un juego basado en componentes no referenciados ... 
 
Creo, en cierta forma que has interpretado mal el mensaje, y tu forma de contestar no va con tus "conocimientos" ...
 
Como tambien lo dice @lightbug, deberias corregir, no simplemente insultar.

@Arthure Lo comente abajo, que es algo complicado de explicar, cuando alguien está comenzando se le hace muy dificil entender como funcionan los delegados, los eventos, los argumentos, para que y porque se utilizan. Por ejemplo, si vamos a lo teórico, un delegado se parece mucho a un puntero de C, este vendría a ser una referencia a un método cualquiera, es decir no está explícitamente declarado para el compilador. Pero, ¿Quién podría entender estas palabras?, muchos ni siquiera saben que es un compilador...
 

Cita de: francoe1 date=1502307684Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
   

En esta parte especificó que en realidad esto es algo muy disparado...
 
De todos modos gracias por la corrección, pero antes la burla o "la mala manera de corregir" estaria bueno que muestres de que manera cada implementación sería mejor, y que al mismo tiempo, personas que no conocen mucho sobre el tema puedan llegar a entender.
 
Saludos. 

Cita de: pioj date=1502303919Si algún día compartes un ejemplo de todo esto que fomentas, la Comunidad y to te lo agradeceremos efusivamente...
   

Claro, siempre que puedo estoy compartiendo, pero en mis momentos libres creó material que luego pueda obtener ganancias, pero estoy muy limitado con el tiempo.
 
En este caso, no se explica claramente lo que está necesitando, pero supongamos que el tiene un objeto que emparenta a otro.
 
(Player):GameObject // Jugador

        (Box Temp):GameObject // Caja temporal que se destruye al pasar por algún lugar.
 
Supongamos que el jugador necesita saber si la caja temporal se ha destruido, de ser así, obtener los valores del componente transform de la caja.
 
Por lo general, este tipo de problemas se plantean de la siguiente forma ¿La caja le avisa al Jugador que se destruyó?, ¿El jugador comprueba que la caja se existe? ... pero todas estas dudas no son más que malas ideas, partamos desde un inicio. ¿Por que el jugador necesita saber si la caja se destruyo?, ¿Y?¿Si otro componente tambien lo requiere? ... siempre estas son las preguntas futuras, las que hacen que el desarrollo de una aplicación se vuelva inestable. Entonces ¿Cómo realizarlo de la manera correcta?, bien, en primer lugar, vamos a tratar de centralizar los eventos, es decir, creamos una clase estática la cual puede llevar el nombre de GameEvents donde registramos todos los eventos del juego (con antelación deberíamos tener el diseño de nuestra aplicación, está más que claro que de lo contrario hay pocas posibilidades de éxito). Veamos un Ejemplo:
 

public static class GameEvents
{
public delegate DestroyObjectDelegate(GameObject go);
     public static event DestroyObjectDelegate DestroyObjectEvent = delegate {};
public static void DestoyObject(GameObject go)
    {
         DestroyObjectEvent.Invoke(go);
         //Unity ... 
         MonoBehaviour.DestoyObject(go);
    }
}

 
De esta manera nosotros podríamos desde cualquier lugar de la aplicación capturar el evento requerido... Ejemplo.
 

public class Player : MonoBehaviour
{
private void Start()
    {
   GameEvents.DestroyObjectEvent += OnDestroyObject;
    }

private void OnDestroyObject(GameObject go)
    {
   if(go.name == "Box Temp") Debug.Log("¡Objetivo destruido!");
    }
}

 
Podríamos utilizar la misma implementación desde cualquier lugar del proyecto, debido a que estamos trabajando basado en eventos.
 
 
 
Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
 
 
 
1º Aprender a utilizar eventos(event y delegate)
 
2º Aprender a utilizar enumeradores, entender como funcionan internamente (IEnumerator)
 
3º Aprender a utilizar clases Abstractas, Interfaces, Estructuras saber donde y cuando utilizarlas.
 
4º La decisión de utilizar un Componente MonoBehaviour es crítico, tratemos de no hacerlo.
 
En este punto me gusta mucho dar el ejemplo del movimiento de las actores dentro de un juego, por ejemplo, tenemos dos tipos de personajes con movimientos totalmente diferentes, muchos frente a este problema crearán un componente diferentes para cada uno, 2 prefabs, y se empieza a complicar todo, otros recurrirán a la abstracción, mi recomendación, utilizar clases no serializadas para los diferentes comportamientos, es decir.
 

public class Player : MonoBehaviour
{
private Motor _motorJumper = new MJumper();
private Motor _motorRunner = new MRunner();
private Motor _current;
private void SetMotor(int mode)
    {
   switch(mode)
   {
      case 0: _current = _motorJumper; break;
      case 1: _current = _motorRunner; break;
   }
    }
private void Update()
    {
   _current.Run(Input.Axis*****);
    }
}
public class Motor 
{
public virtual void Run(Vector3 axis){}
}
public class MJumper : Motor
{
public override void Run(Vector3 axis)
    {
   movimientos.. 
    }
}
public class MRunner : Motor
{
public override void Run(Vector3 axis)
    {
   movimientos.. 
    }
}

 
Existen muchos ejemplos, en cuanto tenga tiempo voy a terminar una serie de tutoriales que tengo ya en edición, sobre un sistema de armas bastante completo, donde trato de explicar la importancia de cada técnica... 

Serializar el componente Transform y Deserializar....
 
Capturar un Evento por parte del Padre.
 
Etc... 
 
Pero usar SendMessageUpwards() no es conveniente! ...
 
 
 
Tienes que dejar de pensar en componentes y más bien tratar de armar un ambiente estructurado y en sintonía, utilizar la mínima cantidad de MonoBehaviour y abstraer todo al máximo logrando así mantener tu aplicación limpia, optimizada y expansible.

Yo lo optimizaría al
 

Cita de: Jocyf date=1501866038if( god.name == "pioj") BlendTheKnee(true, "Oh, pioj, my good god"); else KillTheBitch (stone, 1000).
   

(god.name == "pioj")? BlendTheKnee(true, "Oh, pioj, my good god") : KillTheBitch (stone, 1000);
 
 
 
Jajaja

Cita de: Jocyf date=1501778523Gracias por vuestras palabras, la verdad es que el trailer nos ha quedado muy bien.
   
   
      Ahora estamos preparando una nueva versión mejorando pequeñas cosas y pensamos publicarlo en un par de semanas. Una vez publicada esta nueva versión pensamos sacar una versión para Android hacia Septiembre.
   

Genial, estaré a la espera, siempre estoy pendiente de tu contenido, indirectamente fuiste mi mentor.. jajajaja, Abrazo.. 

Cita de: Jocyf date=1501778624

      Viendo mi perfil de Iniciado con mis 27 post en curso, no puedo sino expresar mi más sincera y profunda decepción.
   
   
       
   
   
       
   
   

      ¿Donde andan todos mis miles de post de hace tropecientos mil años??? Con las chapadas tan guapas que me había cascado durante tantos años y con unas explicaciones que rezumaban sabiduría -mal está decirlo, pero si, SABIDURIA con mayúsculas- por los 4 costados.
   
   
       
   
   
       
   
   

      Creo recordar sin temor a equivocarme (aunque el Alzeimer cuando ataca no lo ves ni llegar, es muy traicionero y ruin), que era el usuario más activo del antiguo UnitySpain con bastante diferencia. O, dicho de otra forma, los demás eran vagos, pero que muy vagos; no posteaban más que para adularme golosamente por mis extensos conocimimientos que tan altruistamente compartía con esas pequeñas mentes  (conocidos comúnmente como nubs o novatos) que bebían compulsivamente -letra a letra- cada uno de mis inmejorables y gloriosos post (ahora perdidos y olvidados en las brumas de internet). 
   
   
       
   
   
       
   
   

      Dicho esto solo para poneros en antecedentes, solo me queda decir:
   
   
       
   
   
       
   
   

      Mal!!  Muy Mal!!! Donde esta el Moderador!!!!  Exigo una explicación!!!!
   
   
       
   
   
       
   

Esto cambió mucho, quizas a peor, el material que uno comparte es irrelevante, ya no se premia las personas que comparten sus conocimientos, simplemente te convertis de usuario a experto en 10 minutos, creo que ese fue uno de los cambios que más me llamó la atención dentro del foro, pero lo usuarios viejos ya casi no existen, los que estamos hace varios años en los inicios de UnitySpain sabemos de que se habla.... 
 
Estoy de acuerdo con que se cambió muchísimo la modalidad de premiación, y se da poca importancia a los aportes de verdad muy interesantes.
 
Debería existir una sección donde solo usuarios con ciertos privilegios puedan compartir su material, haciendo así que la calidad del foro crezca, y se vuelva a disfrutar de compartir los conocimientos y experiencias.
 
Ahora veo solo un par de usuarios activos, pero hace un tiempo Jocyf era un usuario bastante querido y activo dentro de la comunidad, uno de los primeros videos tutoriales en español...
 
No digo que de vergüenza, pero me gustaria recuperar parte de lo UnitySpain fue a  un principio.
 
 

¿Por qué no intentar con Google Play?, ¡Quiero probarlo!

Lo de braltor es un punto a resolver..
 
https://unity3d.com/es/learn/tutorials/temas/best-practices/resources-folder
 
Se podría utilizar una carpeta relativa a la aplicación que contenga la malla y textura serializada, hasta se podría serializar todo en un solo archivo, osea, Casa.msh > contiene la malla mas los materiales... es cuestión de imaginación, lo mejor seria no cargar en memoria todo, sino más bien, cargar lo necesario, y luego liberar los recursos al terminar de utilizarlo.
 
 
 
Utilizar este Plugins.. tambien puede ser una alternativa, aunque volveríamos al problema iniciar.

Cita de: lightbug date=1501709283Eso esta genial, pero me parece que todas las mallas que tienen un skin tienen un skinned mesh renderer, y una de las variables de ese componente son los bones: https://docs.unity3d.com/ScriptReference/SkinnedMeshRenderer.html asi que en teoria si usas los mismos bones (lo cual es lo correcto) deberia funcionar sin problemas. Es mejor que andar instanciado, lo unico que haces es cargar el recurso (mesh data) con Resources.Load supongo.
   
   
       
   

Claro, deberias de poner todos los ítems dentro de la carpeta Resources, luego, como dices Resources.Load(); cargas la malla y los materiales. Lo hice en varios proyectos, es algo bastante utilizado, y va con uno de los conceptos de diseño, "NO MEZCLAR LÓGICA CON GRÁFICA"... 
 
Pero no siempre es compatible con todos lo proyectos, pero evita bajo todo concepto la activación o instanciación de modelos.

Si las armaduras no tienen colisión, por que no cargar la malla a MeshRenderer, y los materiales correspondientes, eso desde mi punto de vista seria lo mejor.

   
      public GameObject[] objeto = new GameObject[10];
   

[/quote]
 
El problema es la serialización, que puede que te lo inicialize a 0.
 
Frente a esto creo que lo mejor seria Unit***itor, implementar ReorderableList o bien armar algo con ObjectField.

Posiblemente se trata de un error de referencias!

En principio, debería de detectar si X objeto existe antes de llamar uno de sus métodos.
 
Por ejemplo, tienes una cámara, que sigue a un Transform, si dicha referencia es nula entonces no se ejecuta ninguna acción dependiente.
 

public class CameraPlayer : MonoBehaviour
{
public Transform Target;
private void LateUpdate()
    {
   if(Target == null)return; //Si el target no esta asignado entonces salir de la funcion.
    }
}

 
Esto seria lo mas simple, si no es lo que buscas entonces estaríamos hablando de CallBack, Eventos, etc.. 

El problema es que estas intentando desarrollar algo que requiere de un conocimiento mucho más elevado del que dispones, ya lo comente en varios topics, el apartado Networking requiere de mucho conocimiento y para lograr algo decente te voy a dar los puntos más necesarios.
 
1º - Programacion de Socket - Entender el funcionamiento de UDP y TCP.
 
2º - Tratado de datos, Serialización y Compresión.
 
3º - Sistemas centralizados.
 
4º - Base de datos o estructuras como XML o JSON.
 
¿Por qué todo esto es importante?
 
La programacion de un juego en red es algo de lo más complicado que existe, no por el hecho de enviar una posición y predecir, esto es lo más simple, los sistemas se vuelven complejo cuando se trata de sincronizar los estados de múltiples objetos, implementacion de múltiples sockets para evitar los cuellos de botella por los AKC en datos importantes. Para todo esto existen técnicas , como ZoneSync, ChunkSync y varias más.
 
Por esta simple razón resumida a lo bruto te diría que comprendas cómo van las cosas.
 
 
 
Ahora, ¿Cuál es tu problema puntualmente?
 
No estas distinguiendo entre un entorno local y el servidor, cada instancia del juego es un entorno local, aunque estés conectado a un servidor sigue siendo totalmente local, quiere decir que, podes mover otros jugadores, destruirlos, etc, por esta razón en juegos de la actualizad aun se pueden usar hacks como Auto-aim, wall hack, fly, etc.
 
¿Por que la cámara del o los jugadores que se conectan después del primero no funciona?
 
Lógicamente no funcionan por que en tu instancia local existe ya un "Game Object (Player)" que contiene un cámara en X layer, supongamos 1 y cuando se crea tu instancia tambien contiene una cámara con las mismas configuraciones por lo que Unity no renderiza con dicha cámara, porque no detectó cambio alguno.
 
Lo mismo sucede con los movimientos, primero tienes que estar seguro de que estas moviendo tu propia instancia, en networking es muy utilizado el "IsMine", que en UNET es equivalente a isLocalPlayer, entonces deberias de procesar todos los inputs con la condición de isLocalPlayer. Aca vienen problemas de diseño, de lógica y un millón de temas para hablar que no van al caso.
 
... CÓDIGO ... 
 
Game Input... Cuando se conecta a un servidor se deben setear las dos variables, si no se conecta a un servidor entonces se pueden utilizar normalmente para el juego OffLine.
 

public class GameInput : MonoBehaviour
{
public static bool isLocalPlayer = false;
public static bool isNetwork = false;
public bool Press(KeyCode key)
{
   return (isNetwork && isLocalPlayer)? Input.GetKey(key) : false; 
   return Input.GetKey(key);
}
}

 
Jugador.
 

public class Player : MonoBehaviour
{
private void Update()
    {
   if(GameInput.Press(KeyCode.W))
        {
      transform.Translate(transform.forward * 5 * Time.deltaTime);
   }
    }
}

 
 
 
Te dejo mi blog donde explico un poco de esto...
 
http://unitydoc.blogspot.com.ar/