Yo tuve hace poco el mismo problema (aplicado a 3D).
 
También hacía lo de ponerlo debajo en la jerarquía, pero al parecer, como estaba haciendo uso de RigidBody no era buena idea.
 
Al final, puse en un hilo, una posible solución (tendrías que adaptarlo a 2D y en el ejemplo hago uso de RigidBody) en la que no es necesario ponerlo como hijo en la jerarquía.

 
 

Cita de: nomoregames date=1585567656Bien...
   
   
      AngelFG... tu script es lo mismo que publicaba francoe
   
   
       
   
   
       
   

No exactamente lo mismo...si te fijas en el ejemplo de franceo normaliza la distancia y después, al multiplicar por 1.3f, siempre va a estar a esa distancia fija con respecto a 'a'. Por lo tanto, si 'b' se acerca a 'a' estará más cerca del centro, que es lo que comentaba nomeregame como respuesta a la solución anterior.
 
Mientras que en mi ejemplo no normalizo y eso hace que la distancia se mantenga en la misma proporción (o eso creo si no me equivoqué al hacer el ejemplo )
 
En mi ejemplo siempre se encontraría al 30% del espacio entre 'a' y 'b' independientemente de la distancia entre ellos....
 
 
 
 

A lo mejor no te estoy entendiendo muy bien....
 
¿ Esto no valdría ?
 

public class DistanciaEntre : MonoBehaviour
{
    [SerializeField]
    private Transform mouse;
    [SerializeField]
    private Transform player;
 
    private Vector3 distancia;
    // Update is called once per frame
    void Update()
    {
        distancia = (mouse.position - player.position) * 0.3f;  // Cambia el 0.3 por la distancia fija a la que quieras que esté
        transform.position = player.position +  distancia;
        
    }
}

 
 

Gracias por el aporte.
 
Yo hace tiempo que tenía un enlace Unity en que ya comenta alguna de las optimizaciones que indicas.
 
Lo pongo por si a alguien le resulta interesante: https://learn.unity.com/tutorial/fixing-performance-problems#5c7f8528edbc2a002053b594
 
Y otro de vídeos con diferentes técnicas para optimización: https://learn.unity.com/search?k=["tag%3A5814ded032b30600246b5d0e"]

Gracias a los dos por contestar. Me ha quedado más claro todo.
 
Y gracias a pioj  por poner mejor el post. Tomaré nota para la próxima vez en el uso de etiquetas...
 
Pensando en la idea de lightbug de hacer que al protagonista se le sume la velocidad de la plataforma, se me ocurre este código (para a quien le pueda valer)
 

    // Script asociado al protagonista. 
    [SerializeField]
    public GameObject plataforma;
 
    private Rigidbody rb;
    private Rigidbody rbPlataforma;
    // Start is called before the first frame update
    void Start()
    {
        rb = GetComponent<Rigidbody>();
        rbPlataforma = plataforma.GetComponent<Rigidbody>();
    }
 
    private void FixedUpdate()
    {
       float hor = Input.GetAxis("Horizontal") * 5;
       float ver = Input.GetAxis("Vertical") * 5;
        if (hor == 0 && ver == 0)
        {            // Tenemos que poner esta condición para que cuando se mueva no reste o sume la velocidad de la plataforma a su velocidad
            Vector3 velocidad = new Vector3(rbPlataforma.velocity.x, rb.velocity.y, rbPlataforma.velocity.z);   // La velocidad y la dejamos para que tenga en cuenta la gravedad
            rb.velocity = velocidad;
        }
        rb.velocity += hor * transform.right + ver * transform.forward;
 
    }

 
Seguramente lo estaré liando más
 
Este script hace que un objeto B se mueva como otro objeto A, pero al mismo tiempo se podrá mover libremente.
 
