[2D Platformer] Horizontal Loop

Started by
4 comments, last by kburkhart84 8 years ago

Hi everyone !

I'm new to this forum ;)

If i'm here today, it's to ask you a question about the simple way (or the most effective way), to make an horizontal loop in 2D platformer games.

But what do i mean by : horizontal loop ? :P

Two examples could be : super mario 3 battle mode, or Towerfall Ascension.

To explain it with words : in a 2D game with fixed view, when an object reach the end of the room (max right, min left, top, bottom), it might "loop" to the opposite place.

Screenshot (always easier to understand) :

430883Sanstitre.png

So this is a towerfall ascension screenshot. You see the arrow is passing through the left to the opposite (right).

The difficulty is : how can a object can be at two positions at once ?

I tried two methods :

- Duplicate sprite and body collision (not the effective way i think).

- Use multiple views (i didn't manage to make it properly).

So, do you guys (or girls), know the best way to do that ?

For informations, i'm programming in c++ with SFML libraries.

But, what i'm searching is not a code, but an algorithm :rolleyes:

Hope, you could help me.

PS : I'm not speaking english fluently, so sorry if there are mistakes.

Advertisement

You could either:

  • render the player in two positions (in the player's draw() function, if you have one) when they are touching the boundaries of the window
  • eschew the fancy visuals and simply have the player teleport to the other side when they go off-screen

Similar to the poster's second bullet point above, you can have an offscreen/covered portion, so that you won't have the player in two spots at once. For example if your character is 10 pixels wide, you could not have the character teleport until they are completely offscreen and are 11 pixels offscreen.

Yeah, pretty much what they said, either cover up a portion and teleport, or just render two for a short time, if you wanted to be completely efficient, calculate the cut off point and set the offsets into your sprite sheet, and size of your sprite accordingly so that the portion that would be hidden by the black part doesn't get drawn at all.

Portal-based motion (which have been called that long before the game named Portal) frequently operate as individual triggers with a response. For your example, one trigger is on the left side of the board, and the trigger's response is to place the character on the right side. The other trigger is on the right side and the trigger's response is to place the character on the left side.

One could just as easily have the triggers place the character in a different location. Maybe three triggers that all put the character in a central location, or maybe several triggers where each is pointing to the next, so a player could enter them each sequentially to jump around the board from place to place.

The triggers could also be leveraged for something else, tied to an event like starting a scene, moving to a new level, entering a store, spawning a monster, triggering a trap, or both locking the door and spawning a boss, to name a few.

In my opinion, the general easiest way is what has been said above. Figure out a good distance(dependent on the move speed) and as soon as you would be about out, simply do an instant movement of your character from one place to another, and keep the other stats, like inputs, movement speed, etc... You don't have to do it when completely out, rather for example, if your character moves at 2 pixels a frame, then when your character only has 2-4 pixels left inside, that's the point where you switch to the other side, and the position on the other side could have 2-4 pixels of the character on the inside.

One other idea, if you are using any programming language that lets you create classes/objects, is to create a special object. You would make this object only do a couple things, move a few pixels in a certain direction, draw a certain sprite/animation, and then delete itself after a few frames. Now, the catch to this method is that you probably would need to have a certain commitment at a certain point. Maybe once the character is halfway out, you then commit it to follow through with the motion. At this point, you create your "dummy" and give it the sprite/frames of the character, along with the speed, etc... and at that point, you can move your real character to the other side. The point of having the dummy object is so that you don't have more than one instance of your actual character, so for example if your AI depends on that, you don't have to worry about accounting for that as you never duplicate the character. And the fake object would delete itself after however many frames you set it to, so you don't have to worry about managing it later either. The bad part about this method isn't so much the coding(as long as you understand OOP, or are using a framework that makes this easy, like GMStudio or Unity), but rather in the whole part about the commitment. If your players are used to being able to turn on a dime, then you may have to forgo the whole visual, but if movement is grid-based, or simply can work without instant friction, etc... than this version could work. And the techniques can work for other things, making you learn how to create and use different types of objects for things like this.



This topic is closed to new replies.

Advertisement