3 ms·

I think there is a simpler way to represent this. Represent each wall as a pair of tiles. Whenever a ball would move from tile A to tile B in a single time step

by lacker 12y ago

I think there is a simpler way to represent this. Represent each wall as a pair of tiles. Whenever a ball would move from tile A to tile B in a single time step, check if there is a wall whose pair of tiles is A and B. If there is such a wall, the ball bounces. If not, the ball doesn't bounce. I don't think you should need to write any code that handles north/south/east/west with a switch statement, it should all be vector math. I think the only edge case here would be a ball that hits a corner dead on. You would need code that says "if a ball goes from A to B in a time step, and those are diagonal, treat it as A -> C -> B where C is one of the tiles adjacent to both A and B, for bounce checking."

w0utert 12y ago
This is exactly how I implemented almost the exact same thing in the iOS clone of a classic DOS game (Snipes!) I made (shameless plug: https://itunes.apple.com/nl/app/snipes!/id428845764?mt=8 https://itunes.apple.com/nl/app/snipes!/id428845764?mt=8) The linked article is pretty thorough, but a little complex for the nature of the problem I think. What I did was just calculate all tiles (I call them 'cells') intersected by the displacement vector of the projectiles (balls) moving around the maze, which can be done in constant time if your maze dimensions are fixed. Then I look up the walls of intersected cells, and calculate the closest intersection of the displacement vector with any of these walls. This intersection happens somewhere along the vector between t=0 and t=1, so I translate the projectile position back in time using this value, change its direction (invert either x or y based on the orientation of the wall), then move it along (1 - t) * v_inverted to solve the 'fast projectiles skipping walls' problem (this is basically a very simple case of continuous collision detection). If you allow a tiny bit of non-determinism in very rare cases, the edge case where a ball exactly hits an corner doesn't need a lot of additional work, you just repeat the intersection test iteratively until there are no more intersecting edges (99 out of 100 cases there will be only 1, and in the remaining case there will be 2, provided that your balls don't move faster than 1 unit cell distance per frame).

by lacker 12y ago

w0utert 12y ago

This is exactly how I implemented almost the exact same thing in the iOS clone of a classic DOS game (Snipes!) I made (shameless plug: https://itunes.apple.com/nl/app/snipes!/id428845764?mt=8 https://itunes.apple.com/nl/app/snipes!/id428845764?mt=8) The linked article is pretty thorough, but a little complex for the nature of the problem I think. What I did was just calculate all tiles (I call them 'cells') intersected by the displacement vector of the projectiles (balls) moving around the maze, which can be done in constant time if your maze dimensions are fixed. Then I look up the walls of intersected cells, and calculate the closest intersection of the displacement vector with any of these walls. This intersection happens somewhere along the vector between t=0 and t=1, so I translate the projectile position back in time using this value, change its direction (invert either x or y based on the orientation of the wall), then move it along (1 - t) * v_inverted to solve the 'fast projectiles skipping walls' problem (this is basically a very simple case of continuous collision detection). If you allow a tiny bit of non-determinism in very rare cases, the edge case where a ball exactly hits an corner doesn't need a lot of additional work, you just repeat the intersection test iteratively until there are no more intersecting edges (99 out of 100 cases there will be only 1, and in the remaining case there will be 2, provided that your balls don't move faster than 1 unit cell distance per frame).