34

The solution is actually simpler than expected. The trick is to use Minkowski subtraction before your hexagon technique. Here are your rectangles A and B, with their velocities vA and vB. Note that vA and vB aren't actually velocities, they are the distance traveled during one frame. Now replace rectangle B with a point P, and rectangle A with rectangle C =...


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 ...


17

First of all, in the case of axis-aligned rectangles, Kevin Reid's answer is the best and the algorithm is the fastest. Second, for simple shapes, use relative velocities (as seen below) and the separating axis theorem for collision detection. It will tell you whether a collision happens in the case of linear motion (no rotation). And if there's rotation, ...


16

Solving this problem requires adjusting position and possibly velocity. Rigid body physics engines have a solver that march objects forward in time using Newton's laws of motion while also solving non-penetration constraints and friction. These engines can compute the right combination of linear and angular motion to create plausible trajectories. If you ...


15

Independent of feasibility (yes, depending on scale) there are often better or easier ways. For instance, in your typical MMO, the server really only needs to know about the coarse navigation map used by AI and player pathfinding. Instead of storing the location of a tree, you can instead just cut a hole into the navmap at the location of the tree. Likewise ...


14

First, I recommend using a free, open-source physics library like Box2D and just focusing on the aspects of your game that make it unique! If you insist on re-inventing the wheel, read on... note all physics engines are approximations, and while the method I outline below will be more accurate than your current model, Box2D's results will be far more ...


14

Scenario It seems your pathfinding and collision detection have different ideas of what's OK, when it comes to walking around corners. Say your pathfinding plans out this path (brown squares are walls, yellows are empty space, green is an enemy character, arrows are the planned path): The enemy character then moves directly toward each point from the ...


12

A* is the logical choice. Your main concern is going to be with generating good navigation nodes. The nodes will tell you everything you need to know about how traversable each node is with respect to each unit. Having size information associated with your nodes will be very helpful to you. In the above, we see a size 1 unit can use any of the nodes. Where ...


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 ...


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

Depends a bit how in depth you want to go. For simplicity I would suggest either a Observer Pattern for a CollisionDetector class or a simple Aggregation (the CollisionDetector has a reference to the world which contains everything) Basically you would have to check everything against everything. In an optimization you could use a Sweep and Prune approach ...


9

Generally the way most physics engines handle this problem is by separating the intersecting objects. So if your objects are represented by rectangles (also known as "Axis Aligned Bounding Boxes"), and they collide on a given frame like so: You would then measure the amount of interpenetration on each axis. Then select the axis with the smallest amount of ...


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

The resolution for this could be the same you'd use for processing held keys on the keyboard. colliding = checkCollision(this, otherObject); if(colliding && !previousFrameColliding) { //trigger hit with otherObject } else if(colliding && previousFrameColliding) { //still in contact, do what you will here, or nothing } else if(!...


7

What you're looking to do is have the solid object (wall, obstacle, etc.) push back with a force equal to that which the player is exerting on it. In a simulated physical world, applying forces will not result in the behavior you want, so the velocity of the player has to be changed directly. This is what's known as an impulse. The impulse you want to ...


7

Like Byte56 suggested, rather than fix the collision, you simply doesn't allow the collision to happen in the first place. Here's a snippet of how my engine handles it // Reset flags just like you do. this.IsPushingLeft = false; this.IsPushingRight = false; // verticalWall is just a struct containing all the common data for whatever wall of tiles the ...


7

What you have here are two constraints that need to be resolved. On one hand, you need the sphere to stay outside the wall, by pushing it along the normal. On the other hand, you have the constraint that the sphere needs to stay attached to the ground. If you don't want to try writing fancy solvers, the easiest way to do this is to use an iterative solver. ...


7

( Edit : the method above works only for square AABB, i'll have to think on how to improve it, sorry ) Fastest way is to : - A) test circle against rect's outer bounding circle -> reject if too far. - B) test circle against rect's inner bounding circle -> accept if near enough. - C) test that the outer point of the circle (on the line joining both centers) ...


7

Yes - it is feasible. MMOs often split the game world into multiple areas, as this makes the job easier, but you can still do it with 1 massive area - you just need to use a good spatial partitioning scheme. Because most objects in MMOs don't move, you can also perform a preprocessing pass where objects are used to create collision checking trees. Memory ...


6

First of your problem is that you're not looking in a further perspective. The ball blocks itself on a wall - just move it 0.5 pixels away. Why not try to unblock it instead? Later you treat a corner like a circle (do you mean a point? If not, I don't understand the idea and it makes me dizzy when I try). It's OK to do quick, dirty fixes and try if they ...


6

The problem The problem lies in your method of collision resolution. Your method goes as follows: Move the player. Check for collision. Determine the shortest collision depth. Resolve collision. The problem with this, is that it can easily move the player in the wrong direction. You can see how this might happen in the image below: Because the player is ...


6

Your solver needs multiple iterations (aka sequential impulse) over its contacts. Treat each contact point independently and calculate the impulse to resolve its contact constraint for that iteration. This may cause previously resolved contact points to be pushed back into the colliding object, but not by as much as the initial penetration. Perform ...


6

As someone who grew up with 80s platformers, my first comment is that the contact points must be exactly on the sprite, not anywhere outside it. There were few experiences more frustrating than dying when a weapon/crusher/enemy was clearly several pixels away from your character - and that kind of experience is what stops people playing. With that in mind, ...


5

Diagrammatically When I have collision problems, I draw. This is your problem, as I understand it: Tiles A and B, considered separately, have their own ideas of where you should go to get out of each of their collisions. In this case, the displacement out of A is superfluous: The displacement out of B is already the minimum exit distance. However, in a ...


5

What you probably want At the moment, your code only removes any Blocks (they may be one or more) that the Ball collides with. You want the Ball to bounce off of the Blocks in addition to removing them. What you have is called collision detection (reporting when a collision has happened). What you'd like to have is called collision response (doing sensible ...


5

This is a really common problem, and I'd be very surprised if it hasn't been answered several times already. Short version of several potential fixes: 1) Ignore internal edges between tiles using flags. For each tile, set a flag for each of its four sides indicating whether that side is external (adjacent to an empty cell) or not. Then only do collision ...


5

Instead of an AABB of size (w,h), position (x,y) and velocity v, and an AABB of size (w2,h2), position (x2,y2) and velocity v2, you could consider a fixed-position AABB of size (w+w2,h+h2), position (x,y) and a point of position (x2,y2) moving at velocity v2-v. Then use AABB/ray collision resolution. You can restrict yourself to the 2D case by removing the ...


5

I think the problem is that in one frame the objects move fast enough to pass through each other. Behold my ascii art: Frame 1: a is heading towards b +-------+ +-------+ | A | | B | +-------+ +-------+ Frame 2: +----+--+----+ | B| |A | +----+--+----+ At this point the collision response moves them away from each other but the ...


5

The basic concept, used for many years now, is to just send out ray (really, line segment) queries from your character. If the character has gravity applies or is moving donwards, shoot two rays from the bottom two corners of the character's collision box and see if anything is close. You can react differently depending on which of the two registers a hit. ...


5

The minimum y offset can be calculated with the minimum overlap: The blue line is the MTV from the SAT algorithm, the red line is the minimum Y offset. phy::vect2D c = phy::_poly_collision(p1,p2); if(c.y != 0 && c.x != 0) { p1.y_pos += ((c.x*c.x) / c.y) + c.y; } else { p1.x_pos += c.x; p1.y_pos += c.y; }


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