@lightbug Jajajaja, Gracias por el mérito. Últimamente (desde principio de año) estoy bastante inactivo (en cuanto a respuestas) en el foro, entro reviso todo los temas nuevos, veo los mas interesantes y contesto los que puedo, muchas veces me pasa que estoy contestando algo y digo ¡Uff que complicado que es explicarle esto a alguien que no sabe!, entonces pienso, que vos le vas a contestar.. y así es. @Igor tambien da buenas respuestas. Somos algunos los que aparecemos en todos los topics dando un poco de cariño..
 
¡@lightbug! Te vengo mordiendo los talones (o-O) ~ Jajajajaja
 
 
 
Lo único que me hace entrar al foro día a día es el excesivo compañerismo, el respeto y lógicamente los troll espontáneos.
 
 
 
Por otro lado paso el "cheat" que utilizar @lightbug http://www.cheatforscoreinunityspain.com/hjgisjd2" rel="external nofollow">Página del Cheat

Por lo que intento entender del código estas intentando hacer un Selector de Coches.
 
Primero -
 
1º Crear un Arreglo de GameObject, luego asignar todos los coches en escena.
 

public GameObject[] Coches;

 
2º Crear la lógica para seleccionar el siguiente o el anterior.
 

private int _current;
public void Next()
{
_current ++;
if(_current >= Coches.length)
   _current = 0;
OnChange(_current);
}
public void Last()
{
_current ++;
if(_current < 0)
   _current = Coches.Length -1;
OnChange(_current);
}           
                    
private void OnChange(int index){}

 
3º Necesitas obtener el actual objeto.
 

public GameObject GetCurrent { get { return Choches[_current]; } }

 
4º Crear la lógica para Activar y desactivar los objeto, crearemos una variable GameObject para almacenar temporalmente el objeto actual, luego dentro de la función OnChange vamos a hacer lo siguiente
 

private GameObject _lastObject { get; set; }
public virtual void OnChange(int index)
{
if(_lastObject != null)
   _lastObject.SetActive(false);
_lastObject = GetCurrent();   
GetCurrent().SetActive(true);
}

 
y eso seria todo.
 
 
 
Luego desde los Botones de UGUI seleccionas el componente y llamas la Función Next o Last.

Cita de: Igor date=1523392173
   
   
      nuevo escenario en proceso
   

Sera por que uno esta dentro de este mundo, pero por que cuando se ven estas capturas te da esa sensación de "¡Que genial!", me gusta hacer capturas de pantallas y guardarlas para luego hacer time lapse de mis proyectos, es muy satisfactorio ir viendo el progreso..
 
Buen trabajo, me gusta el estilo  

podrias hacerlo de la siguiente manera.
 

private T GetResource<T>(T type, string key) where T : UnityEngine.Object
{
//Verificar que no exista el objeto en el diccionario
//Si el objeto existe en el diccionario verificar que el tipo es el correcto
  
     StartCorrutine(IEDownloadResource(string.Format("http://mycompany.com/resources/{0}/{1}", type, key), (www)=>
     {
        swith(type)
        {
           case typeof(Texture) : /*logica de imagen*/ break;
           case typeof(AudioClip) : /*logica de audio*/ break;          
        }
     }));
}
  
private IEnumerator IEDowloadResource(string url, Action<WWW> callBack)
{
  WWW www = new WWW(url);
  yield return www;
  callBack.Invoke(www);
}
  

 
De esa manera lo haría yo...
 
Lo escribi desde la WEB puede tener errores saludos.

Dale! -
 
Tengo algunas cosas que podría ser de ayuda, pero primero intenta entender a fondo cómo funciona.
 
1º Te recomiendo familiarizarte con Socket UDP en C#, no uses UdpClient, hazlo todo desde cero.

2º Intenta recrear un sistema como TCP donde un cliente se conecta el servidor lo valida y lo agrega a una lista de clientes para luego ser utilizados.

3º Intenta crear un escritor binario para la serialización de paquetes.

4º Intenta crear una arquitectura donde puedas enviar y recibir paquetes personalizados entre el servidor y los clientes.
 
Si dominas ese 4 pasos, podrias pasar a hacer pruebas con sistemas más complejos como Relay Server, Master Server.. Etc.. 
 
