- Home /
Move an enemy on top of a moving platform
I have a setup which involves a moving platform(in green) and a patrolling enemy on top of it, shown below:
The platform is moving left and right, periodically and so is the patrolling enemy both using rigidbody.velocity. Both when in motion separately are appearing fine. But when enemy is on the top of the platform, with enemy being the childobject of platform, the enemy is appearing static (just playing moving animation in it's place) even though I have corrected for the velocity of the platform. Below is the snippet of my Update() method:
void Update()
{
if (parent)
parentVelocity = parent.GetComponent<Rigidbody2D>().velocity;
Debug.Log("parentVelocity=== " + parentVelocity);
if (IsFacingRightOrUp())
{
if (moveVertical)
myRigidBody.velocity = new Vector2(0f, moveSpeed);
else
myRigidBody.velocity = new Vector2(moveSpeed, 0f);
}
else
{
if (moveVertical)
myRigidBody.velocity = new Vector2(0f, -moveSpeed);
else
myRigidBody.velocity = new Vector2(-moveSpeed, 0f);
}
Debug.Log("myRigidBody.velocity === " + myRigidBody.velocity);
myRigidBody.velocity += parentVelocity;
Debug.Log("myRigidBody.velocity === " + myRigidBody.velocity);
}
It is producing the Debug logs as follows, parentVelocity being defaulted to (0,0):
What should I do to make the motion of enemy same to an observer on the platform as the motion ob enemy would appear when both are standing on the static ground?
The only way a Rigidbody can work well as a "child" of another object is by using joints. I've often thought the editor should warn users when the situation arises where an object with its own Rigidbody becomes the child of another object that also has its own Rigidbody without a joint between them.
So, one must ask why is the character a child of the platform? Is there a logical relationship which implies a child/parent relationship? It doesn't seem so to me. If the primary purpose you had in $$anonymous$$d was to couple the motion of the character to that of the platform, that only makes sense if the child object is part of the platform, and is either just some related artwork (without its own Rigidbody), or is joined through a joint.
For objects on a table, for example, it may seem appropriate in pure artwork (say within a 3D editor like Blender or $$anonymous$$aya), to place the objects on the table as children, or as a group. Yet, in such editors physics is usually not a major consideration, nor is real time motion.
I don't work in 2D that much, so I have a 3D perspective on these points, but it make more sense to rely on physics between two objects such as these. The character would experience friction against the surface of the platform such that moving the platform moves the character. The first "benefit", or characteristic, of this arrangement is that if the platform moved "too fast", the character wouldn't have enough friction to remain on the platform (as would be the case in the real world).
Another approach is to avoid the Rigidbody on one or other object, whichever seems most appropriate, and control that object through script ins$$anonymous$$d of physics. The platform may be the best choice for that approach.
i have never used joints before :/
which joint should i use?
Well, I don't believe a joint is the best solution to this particular problem. I was referring to the more general notion of a Rigidbody on a child to a parent with a Rigidbody (or any complex relationship that resolves to the same). The only way that works is with joints, but the context of the two objects must be related by the joints behavior in some meaningful way.
Joints are chosen for the behavior desired. The fixed joint, for example, is like a firm, non-moving attachment (like bolting something on). It is used in particular for the feature that it can break under force, giving a means of destruction to an complex object.
HingeJoints work for doors, swinging signs, some have made ropes from them, and I've been able to use one as a set of wheels, though it can be a bit jittery.
Springs, however, are quite curious creatures, and may have SO$$anonymous$$E limited purpose for you. Adjusting parameters can make them behave in interesting ways, and some use them with high damping to cause a camera to follow an object. It might have interesting effects on keeping a character on a platform, but you'd have to judge if the effect was desirable. It may well not be.
However, I assume the character eventually jumps to other platforms, and the relationship therefore becomes dynamic (in the sense that it trades from platform to platform, any relationship is under change). I still think friction is best, and perhaps you could consider invisible colliders on the edge of the platform as a guard rail for the character, which would the require an action to "jump over" the rail to get off the platform. That would otherwise keep the character within the platform.
Answer by Epic_PotatoGuy · Jul 09, 2018 at 06:00 PM
I might be interperting this wrong, but why are you correcting for the velocity of the platform if it's a child of it? it should be able to be connected as a child to the platform and move with it, and move only in relation to it using the script, 0,0,0 will always be the center of the platform if the enemy is a child.
That's what I thought earlier, but it didn't work. I have solved it some other way though - https://stackoverflow.com/questions/51241868/move-an-enemy-on-top-of-a-moving-platform