Ey muy bueno para aquellos principiantes, el uso de interfaces es una herramienta muy útil, pero la estas implementado de manera correcta, el problema es la interacción del Player en este caso no es correcto, no entiendo porque compruebas tag si el RayCast solo podría colisionar con "Objetos Interactivos" bastaría solo con utilizar Capas, de hecho no sería ni siquiera necesario el uso de Layer.
 

private void InteractivePlayer()
{
var ray = "Rayo desde el centro de la camara";
RayCastHit hit;
if(Physics.RayCast(ray, out hit, 2))
{
   var interactive = hit.transform.GetComponent<IInteractive>();
        if(interactive)
        {
           Ejecutar la Accion.. .. 
        }
}
}

 
Aunque de todos modos esto es mejor realizarlo con funciones virtuales.
 
 
 
De todos modos buen comienzo.. 

Claro, en Fisica se da por sabido que un cuerpo dentro de otro bajan a la misma velocidad debido a que la gravedad afecta de igual manera a ambos. por lo que tienes que tener controlada la velocidad y la gravedad del jugador cuando se encuentra en plataformas de movimiento vertical.
 
Cuando se trata de movimientos Horizontales entra en juego el rozamiento, algo que da muchos problemas a la hora de la física simulada, en este caso lo mejor es afectar la posicion del Jugador con la velocidad de la plataforma, este es un problema aparte al de un ascensor, Por este motivo dije que el Emparentamiento era una solución simple, pero no la mejor para el caso.

Cita de: lightbug date=1481502644Por que no lo es? muchos juegos sino la mayoria lo usan, depende del tipo de personaje que tengas, si son todos rigidbodies aplicas la velocidad de la plataforma y esta bien, pero si son controllers tenes que ver en que momento el player cae en la plataforma y empezar a moverlo por deltas, casi lo mismo que enparentar. Te comento porque yo trate hasta lo ultimo por no enparentar cosas, me parecia "incorrecto" este metodo. Hace poco me cambie a esto, y se solucionaron todos los problemas con las plataformas moviles 2D y 3D que antes tenia. Y aparte el codigo quedo mucho mas prolijito jaja
   
   
      Saludos
   

El problema se debe a que no es totalmente genérico, yo tambien me encontre frente a estos problemas de plataformas más aún en el 2D, pero en realidad realizandolo con FixedUpdate las cosas se solucionan, lo he probado e implementado en múltiples proyectos y jamas me fallo.. 
 
Pruebalo por ti mismo, evitas emparentar algo no recomendado debido a las escalas y otros factores aplicados al Transform debido al emparentamiento.
 

public class Ascensor : MonoBehaviour
{
    public bool Use;
void FixedUpdate ()
    {
        if (Use) 
        {
            transform.position = Vector3.MoveTowards(transform.position, transform.position + Vector3.up, Time.fixedDeltaTime * 5);
        }
}
}

 
 

El Emparentamiento no es una buena idea, pero si una solución simple y rápida! me había olvidado de esto.

public float Heigth = 100;
public bool IsUse = false;
private Vector3 _startPos;
private void Start()
{
_startPos = transform.position; 
}
private void FixedUpdate()
{
if(IsUse)
   transform.position = Vector3.MoveTowars(transform.position, _startPos + (Vector3.Up * Heigth), Time.fixedDeltaTime * 10);
else
   transform.position = Vector3.MoveTowars(transform.position, _startPos, Time.fixedDeltaTime * 10);
}

 
Deberia andar, pero lo escribí directamente en la WEB es algo muy simple, analizalo y trata de entender la lógica. 

Si el ascensor solo asciende y desciende no es necesario una animación, para dicha acción lo mejor sería hacerlo con traslación de posicion dentro de FixedUpdate y con esto vas a resolver los problemas de saltos, tambien podrás ajustar la altura de parada y de esta manera reutilizar los ascensores.

Cita de: leocub58 date=1481412147pues no destruyas el personaje principal, ni instancies uno nuevo solo tienes que desactivar el animator y hará efecto el ragdoll.
   

Claro, pero si deseas que el cuerpo quede aun después de un Respawn este método no sería viable.

No entiendo que necesitas hacer, ¿Qué sentido tendría instanciar un objeto para aplicarle un ragdoll? ¿Que estaría haciendo Ragdoll en ese caso?.
 
Te explico, por lo general el modelo está separado de la lógica, un error muy común en los desarrolladores de Unity es no darse cuenta de esto. ¿Porque lógica, modelos y ui separados?, en el desarrollo de cualquier proyecto el cambio de una varias partes no tienen que afectar directamente a partes no dependientes, es decir, el modelo de tu personaje puede encontrarse en cualquier lado sin necesitar de un componente que lo controle, podrias cambiar el objeto completo sin necesidad de cambiar parte de tu código o reasignar nuevamente las variables. 
 
Ragdoll es una técnica utilizada en muchos juegos, deja muy buenos resultados, el problema es la mala aplicación de la misma, empieza por separar los modelos de tu código, es decir un personaje tanto en tercera como primera persona necesita sólo 3 datos, posicion, rotación y ángulo de cámara, y esto a la misma vez no tiene que estar emparentado a tu modelo. De esta manera puedes aplicar un Ragdoll del mismo modelo, luego en el Respawn solo creas una nueva instancia del modelo a controlar, es más de esta manera se hace efectivo el uso de PoolObject para evitar instanciar objectos todo el tiempo.
 
