Prueba aplicando la rotación desde LateUpdate y fíjate si pasa el mismo problema. Utiliza las propiedades locales. Ya que como muestras en el vídeo estás utilizando la rotación local.

El problema que el compartimiento que buscas va más haya de los IK que maneja Unity, deberías programar dichas "situación". Pasa lo mismo con Foot IK, con AIM tienes que programar la rotación de los brazos y la inclinación de la cadera para que sea un poco más realista. 
 
Tendría que probar si tirando de un brazo el cuerpo realiza la inercia pero no creo. 
 
Otra solución sería activar ragdoll en algunas partes del cuerpo. Fíjate con esto, quizás logras algo de lobtebesras buscando, aún que lo correcto sería IK

Cita de: Eskema date=1525087308 
   
   
      La logica en el server nos la saltamos porque creemos y confiamos en el player, deberiamos poner la logica en el server pero se penso que no era necesaria esa capa porque ya hemos validado la tirada. 
   
   
      Validamos que el player 1 ha lanzado una carta y el server le ha dicho "carta ok, no esta trucada", entonces se la enviamos al player 2 via photon. Como decia alguien podria interceptar la llamada de photon y cambiar la carta... pero cuando el player 2 fuera a lanzar su carta (en el siguiente turno) se veria que no coincide y el juego se quedaria bloqueado/se cerraria, le explusariamos de la partida, etc.
   
   
      El tema compras va por nuestro server tambien. Tu quieres comprar algo asi que vamos a la api de android o de ios (a sus sitema de IAPs) y sacamos el item y demas, Una vez comprado se valida la compra con nuestro server, en caso de fallo la compra se anula. 
   
   
      En nuestro caso ademas las compras NO se hacen ingame, mientras juegas no se puede comprar nada, las cartas nuevas se compran en el menu, tras acabar la partida o antes de empezarla, con lo cual con el sistema de pagos de apple/android mas la validacion del server es mas que suficiente para saber que nadie te hackea, porque para eso la llamada al server la hace el cliente logeado previamente y validado, si algo no coincide porque han intentado cambiar el token de sesion el server le dice que "una mierda que te comas".
   
   
       
   
   
      La unica parte como digo donde "flojeamos" con la seguridad es que el player 2 cuando recibe la carta no se valida, se da por hecho que viene la carta correcta, y aunque se hackee, la tirada se ejecutara, pero como luego al lanzar la carta que sea se vera que hay una inconsistencia pues... le sacaremos de la partida y lo marcaremos en el server como tramposo xD. Osea que le damos al jugador tramposo unos segundos en los que parece que todo esta ok y se cree que nos la ha colado, para luego en su tirada sacarlo de la partida por tramposo xD.
   
   
      Como digo con este sistema nos ahorramos tanto el tener que validar las cosas tantas veces, no sera el mejor ni de lejos, pero hasta la fecha hackeos hemos tenido 0, intentos muchos xD
   

Genial, quizas suena un poco "inseguro", pero viendolo desde ese punto puede que funcione y te ahorres cierto "USO" por parte del servidor, en mi caso, veo poco fiable que el jugador ejecutará la Lógica debido a algunos factores en el gameplay, pero me gusta la idea que implementaron, quizas haga unas pruebas de esa manera en otros juegos que tengo aún por desarrollar -
 
¿Como se llama el proyecto en el que estás trabajando actualmente?

Gracias @pioj ....

Cita de: Eskema date=1525081920 
   
   
      En el caso que me ocupa, y el "hearthstone" que cree en una empresa en la que estuve trabajando funcionaba de la siguiente forma.
   
   
      -el jugador entra en el juego, se conecta al server y nos bajamos su json con sus datos, su mazo de cartas, etc, etc.
   
   
      -cuando se inicia una partida online, se llama a nuestro server para decirle que "manolito" quiere jugar online, se espera a que alguien conecte (via photon) y esa segunda persona tambien ha enviado al server el tipico "hola soy pepe y quiero jugar".
   
   
      -una vez encontrados y matcheados via photon, ambos le envian al server nuestro el "ok estamos listos para jugar", y arrancamos la partida
   
   
      -cada cliente se encarga DE TODO, el juego transcurre a nivel local y el server solo se usa para lanzar cartas.
   
   
      -cuando el player 1 lanza una carta, se la envia a nuestro server, si la carta es ok (coincide, no se ha trucado, etc), entonces se le envia la carta jugada al player 2 via photon
   
   
      -player 2 la recibe y replica la jugada de player 1. (por supuesto alguien podria interceptar el paquete y poner otra carta en juego, no se valida aqui nada)
   
   
      Tal cual, sin mas seguridad ni nada, ¿que se puede hacer de otra forma?, pues seguramente habra mil formas mejores, pero creemos que con este nivel de seguridad era bastante para quitarnos de encima a los scriptkids, porque esta claro que a un hacker con ganas no lo vas a parar....
   
   
       
   
   
      Respecto a los timers, tengo un id que recorre la lista, de forma que no recorro toda la lista siempre, el "for" empieza en la ultima posicion asignada. La ganancia es minima como suele pasar pero algo es algo.
   
   
      ¿Por qué una lista?, ¿y por qué no?, quiero decir, ¿que otra estructura gastarias?, ¿un diccionario?, ¿una queue?. No vi ninguna estructura que me fuera mas rapida para como lo tengo montado (de estructuras "nuevas", el array no lo discuto).
   
   
      Podria ser un array de toda la vida que es mas optimo que una lista y si un dia tengo ganas probablemente lo cambie a array. Los arrays son mas rapidos que las listas y al fin y al cabo es una lista "estatica", una vez creada no se modifica, solo se recorre y se actualizan los timers activos, no se añade nada ni se modifica nada. Dado que la lista es fija y no cambia no hay motivo para usar la lista, aparte claro de una cuestion de comodidad y vagancia xD
   

