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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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.
I think I stumbled upon this link here on gamedev and I really found it enlighting.
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 ...
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 ...
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 ...
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 ...
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 ...
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:...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
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, ...
Make sure that there is a visual cue that the player is currently not in control.
When it is a non-interactive cutscene, you could remove the GUI during the cutscene and bring it back as soon as the player is in control again.
When the users control is impaired (but not completely disabled) during normal gameplay, for example because their character is ...
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 ...
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 ?
As far as 1) you'll need to use a toggle state.
Fire ONLY if the user did not click the previous tick, and is registered as clicking this tick.
This can be thought of as the rising edge of the click state.
here should the fire logic be called
not clicked ___|
For 2) it seems that your update() ...
You're likely simulating some kind of upward force greater than gravity to make the physics object "jump". Increasing the amount of force will allow the character to reach a higher velocity quickly. Likewise, increasing the force of gravity on the player will make them fall faster.
You can either increase gravity for the entire world, or apply an additional ...