Es muy importante conocer los conceptos de la programacion para lograr un trabajo funcional y escalable.
 
 
 
Saludos.

Yo quiero "Server Library"... UNET sin poder crear server dedicado es un robo... -.- 

Cita de: Er_TaloN date=1479298031He estado echando un vistazo, pero hay cosas que tu envías como por ejemplo el tema de la posición, pero si utilizas NetworkTransform(creo recordar), se envía de forma automática. Para qué hacerlo manual ?
   
   
      Te digo esto, desde la ignorancia, he empezado esta mañana a mirar el Network de Unity.
   
   
      Un saludo compañero.
   

En principio la manera en que Sync Transform de UNET trabaja no me es útil, en un FPS necesitas enviar valores todo el tiempo, rotación del jugador y la cámara son 2 valores y la posicion son 3, en total tenes 5 valores, con un simple comando y una buena serialización logre pasar posicion y rotacion completa en tan solo 9 bytes.. sumandoles todo lo necesario para animaciones 8 bytes más, por lo que en total el juego para moverse y ejecutar animaciones solo enviaba 20 bytes por segundo. Leer este articulo https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking para entender de que hablo.
 
En total si sacamos la cuenta por minuto el jugador envía 1200 bytes lo que equivale a 1.18Kb si a esto le sumamos posibles 20 jugadores tendríamos case 2 Mb por minuto. Luego lógico hay que sumar la sincronización de las estadísticas otra cosas que logre pasar en menos de 20 bytes.. 
 
Teniendo estos valores ahora te das cuenta de que es muy importante poder mani***r vos mismo los datos que salen y llegan...
 
En cuanto tenga tiempo voy a cargar nueva información sobre esto.

La primer solución de @GSG3D no me parece la mejor, en principio cada vez que se llame Ejecutar tiene que estar accediendo a métodos de Reflexión algo que consume mucho tiempo, y en un RTS no puedes permitirlo.
 
Por lo general para este tipo de juegos se utilizar varias técnicas, pero la más eficaz es la lista de comandos, un ejemplo práctico AOE 3, si te detienes a analizar los XML de configuración de unidades de AOE te vas a encontrar con un sin fin de ID de acciones, cada ID hace referencia a uno o varios comandos que al final los llaman acciones. Es muy parecido a una base de datos, donde tienes tu tabla Action y Commands, digamos que en action puedes agregar múltiples comandos para un solo ID, relacion de Uno a Muchos. 
 
Una vez que tienes estos Comandos, es hora de programar de qué manera se van a ejecutar en cada Actor. Para esto, te recomiendo utilices simplemente una referencia a una clase llamada Action, es decir.
 

public class Actor 
{
public class Action action;
public void EjectueAction(int CommandID)
{
   action.Ejecute(CommandID);
}
}

 
y luego tus clases de acción.
 

public class Action
{
public virtual void Ejecute(int CommandID)
     {
}
}
public class Action_test : Action
{
public override void Ejecute(int CommandID)
{
}
}
public class Action_test2 : Action
{
public override void Ejecute(int CommandID)
{
}
}

 
De esta manera es la más eficiente, siempre y cuando cada ID de acción ejecute eventos diferentes para cada Actor.
 
Hay que tener bien separado los Eventos de las Acciones, esto lleva tiempo y muchas veces hasta una reconstrucción por completo de la base del juego, si tienes pensado luego añadir un multi jugador entonces de la manera que te estoy recomendando luego vas a evitarte muchos dolores de cabeza.
 
Hace ya varios meses vengo programando un juego de cartas, que si bien no es un RTS tiene planteamientos similares, y este creo, fue uno de los que más tiempo me llevó, en cuanto a investigación, práctica y correcto funcionamiento. 
 
 
 
Un abrazo suerte.

Cita de: Er_TaloN date=1479289452Gracias por el tutorial, me sirve para aclarar algunos conceptos jeje.
   
   
       
   
   
      Saludos!
   

De nada.. En el blog vas a encontrar mas material.

Se puede deber a que la variable "vida" sea un campo estático, o bien, porque OnTriggerEnter está detectando varios objetos.
 
Dudo mucho de que sea un campo estático por la forma de acceder a dicha variables. Verifica que On Trigger este solo colisionando con el objeto deseado.

Claro, si vos necesitas que la información perdure al cerrar Unity Apagar la PC u otros entonces requiere de que guardes la información en algún lugar. Si se trata de una herramienta fijate que podrias utilizar la misma carpeta del proyecto pero un nivel atrás  "../ASSETS" para entonces poder configurar de formas diferentes cada proyecto y pasar de proyecto en proyecto las cosas no se sobre escriban. 
 
 
 
 

Pero, los campos estáticos no se pueden serializar, y segundo la lista no está inicializada por lo cual no vas a poder utilizarla.
 
Deberías serializar a byte y guardarlo dentro de un TXT o cualquier archivo y cada vez que vuelvas a utilizar la clase carga desde dicho archivo los datos de la lista.