También funciona con la gravedad activada siempre que los dos (A y tengan el mismo rozamiento (Drag)

Muchas gracias por responder.
 
La idea es hacer que al subir a una plataforma (objeto A) el protagonista (Objeto se mueva con la plataforma y al mismo tiempo pueda moverse.
 
Buscando por internet, la solución que dan es la de hacer el transform.parent de B = transform del A: https://answers.unity.com/questions/167404/rigidbody-on-a-platform.html?_ga=2.71220112.143840515.1583333028-1717286999.1553115133
 
Haciendo más pruebas, resulta que moviendo la plataforma con rb.velocity, no hace falta hacer que el protagonista sea hijo de la plataforma, al caer sobre ella, ya se mueve con ella y si lo muevo con velocity se desplaza por encima de ella....pero si muevo la plataforma con rb.MovePosition, estonces no funciona.
 
Es que Unity es un poco contradictorio. En la documentación viene a decir que hacer un MovePosition es equivalente a realizar un transform.position y que sólo se emplee cuando el RigidBody es Kinematic. Yo entendía que si hacemos kinematic, deja de actuar la física y el movimiento se debería de realizar haciendo uso del transform, ya que el rigidbody es como si no existiera. Por otro lado, MoveRotation no dice nada que tenga que ser Kinematic.
 
 
 
Entiendo que como está no sería la forma óptima, pero tenía curiosidad por qué si pongo este código al protagonista que es hijo de la plataforma:
 

   
       
   
   
      private void FixedUpdate()
          {
            float hor = Input.GetAxis("Horizontal") * 50 * Time.deltaTime;
             float ver = Input.GetAxis("Vertical") * 50 * Time.deltaTime;
   
   
              Debug.Log("Transform:" + transform.position + "- RigidBody" + rb.position);
          }
   
   
       
   

[/quote]
 
Puedo comprobar como transform.position se mueve y el rb permanece en su posición (lo correcto)
 
Y si añado este código: rb.MovePosition(transform.position + rb.transform.forward * ver + transform.right * hor);
 
se queda quieto, cuando transform.position debería guardar la posición del protagonista 'movido' por la plataforma (al estar debajo en la jerarquía) y que es lo que aparece en el Log si no pongo la orden MovePosition.

Hola a todos.
 
A ver si me podéis ayudar...
 
Tengo dos gameobjects con RigidBody y collider asociados, movidos por la física.
 
A es el padre y B es el hijo en la jerarquía, situado encima del objeto A (pos Y más  arriba)
 
Ya sé que el rigidbody del hijo no se actualiza aunque se mueva el padre.
 
La situación es la siguiente:
 

• 
     El objeto A se mueve de izquierda  a derecha de forma continua empleado su rigidbody y método MovePosition
  


• 
     El objeto B se mueve con el objeto A, manteniendo su posición relativa.
  

Si en el objeto B hago esto en el método FixedUpdate:
 

   
      Debug.Log("Transform:" + transform.position + "- RigidBody" + rb.position);
   

[/quote]
 
compruebo que su rigidbody.position no se mueve, pero sí su posición GLOBAL (transform.position). Su posición relativa (transform.localPosition) no se mueve.Hasta aquí lo entiendo, todo correcto. Ahora quiero mover el objeto B al pulsar una tecla, pero que siga desplazándose al mismo tiempo, por lo que tengo este código asociado a B:
 
 

   
       
   
   
      private void FixedUpdate()
          {
            float hor = Input.GetAxis("Horizontal") * 50 * Time.deltaTime;
             float ver = Input.GetAxis("Vertical") * 50 * Time.deltaTime;
   
   
              Debug.Log("Transform:" + transform.position + "- RigidBody" + rb.position);
              rb.MovePosition(transform.position + rb.transform.forward * ver + transform.right * hor);
          }
   
   
       
   

[/quote]
 
Esto da como resultado que el objeto B ya no se mueva con el padre y que sólo se mueva por la pulsación de las flechas (ejes virtuales).
 
 

Buenas noches a todos.
 
Como aporte a  esta comunidad estoy escribiendo un manual de Unity para los alumnos del Ciclo Superior de Programación de Dispositivos Móviles.
 
Aún no está acabado, pero ya hay secciones bastante interesantes para ver, como la de materiales y animación.
 
Espero que os sirva.
 
https://wiki.cifprodolfoucha.es/index.php?title=Programacion_de_videojuegos_con_UNITY3D
 
Un saludo.
 
 
 
 

Gracias por responder al mensaje.
 
 
 

   
       
   
   
      la verdad no estoy al 100% seguro de esto pero si querés que las físicas tengan conocimiento de un objeto ponele un RB. SI querés que además no simulen al objeto dentro de su mundo de velocidades/aceleraciones ponelo como is kinematic. Las animaciones (animator) es ejecutado en una parte específica del ciclo de Unity (creo que despues de LateUpdate), por lo tanto no se que tan "necesario" sea marcarlo como kinematico. 
   

[/quote]
 
Esto sería interesante de confirmar ya que de esta forma no habría necesidad de hacer 'más complejo' el GameObject (lo de complejo por la siguiente pregunta)
 
 
 

   
      Eso se logra moviendo (kinematico o dinámico) a un objeto que no te ofrece animaciones, por ej una capsula o una caja, que es lo que realmente iteractua con el mundo. La animación la tendrá la parte visual o gráfica, el personaje modelado en 3D o el sprite 2D, entonces separás ambos mundos.
   

[/quote]
 
Esta parte no la entiendo.
 
¿ Quieres decir que podría crear un EmptyGameObject formado por dos GameObjects:
 

• 
     En uno irá el Collider con el RigidBody que sería el que tendría que mover haciendo uso de la física.
  


• 
     En el otro iría el Modelo con el Animator Controller asociado y las animaciones
  

?
 
 
 
Un saludo y gracias por la ayuda.
 
 

Buenas.
 
Llevo dándole vueltas a este tema y no lo tengo claro (o sí ) y por eso no me cuadra alguna cosa.
 
 
 

• 
     En teoría, cuando tenemos un objeto con un collider sin RigidBody es Static RigidBody y es necesario marcarlo como 'Is kinematic' cuando queremos aplicar una animación sobre él, ya que con esa opción marcada podemos hacer uso de su componente Transform para moverlo.
  


• 
     También está puesto que si un GameObject quiere ser manejado utilizando 'fuerzas' no podemos hacer uso de su componente Transform para moverlo.
  

Con esas dos condiciones, ¿ cómo se hace para tener un GameObject que  se mueva con el motor de físicas (por su RigidBody) pero que tenga una animación asociada cuando lo movemos ?
 
Acabo de mirar el juego que tiene Unity para formación (unity zombie toys) y en él sus protagonistas tienen animación pero no están marcados como 'Is Kinematic' y se mueven por su RigidBody. ¿ Esto no contradice la condición de que si se hace uso del Transform hay que marcar dicha opción ?
 
 
 
Gracias por la ayuda

Buenas.
 
Ya llevo un tiempo desarrollando juegos en Unity después de venir de LIBGDX.
 
 
 
Mucha documentación y muchos vídeos pero aún con dudas.