Page 1 of 1

### How did games usually do moving platforms?

Posted: Sat Mar 16, 2019 10:31 am
My game uses a combination of letting having the player routine look at the platform's velocity, and having the platform's routine check collision and adjust objects so they are directly on top. It works good if the velocity is constant, but I realized that if it's not constant than my character would "fall" for a couple frames if the platform changed directions, so instead of using normal bounding box collision, I did collision with a platform 2 pixels higher than it actually is to avoid "falling".

Does this sound like a way other programmers would do it? Another method I thought of is for the platform's routine to do collision with the player before moving the platform, and then move the player's coordinates with the platform. However that might need to run through the tile-map collision routine a second time. Now it's possible to make a tile-map collision routine that doesn't rely on the previous frames coordinates, but you still need some way of detecting if the sprite is moving down so it can detect pass-through-bottom tiles.

### Re: How did games usually do moving platforms?

Posted: Sat Mar 16, 2019 11:21 am
My solution is this:

- objects that can carry others are processed first, and their latest displacement is cached;
- when an object that can be carried lands on an object that carries objects, it snaps to the top of this object and a reference to it is saved in the falling object's "standing on" field;
- when processing objects, in addition to their normal displacement, also move them by the displacement of the object indicated in their "standing on" field;

### Re: How did games usually do moving platforms?

Posted: Sat Mar 16, 2019 12:59 pm
Terrain collision in two released NES games that I programmed has a step where it finds the highest floor that is at or below 8 vertical pixels above the actor's bottom center. If the actor is the player, it includes all lifts in the search. If the player's velocity is not upward, and a lift is close enough to the player's feet, it marks the player as being on the lift, and the rest of the terrain treats that lift as floor. Whenever a lift moves, if the player is on that lift, it also moves the player by the same number of pixels.

I'd point you to the source code but it's private, as I was not the producer.

### Re: How did games usually do moving platforms?

Posted: Sat Mar 16, 2019 8:28 pm
tokumaru wrote:My solution is this:

- objects that can carry others are processed first, and their latest displacement is cached;
- when an object that can be carried lands on an object that carries objects, it snaps to the top of this object and a reference to it is saved in the falling object's "standing on" field;
- when processing objects, in addition to their normal displacement, also move them by the displacement of the object indicated in their "standing on" field;
Okay that sounds like what I'm doing except for part about the platforms being processed first.

### Re: How did games usually do moving platforms?

Posted: Sun Mar 17, 2019 3:12 pm
My sollution is simple as moving platforms in my games just displace the main character. I do box collision with a rectangle going up a couple of pixels above the platform. If collision is registered I move the player alongside the plaform. I have a couple of variables (one per axis) to express displacement velocity. When I run the player moving code afterwards, those are taken in account in the collision checks. For example, you normally check the rightmost collision points of your character if player's horizontal velocity is positive; if I'm using moving platforms I do such checks if the result of adding the player's horizontal velocity plus the horizontal displacement velocity is positive.

### Re: How did games usually do moving platforms?

Posted: Sun Mar 17, 2019 5:23 pm
psycopathicteen wrote:Okay that sounds like what I'm doing except for part about the platforms being processed first.
The reason I introduced ordered object processing in my engine was precisely to avoid jitter and re-processing when objects have their positions affected by other objects.