Static character and camera.
Semi-Randomly generate the level from a selection of prefab tiles. Move the tiles under the player. Player animates to appear to be running.
Destroy tiles at they get some distance behind the player, create new ones outside the fog distance.
HammerFist: Not sure exactly what you mean. If you mean can the player move relative to the camera around obstacles? of course.
The only thing that wouldn't work is going backward through the level unless you somehow kept a running track of what bits came when.
you can go up or down or whatever just plan for it and move the level pieces relative to the camera so you don't wind up off in some strange place in game space.
@Vailias Surely it would be more efficient to just move the player and the camera?
When I did an endless runner for a games jam we created a load of modular set blocks and then randomly placed them in front of the path the player was running along. Once they are out of the camera view range they get moved to another point It worked quite well
AzzaMat: If you allow the player to move in the world then in a long enough run you'll start running out of mathematical precision. Actual limit distance depends on how your base unit is stored and how big that is. Its an edge case scenario, but it makes your endless runner not actually endless. Especially if you get way way out, then add a small bit forward (like adding say the distance traveled in a frame to several hundred kilometers) can result in a loss of data precision. When that happens to something like player position, the results could be somewhat unpredictable. This also affects other things like collision detection accuracy etc.
Now your average player will fail and die before they get that far, however if you can avoid that concern all together, why not do so?
Also as far as efficiency goes, the transformations are equivalent. A player moving through a world, or a world moving around a player are mathematically symmetrical. Its just a matter of what your base coordinate system is.
Another upshot of a moving world is you could manage your block destruction with a simple collision detection routine rather than figuring out if the camera can see it or not depending on location.
In unity you could just set up a large box collider outside of the camera view. Attach this script to it:
Replies
Semi-Randomly generate the level from a selection of prefab tiles. Move the tiles under the player. Player animates to appear to be running.
Destroy tiles at they get some distance behind the player, create new ones outside the fog distance.
http://www.polycount.com/forum/showthread.php?t=117953
HammerFist: Not sure exactly what you mean. If you mean can the player move relative to the camera around obstacles? of course.
The only thing that wouldn't work is going backward through the level unless you somehow kept a running track of what bits came when.
you can go up or down or whatever just plan for it and move the level pieces relative to the camera so you don't wind up off in some strange place in game space.
When I did an endless runner for a games jam we created a load of modular set blocks and then randomly placed them in front of the path the player was running along. Once they are out of the camera view range they get moved to another point It worked quite well
Now your average player will fail and die before they get that far, however if you can avoid that concern all together, why not do so?
Also as far as efficiency goes, the transformations are equivalent. A player moving through a world, or a world moving around a player are mathematically symmetrical. Its just a matter of what your base coordinate system is.
Another upshot of a moving world is you could manage your block destruction with a simple collision detection routine rather than figuring out if the camera can see it or not depending on location.
In unity you could just set up a large box collider outside of the camera view. Attach this script to it:
And so long as your collider is big enough your level cleanup is done for you.
Put a game object forward out of camera view to spawn new sections based on current movement speed and you're all set.