Para el networking utilizó un sistema basado en Plugins, el cliente y el servidor tiene plugins.. 
 

 
Fijate que el Servidor y el Cliente tiene plugins, y cada uno tiene su respectiva lógica.

Cita de: datmos date=1523174805Buenas!
   
   
      Pues el TargetRPC lo leí en su día pero como aún no sabia nada del networking lo deje atrás temporalmente. Parece muy útil para solventar ciertas situaciones, tengo que hacer pruebas con el.
   
   
      Des de que me respondiste estuve la tarde leyendo, empapándome de mas teoría y me encontré con algo que te quiero preguntar, lo haré al final.
   
   
      Puedo utilizar mi lógica para suponer a que te refieres con lo de "los RPC no deberían tener conexión con el servidor", pero para que no me queden dudas o por si acaso voy errado me lo podrías explicar porfa?
   
   
      Con la estructura de datos, me pasa lo mismo, puedo verle un sentido a lo que comentas pero no lo veo en la practica.
   
   
      Estoy aprendiendo a entenderlo, obviamente no busco soluciones, busco la manera de ponerlo en practica, hacer pruebas y entender el funcionamiento de lo que me comentas, así que disculpa tantas preguntas pero es un terreno complicado (o al menos a mi se me hace complicado) y llego a el des de cero.
   
   
      Por cierto tambien me contre con esto: https://docs.unity3d.com/Manual/UNetVisibility.html . Me parece algo muy interesante, voy a estudiarlo y probarlo.
   
   
       
   
   
      Lo que te comentaba al principio que encontré ayer leyendo por internet, es a gente con bastante experiencia con uNet comentando que al final se pasan a otra Network Solution como Photon, etc, por muchos motivos, tales como la falta de documentación, ejemplos, la falta de actualizaciones por parte de Unity sobre uNet/HLAPI..., limitaciones en cuanto a estabilidad cuando la cantidad de jugadores en el servidor es "alta" (en plan, mmo, survivals, etc..), la sensacion de abandono de este apartado por parte de Unity... Y muchos mas motivos que algunos de ellos no puedo comentar por que ni los entiendo ya que son demasiado técnicos para mi. Pero ademas lo que me sorprendió es la gran cantidad de gente que respondía a estos posts que estaban de acuerdo con el, osea que pensaban igual.
   
   
      Y esto me da que pensar, realmente me vale la pena seguir aprendiendo uNet? No tendrá mas futuro (a corto y medio plazo al menos) aprender otra solución? En su momento tiré por uNet sin dudarlo porque no quería depender de un tercero, ya que si salen actualizaciones de Unity deberemos esperar a que ese tercero saque una actualización también.
   
   
      Pero bueno, si la diferencia es tan importante quizas vale la pena cambiar, no lo se. Ademas quiero aprender a hacer funcionar muy bien uNet/Photon/lo que sea, antes de hacer crecer un juego, creo que es bueno ir programando el networking al mismo ritmo que crece el juego.
   
   
       
   
   
      Voy a seguir leyendo cositas mientras espero tu respuesta
   
   
      Gracias!
   

Definitivamente UNET no es lo mejor, PHOTON es algo más complejo. Pero en ningún caso es bueno utilizar HLAPI esto dejalo para la gente que no tiene idea de cómo se comportan las cosas.
 
Conceptos 
 
Servidor: son los SOCKETS encargados de la transmisión de información desde un Dispositivo a Otro. este se suele basar en 2 protocolos TCP y UDP, las diferencias entre podes buscarlas en google, pero para resumir de una manera "brutal" TCP es como HLAPI de UDP (No es así, pero te puedes dar una idea).
 
Cada Socket requiere un PUERTO, en el caso de los Servidores, el puerto debe ser siempre el mismo o estar dentro de un rango controlado, por lo que si el puerto utilizado por el servidor ya está en uso en el dispositivo HOST este no funcionara.
 
Cliente: nuevamente SOCKETS.
 
¿Como haces para que un Socket sepa de dónde viene cada Paquete?

Cada conexión que recibe el Socket del servidor contiene la información del emisor "EndPoint" dentro de este objeto tenes algunos datos como la IP y el Puerto utilizados para dicha conexión. Cuando se trata de conexión el puerto no es especificado por el cliente, si no, se toma uno libre. es decir, EJ:
 

