I finally implemented moving platforms, in my third NES game. They were kind of tricky to get working (without remaining bugs) because of their interaction with an already quite complex main character state machine. I had two options available to me for how to implement them (pseudo code);
The second option was:
I ended up going with the second option, as it ended up working just as well doing it this way and kept additional clutter out of the main character's state machine. *edit* It has occurred to me the second option should make horizontal platforms easier as they will have direct access to their horizontal velocity and can add it on to the player's position. The first option would have made the plumbing for this slightly more complex, potentially. At least with how I've architected things...
I left out a lot of details. But one interesting detail was that whenever the main character leaves a platform, at first it didn't look right because the platform was ascending and descending and when the main character falls, his y velocity was 0 so it looked unnatural. I eventually found a way to transfer the current velocity of the platform to the character right as he falls, so it looks like it should.
I also left out details about when the various flags are cleared or set, which allow platforms to be right next to each other moving at different offsets but still hold up the player as expected.
I'd be curious to hear at a high level how moving platforms work in your games. What's particularly interesting to me when designing various bits of a game engine is whether objects should perform an action ON another object, or whether the target object should perform the action ON ITSELF based on detecting some condition or other. I suppose depending on any given game engine there's going to be a heap of trade offs with all such decisions. A few years ago I had been under the illusion that there's one, crowningly perfect way to do everything; however I no longer believe this is the case.
Code:
-Have all entities which are platforms mark themselves as such, and keep track of all active platform entity indices in an array
-The main character checks all active platform entities prior to checking for map collisions.
-Collision is done with a thin rectangle on the top portion of the platform. If there's a hit the player is locked to the top of the platform, but only if he is currently descending.
-Platform entities lock the player vertically to stay on top of the platform. I have not yet implemented horizontally moving platforms, though.
-The main character checks all active platform entities prior to checking for map collisions.
-Collision is done with a thin rectangle on the top portion of the platform. If there's a hit the player is locked to the top of the platform, but only if he is currently descending.
-Platform entities lock the player vertically to stay on top of the platform. I have not yet implemented horizontally moving platforms, though.
The second option was:
Code:
-All platform entities have a collision routine which interact with the main character AFTER the main character's collision routine has already run, setting an "on platform" flag if a rectangle collision is detected, as well as a couple of other flags to trigger his "landing on something" state transition.
-Collision is done with a thin rectangle on the top portion of the platform. If there's a hit the player is locked to the top of the platform, but only if he is currently descending.
-Platform entities lock the player vertically to stay on top of the platform. I have not yet implemented horizontally moving platforms, though.
-Collision is done with a thin rectangle on the top portion of the platform. If there's a hit the player is locked to the top of the platform, but only if he is currently descending.
-Platform entities lock the player vertically to stay on top of the platform. I have not yet implemented horizontally moving platforms, though.
I ended up going with the second option, as it ended up working just as well doing it this way and kept additional clutter out of the main character's state machine. *edit* It has occurred to me the second option should make horizontal platforms easier as they will have direct access to their horizontal velocity and can add it on to the player's position. The first option would have made the plumbing for this slightly more complex, potentially. At least with how I've architected things...
I left out a lot of details. But one interesting detail was that whenever the main character leaves a platform, at first it didn't look right because the platform was ascending and descending and when the main character falls, his y velocity was 0 so it looked unnatural. I eventually found a way to transfer the current velocity of the platform to the character right as he falls, so it looks like it should.
I also left out details about when the various flags are cleared or set, which allow platforms to be right next to each other moving at different offsets but still hold up the player as expected.
I'd be curious to hear at a high level how moving platforms work in your games. What's particularly interesting to me when designing various bits of a game engine is whether objects should perform an action ON another object, or whether the target object should perform the action ON ITSELF based on detecting some condition or other. I suppose depending on any given game engine there's going to be a heap of trade offs with all such decisions. A few years ago I had been under the illusion that there's one, crowningly perfect way to do everything; however I no longer believe this is the case.