145

I slightly disagree with Philipp's answer; or at least with how he presented it. It gives the impression that moving the world around the player might be a better idea; when it's the exact opposite. So here is my own answer... Both options can work, but it's generally a bad idea to "invert the physics" by moving the world around the player rather than the ...


88

Both options work. But if you want the endless runner to be truly endless, you will have to keep the player stationary and move the world. Otherwise you will eventually hit the limits of the variables you use to store the X-position. An integer would eventually overflow and a floating point variable would become increasingly less accurate which would make ...


48

There are three common ways games sort this out: Minimum Separation Vector Upon a collision, compute the shortest movement that pushes the bodies apart into a non-intersecting position. If I've crept just 0.1 units into the platform's left side, but my feet are 0.2 units below its top surface, then the shortest movement to resolve the penetration is to ...


41

I think you need to consider this at a more fundamental level: what is the gameplay purpose of having a health system in your game? A conventional health system serves two purposes: (1) it gives a staged failure state to combat, and (2) it serves to create long term resource management with health between fights. You say you want your game to be ...


37

Building off of XenoRo's answer, instead of the re-rooting method they describe, one could do the following: Create a circular buffer of parts of your infinite map generated, which your character moves through with position updated with modulo arithmetic (so you just run around the circular buffer). Start replacing parts of your buffer as soon as your ...


34

I think you'll have to take the box's movement into consideration. That is, only crush if the box is moving towards the player. This is similar to other problems in platformers, where the movement is important. E.g. for platforms that you can jump through and onto from below, don't check collision if the player is moving upwards. So a block can crush the ...


21

In various Super Mario games, it's called a pit, abyss or bottomless pit. Bottomless Pit is also a TV trope.


19

You don't need to adapt A* at all. The only consideration is where you put your nodes and how you connect them. The linked article seems to convert from a platformer-friendly model to a grid based pathfinding model, which I don't think you want. A* itself is a tree search algorithm which finds the optimal path through your graph and requires some heuristic ...


15

Do it like Super Meat Boy. I assume your game has levels of some sort since its a puzzle plat-former, so as you mentioned Super Meat Boy I believed it's a great example for your question. In super meat boy, the way you control meat boy stays the same throughout the game, it's only the mechanics of the levels/environments that change. Therefore every ...


14

As already asked and accepted, it really depends on the scope and style of your game, but since it wasn't mentioned: FlappyBird moves the obstacle across the screen, rather than the player across the world. A spawner is instantiating objects off screen with a fixed speed in the Vector2.left direction.


12

I think I stumbled upon this link here on gamedev and I really found it enlighting. http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/ It explains some basic methods of implementing tile based levels, but there are also some important parts about how certain mechanics work in 2d platformers. I think you should look into ...


12

There are three general approaches to dealing with stairs in video games: The "Mario" approach is that you must jump to get up stairs. The "Castlevania" approach is that moving up/down stairs is a different sort of movement; you must press 'up' on the controller, and a special "stair-climbing" animation is played to traverse the stairs. A variant of this ...


12

You mentioned having thought about auto-regeneration and your issue with that was the possibility of a player, while in the middle of a fight, running around while they auto-regenerate health. Have you considered auto-regeneration only when not-in-combat (aka out-of-combat)? This is an approach taken in many games. You could combine this with one or more ...


11

In such cases, you may be better off letting the client be slightly authoritative. For such precise controls you're extremely unlikely to get good behavior even with really advanced correction and prediction. The client needs to extend from just sending "I jumped" messages to sending "I jumped from X,Y at time T" messages. The server then checks that the ...


11

If you're able to rotate the boundingboxes, I would've put a 45 degree rotated box at the player's feet and combine it with one non-rotated box to represent the rest of the body. That could make the player automatically slide over anything small enough. Though, that would probably cause some clipping with the player model and the stairs. Another idea is to ...


9

Here is my complete learning experience, resulting in a pretty much functional version of the movement I wanted, all using Nape's internal methods. All of this code is within my Spider class, pulling some properties from its parent, a Level class. Most of the other classes and methods are part of the Nape package. Here's the pertinent part of my import list:...


9

No, you don't have to use any specific toolset and you don't have to use any specific (physics) library either. It's just a question of convenience, since things like Box2D will provide you other benefits as well, e.g. being able to do collision, physics simulation etc. If you're not using tiles, you'll most likely want to write your own custom editor. As ...


9

Have the "crush test" points be inside the gray box shown in your image #1 - i.e. kill the player only if you detect a hit on one of the pixels there.


8

Although this is already answered, allow me to offer another equation: y = mx + b, where y is the coordinate calculated, m is the slope (-1 for down at 45 degrees, 1 for up at 45 degrees), and b is the y-intercept -- the y-coordinate where x=0. This allows you slightly more flexibility; you can change m to calculate a different slope other than 45-degrees. ...


8

The simplest, more fail-proof approach is to simply not check for collisions on hidden edges. If you have two wall tiles, one directly above the other, then the bottom edge of the upper tile and the top edge of the lower tile should not be checked for collision against the player. You can determine which edges are valid during a simple pass over the tile ...


8

I think your main problem lies here: While the jump button is pressed, gravity is turned off and the avatar's Y coordenate is decremented by the constant value of the gravity. For example, if things fall at Z units per tick, it will rise Z units per tick. Gravity doesn't work like that. Google "uniformly accelerated motion" for the details, but in ...


8

How about making any "stick" surface a character touches apply a force along the inverse normal of the surface? The force remains as long as they're in contact with the surface and overrides gravity as long as it's active. So jumping off the ceiling will have the expected effect of dropping down to the floor. You would probably want to implement some ...


7

I believe you're on the right track. Take a look at my amazing artistic skills here ;) Let's say that the player is the red block with the solid being their current position and the open square being their previous position. Now say that the blue tile is the platform you expect to land on and the green one is some other "impassable" tile beneath it. The ...


7

One possible solution is as follow: Fix the rotation angle for the box Box2D doesn't have angle joints, but setting the body definition with the property fixedRotation = true allows it to maintain a constant angle of rotation like the angle joint. High maximum torque for the motor's joint The maximum torque for the motor in the revolute joint needs to be ...


7

You don't say anything about what your game is, so it's hard to know whether you should or shouldn't have such collectibles. Some platformers do have additional tokens to collect, and some don't. There's no tradition that requires they be included in a game. What matters is if they fit in how your game should be played. I imagine you're more likely to be ...


7

You seem to have a handle on this already. My current 2D platformer has objects that implement different concerns, including the following: Notifiable - can be event-driven and scripted Collidable - can interact with solid tiles (eg NPCs) Intersectable - exists in 2D space and can intersect with the player (eg doors) Intersectable - exists ...


7

Most games don't have a separate class for each level. The usual way is to store the layout of each level in a file. These map files contain the environment and the positions and properties of all objects in it. When a level starts, the map file is loaded and a Level object is initialized with the data from that file. When the player finishes the level, ...


7

I'd recommend changing Input.GetKey("space") to Input.GetKeyDown("space"). This way the check is only performed on the initial key press, rather than every frame the spacebar is held. The other issue is at the bottom of your script: ableToJump = Physics2D.Linecast(... Since the physics step (aka fixed timestep) is only updating every 2 milliseconds (by ...


7

Perhaps you can add some non-conventional healing system. Like for example : Health steal -> percentage of health gained = percentage of enemy health lost, and varies with enemy level. Every nth hit -> every nth hit gains certain health with certain weapon/class/etc. Implement the common methods -> but minimal like 1-5% Think something like these, maybe ?


Only top voted, non community-wiki answers of a minimum length are eligible