1. 
      Conexión : Puerto 2555
   


2. 
      Conexión : Puerto 2556
   

Esto se debe a que debemos estar seguros de que la información recibida por el sockets es en cierta forma la esperada.
 
 
 
Funciones -

Los clientes deben mandar cada x tiempo un paquete de vida al servidor.

El servidor debe controlar en cada actualización si cada cliente está vivo << esto se hace observando el tiempo del último paquete de vida. 

El servidor envía paquetes a X cliente.

El servidor envía paquetes a Todos los clientes.

El cliente envía paquetes a el servidor.
 
¿Qué son los RPC?

Como los clientes no pueden enviar un paquete a otro cliente, la única vía posible es pedirle al servidor que lo haga. Imaginemos el siguiente escenario, tienes un amigo viviendo en otro país, para enviarle una carta no te queda otra solución que hacerlo por correo. esto mismo para en la estructura Cliente/Servidor.

 
 
¿En qué casos un cliente requiere enviar un paquete a otro cliente en particular?

El más fácil de ejemplificar es en un chat, existen 2 tipos, un chat global y un chat privado, pero, ¿Como se puede hacer?, primero debes saber el UID otorgado por el Servidor de cliente que necesitas enviar el mensaje. luego, envias al servidor un paquete de chat. supongamos que dicho paquete tiene la siguiente estructura.
 

public class NETPKG_Chat
{
public enum EType
    {
   Public,
   Private
    }

public EType Type;
public string Message;
public int TargetUID;
}

 
Deberíamos de crear una instancia con los valores deseados. new NETPKG_Chat {Type = EType.Private, Message = "Mensaje de Prueba", TargetUID= IdDelCliente }; luego deberias crear la lógica para que el servidor sepa que hacer con x paquete y sus valores.
 
Todo esto sucede en UNET la diferencia es que HLAPI intenta solventar problemas relacionados a la estructura del motor, como por ejemplo la instancia de Objetos Remotos, la sincronización de Network Behaviours, la compilación de Command, RPC, etc. ¿Esto es un problema?, desde mi punta de vista, si, creo que cada desarrollador debería armar lo justo y necesario para su proyecto.
 
En mi experiencia he armado FPS bastante completos con UNET, el problema es que terminas teniendo grandes dolores de cabeza por la Incoherencia contextual que existe en la escritura del código, me refiero a que un Componente no autoritativo tiene lógica del servidor dentro, no tiene sentido, creo que las cosas deberían estar separadas y bien definidas.
 
Si estás interesado en Networking te recomendaria ver soluciones como LIteNetLib es bastante simple de utilizar. o eNET, un poco más compleja pero nada que envidiarle a LiteNetLib, como dato interesante el Core de Photon está basado en eNET.
 
Entonces, en resumen, ¿qué es lo que nos provee UNET que en cierta forma es aceptable? NetworkTransport, es quien se encarga de toda la lógica de Sockets y nos da una comodidad excelente para trabajar, la gran desventaja es que no podemos crear un servidor basados en Network Transport, debido a que solo funciona en UNITY, están en la duda de liberar una librería... Pero no creo que esto sea posible, apuntan a un Cloud Server por lo que intentan realizar un servicio de PAGO sin posibilidades de poder montarlo en otra plataforma.

Averigua sobre TargetRPC.
 
Estás bien encaminado pero tenés problemas de lógica repetida, deberías definir los model shared y por otro lado la lógica. 
 
Si el servidor es enteramente autoritativo entonces los RPC no tendrían que tener conexión con la información del servidor. 
 
Para que no tengas problemas deberías de crear una estructura de datos para el cliente y luego utilizar la misma para cada netPeer.
 
Si necesitas más ayuda podemos seguir este hilo. 

NavMesh teniendo solo 4 vehículos sería bastante viable, si el juego es para PC.
 
Podrías basarte en un PathFinding básico por un grid con slot de un tamaño considerable, y que los muros al ser creados ocupen dicho slot... Lo de siempre.
 
 
 
 

Cita de: Igor date=1522929828no sabia que esto se podia hacer....
   
   
      siempre se aprende algo nuevo...
   

Puedes usar el predicado en la función Where o Count.