¡Muy bueno! ¡Gran trabajo!

Toma muy en cuenta lo que dice stick.
 
La programacion en red no es algo simple, y el sistema UNET hace las cosas aún más difíciles de lo que parecen, cuando se requiere un juego en red se hablan de muchas cosas el uso de múltiples Socket TCP y UDP la abstracción de eventos a sincronizar y otro tanto más. Te recomiendo lo siguiente.
 
¿Que debo sincronizar? ¿Es aceptable la pérdida de datos? ¿Cómo sincronizar un evento?
 
Se entiende que en un juego de red los clientes no están perfectamente sincronizados, y este es el error de los que recién comienzan, juegos como Battlefield utilizan metodos de interpolacion muy transparentes para hacernos creer que estamos sincronizados, pero en realidad las instancias de los clientes se encuentran en muchas ocasiones muy disparejas. La interpolación tiene pro y contras por ejemplo la tan odiada "Compensación de Lag" que experimentan los jugadores.
 
Si tu idea es armar un juego con UNET te recomiendo que leas acerca de QoS, que entiendas los canales de UNET y como trabaja Network Transport.
 
Ahora, vamos con las preguntas - ¿Que debo sincronizar?
 
Bien, para la sincronización de la posicion, rotación y la cámara del jugador se pueden utilizar 5 valores decimales. posX, posY, posZ, rotY, rotCamX. Con un paquete que envíe estos datos ya puedes simular un interpolacion en el cliente. 
 
¿Es aceptable la pérdida de datos?
 
Cuando se trata de la sincronización de la posicion estamos enviando 30 Paquetes x segundo, basándonos en VALVE los llamados Network Tick, si 1, 2 o 3 paquetes se pierden no es de mucha importancia debido a que se estará recibiendo constantemente nuevos datos, en caso de la posicion se utiliza un TimeSpan para saber cuando se envió el paquete, debido a que una conexión UDP no nos garantiza la posicion correcta de los paquetes.
 
¿Cómo sincronizar un evento?
 
Existen 2 tipos de eventos, los "Requeridos" y "No requeridos", muy similar a la respuesta anterior, los requeridos son aquellos eventos de los cuales nos tenemos que asegurar que lleguen, por ejemplo el daño recibido o producido, el score, drop o drag de un arma, un disparo, los no requeridos pueden ser eventos de la escena, que pueden fallar por que no afectarían directamente al cliente.
 
 
 
Tu caso en particular. Instanciar un objeto en la posicion correcta.
 
Bien, partimos de que estas enviando desde un cliente la posicion de Instancia, esto es un error grave debido a "La interpolación", ¿Como solucionarlo?, creamos un paquete, que indique qué objeto va a spawnear y desde donde, en este caso, se spawnea una "bala" desde X cliente.
 
Cliente -> Enviar evento de instanciar bala al servidor -> Servidor -> Envía a todos los clientes el evento de instanciar bala -> lo clientes instancian la bala en el lugar donde actualmente tienen sincronizado dicho jugador. 
 
¿Se entiende?
 
Veamos un Código de Ejemplo.
 
El cliente que efectúa el disparo.
 

private void Shot()
{
  //Ejecutar instancia local..
  
  //Enviar evento al Servidor...
  var pkg = new NetworkSyncEvent{EventID = 1, Data="ID_OBJETO_BALA"};
  NetworkServer.Send(pkg);
}
public class NetworkSyncEvent
{
  public int EventID;
  public string Data; // De ser necesario para enviar alguna informacion, en este caso el id del objeto a instanciar.
}

 
El cliente que recibe el evento.
 

private void NetworkEjecuteSyncEvent(NetworkClient sender, int eventID, string data)
{
switch(eventID)
{
   case 1: 
   {
      int id_object = int.Parse(data);
      Instantiate(Network.SyncObject[id_object], sender.position, sender.camera.rotation);
   }
   break;
}
}

 
Los clientes locales no son iguales a un cliente remoto, es decir, UNET es simple, pero a la misma vez poco escalable.
 
 
 
Recomendación:
 
Intenta programar tu propio servidor UDP/TCP, experimenta con Sockets, a la larga te vas a dar cuenta de que UNET te limita a muchas cosas, hablo de "HLAPI".
 
LLAPI es otro mundo, un gran trabajo de Unity Technology el problema es que no liberan Network Transport y los desarrolladores no están muy dispuestos a distribuir el código del servidor junto con el del cliente. 
 
 
 
Espero te haya servido! 

En pequeños detalles lógicamente se pueden sacar pros y contras, el problema es cuando queres realmente producir, la manera de trabajar no es óptima, tiene algunas cosas que no me convencieron a primera vista , mi crítica fue muy por arriba,  la base del motor el "Game Loop" no está armado de la mejor manera, obvio que Unity tiene muchísimo ingenieros detrás solucionando todos los bug.
 
En cuanto mi opinión voy a darle otra oportunidad, ya que ustedes me están dando buenos puntos de vista. ¿Se puede programar en C++?¿probaron Shiva3D?
 
 
 
¿Están utilizando la version 1.9.3 BETA? ¿vieron algun error en chino?
 
En cuanto termine de probar otras cositas pendientes vuelvo a comentar.. 
 
 
 
Retiro lo dicho anteriormente, que idiota soy, aca esta toda la DOC, por alguna razon el dia de ayer entre a una web desactualizada de XENKO... Se ve fantástico... 
 
http://xenko.com/features/#ui_editor_popup

Es muy malo, el parecido a Shiva, son motores que en realidad dan mucha pena, la interface te perdes, no sabes si esta bien o mal, apretadas algo y se cierra todo, errores en chino.. 
 
Cada vez que queres probar tenes que compilar, osea una mierda, shiva tiene un test en el editor, y es multiplataforma, ahora voy a estar viéndolo, de todos modos Unity es muy superior..
 
Torque3D - Malisimo, encima de pago.

CryEngine - Prefiero Unity si tenemos que pagar.
 
 
 
sigo con los test.. 

Cita de: lightbug date=1487233863Con esto de la noticia de Untiy 2017 ($$) se me dio por hacer una busqueda, mas que busqueda una ojeada a los motores modernos y gratuitos de hoy en dia y me crucé a Xenko Game Engine (mediante el canal de YouTube "Gamefromscratch") .
   
   
      Un motor que hace un tiempo venia ojeando y que pintaba lindo, es de Silicon Studios (japoneses) , open source, basado en C#, con muchas caracteristicas. (Seguro lo recordaran si han visto el video del robot naranja en el museo).