Genial - Es similar a lo que estoy haciendo yo, la diferencia es que la lógica la mantiene el servidor, ya que no contiene ninguna propiedad 3D, no utilizo photon, creo que es un servicio que se adapta a otro tipo de juegos, ya que estamos hablando de algo basado en turnos, con muy pocos paquetes en cada partida.
 
Por lo demás, quizas comparta mi librería de Networking para que le peguen un OJO, está estable, y totalmente funcional es algunos proyectos, tiene algunas características que a mi gusto hacen que el desarrollo de un backend se super simple.
 
La tienda para comprar cartas u otros objectos¿Con que servidor lo hacen? -
 
La pregunta va por lo siguiente, vos inicias el juego y te conectas a un MasterServer, el master server tiene el servicio de sesión de usuarios, para realizar una compra, ¿no pasas por la sesión activa del master server?, veo que el interés por la seguridad no es un problema, pero pienso, seria muy facil de hackear si no se tiene un servicio de sesión activo. <---- hago hincapié en que en estos tipos de juegos los sobres de 5 cartas tiene un valor real U$D por lo que sería preocupante la clonación de sesione, imagino que utilizan un método de encriptación de punta a punta.

Cita de: Eskema date=1525069139Nunca he sido programador de backend, bastante tenemos los programadores de juegos con hacer un juego como para meternos en ese tipo de marrones xD. Mas alla de programar el multijugador con sockets/photon/loquesea, nunca he hecho nada de networking por la parte server. Y no es un area que me llame, demasiado nos especializamos en este sector como para querer abarcar tantas areas :/
   

Pero entonces, ¿los recursos de un Backend son consumidos mediante el protocolo de conexión establecido?, WebRequest, Sockets, Etc? Por la experiencia que tengo, el backend se desarrolla antes que el Front o en su defecto en paralelo, pero, ¿como controlas las sesiones?, ¿La lógica del juego? - O simplemente creas la plantilla con las características requeridas y luego el "Contratista" se encarga de transportar el proyecto a una capa Networking.
 
Siendo WebRequest - Sockets - o cualquier otro tipo de transporte existen métodos de validación, encriptación, creo son parte importante del FrontEnd para el "Debug" - ¿Como logras crear los test? 
 
Me gustaria saber, obvio si no es molestia de tu parte contestar -
 
Estuve viendo el video de los Timers, no pude llegar a estar en el streaming, me gusta la implementación y la abstracción, algunas cosas me sirvieron como idea, el "Pool" si tiene un tamaño asignado desde el inicio ¿Porque lo trabajas con una lista?, se me ocurre que podrias utilizar un arreglo, trabajar con "unsafe" y "fixed" para optimizar el recorrido del bucle en un 100% por otro lado, cuando reciclas un objeto del pool podrias guardar el índice un una variable, entonces la próxima vez que requieras un objeto puedes evitar recorrer parte de las lista, estos "tips" mejorarán en un 100% el tiempo en los timers - Es solo como un aporte. Como tu lo dijiste mil veces, para gustos colores - 

Cita de: Eskema date=1524987440Por razones "obvias" no, no voy a currarme el server. Primero y principal porque no tengo ni idea xD, no soy programador de backend. Yo solo estoy creando el proyecto simulando que las cartas se bajan de un server y tal, y lo mismo al jugarlas. Crear un server se escapa de la tematica, "un curso de unity".
   
   
      En un juego asi para un cliente hicimos eso, al abrir el juego entrabas con tu cuenta y te bajas el mazo de nuestro server seguro, luego al jugar online contra alguien, tu no sabes que cartas tiene el otro, solo sabes de su carta en el momento de jugarla cuando la recibes online, sea via photon u otro servicio. En nuestro caso no habia logica online, con la conexion cifrada ya era bastante para evitar "pesados" y curiosos. Y poco mas a nivel "online"
   

Ha, entiendo...
 
- Suerte entonces - Yo estoy especializandome en Networking desde hace varios años, tanto en la programación como en lo relacionado, ya tengo los cursos de CCNA(CISCO) realizado más una gran variedad de VMWare relacionados a la red, aparte de que tambien tengo estudios en virtualización - 
 
Tuve la oportunidad de ver cómo se estructuran los servicios de Blizzard, por eso lo comentaba arriba, y me parecía algo loco un proyecto así para un Tutorial, pero bueno, tenia la loca idea de que ibas a programar el Backend + Front <--- El trabajo que vengo realizando yo desde hace bastante tiempo, tratando siempre de seguir las normas que requieren hoy en dia tener dichos servicios.
 
¡Networking! - @Igor, es un tema bastante complejo, pero una vez entiendes las bases todo se facilita bastante, pero debes aprender desde lo más básico, aún si vas a utilizar servicios como Photon, te recomiendo aprender Sockets, crear tus propias "librerías" de Network Game basadas en TCP y luego cuando ya entiendes un poco te pasas a UDP para dar el salto a la gloria, una vez domines UDP el resto es cuestión de prueba y error, te vas a encontrar con preguntas como ¿Esto es lo mas optimo?, y luego ya pasas a cosas un poco más complejas como la multiplataforma, la compatibilidad con IPv6, NAT, Ataques DoS, Encriptación, Protección de Datos, Programación en Capas, vas a descubrir rápidamente la programación TDD <<< --- UNA VERDADERA JOYA para el debug.
 
En fin, me interesaba esa parte para compartir un poco de conocimiento.
 
@pioj Por qué no crear un sección "Networking" entonces vamos aportando dudas o material