[library] bump.lua v3.1.4 - Collision Detection

[bobbyjones]

Box2d isn't as complex as people make it seem. The only thing is that you have a lot more variables to adjust to get a nice feel. But um isn't splash or something bump with more shapes added? I would assume it would work with slopes.

[kikito]

It would just be so much cooler if I had them now. Even if I have to implement a secondary collision system just for slopes

I know man. Sorry. Lately I have been busy and the little free time I had I allocated to things that I would enjoy more than the pure math problem that the slopes involve.

But um isn't splash or something bump with more shapes added? I would assume it would work with slopes.

I believe that's the intention, but not the current state. But I'm not the author of splash.

[alexzhengyi]

Would it be possible add a collision type that can move the other item along when collide?

[Sarcose]

So thanks again for your help, and that help has become a demo!

(I haven't implemented the layered worlds feature we discussed, yet)

[kikito]

Would it be possible add a collision type that can move the other item along when collide?

I would not recommend that. The returned values for world:move give information about the "object being moved", but there is no space there for other objects.

Instead, I recommend getting the collision information, and then moving the other objects outside of the bump code itself. You may find an example of this in the "platforms" branch of bump. In particular, the platforms invoke setGround on the player when it collides with them. setGround is a player method which resets the y-coordinate of the player so that it remains "on top" of the platform as it moves.

Finally, when the player is on top of a surface, its velocity is added to it.

You could apply this idea to other scenarios: blocks being pushed, etc.

So thanks again for your help, and that help has become a demo!

(I haven't implemented the layered worlds feature we discussed, yet)

Cool! I left a comment in your post, you likely made a uppercase/lowercase mistake when naming your files.

[Sarcose]

Thanks, kikito. I think I fixed it, and I believe it was exactly what you thought it was

[Tesselode]

Since it looks like the topic is heading in this direction, I'm going to go ahead and ask this. What would be the best way to implement a platformer that has moving platforms and pushable boxes using bump? I've gotten relatively close to having a solid engine, but I haven't quite made it yet (my current solution is to give up and use Box2D, which works surprisingly well).

My solution for moving platforms seems to work decently well, but it might not be the best. Right now the player (and any other object that can ride moving platforms) moves like normal, and if it hits certain objects with a normal.y < 0, then it'll set it's "standing" variable to be that object. As long as the player is still standing, gravity is turned off, and every frame the player does a world:check to see if it's still standing on that object.

Pushable boxes is the thing I'm stuck on right now. I'm pretty sure you have to resolve the collision differently depending on what the normal of the collision is, but the built-in filter system can't handle that. I made my own janky system where you can filter collisions using the collision info from running world:check, but I feel like that's getting overly convoluted.

Attached is my most recent attempt at using bump. It's been a while since I've looked at it, so I'm sure it's convoluted and horrible. If you jump into the pushable box from the left, everything bad happens.

So, Kikito, I need your advice! Off the top of your head, what would be the simplest way to implement a platformer with moving platforms and pushable objects? I'm not looking for any super detailed advice, just some general guidance, because if anyone knows the best way to work with bump, it would be you.

Thanks!

[alexzhengyi]

The idea of add a collision type such as 'push' is just from the platform demo.
It may make implements this kinds of collisions easier.This is the simple use case.But if there is wall just on top of the player, just simply update the player's y position may make the player cross the wall.
For another complicated use case,for example the play is pushing a solid box by 2 pixel , and the box is 1 pixel from a wall,then we can not just update this box like the platform demo.the play and the box both can just move 1 pixel.
For return values, is it possible to add a table otherNewRect in the col table if the other item is pushed?
It's may be not an easy feature to add,but maybe useful for many situations.
Thanks for this awesome bump lib.

[Sarcose]

I think pushable/pullable objects can be implemented using techniques we already see in other games -- most games have a player state that is specifically for pushing, either activated by walking toward the object for long enough (such as topdown zelda) or by pressing and holding a button (such as 3D Zelda, Tomb Raider, or topdown Zelda if you're pulling). In both cases, the player enters into a push/pull state where the actual engine interactions change - the player's input is transferred both to the block and the player entity.

I think trying to use bump directly to implement pushing and pulling is asking to make it into a physics engine. Use the filters feature to send messages between the player and block where you put the player into a push state and allow the block to listen to input values simultaneously -- control the block directly with controller input, instead of making the block respond to actions from the player entity.

In fact, the "push state" concept can be very obviously seen in older topdown Zeldas (NES, gameboy, SNES) where the push trigger (pressing against the pushable) actually puts Link into an immobile state and freezes the whole game, while the pushable object moves a prescripted distance in the direction pushed.

In all cases above, there is no actual "pushing". The concept of pushing would be a physics engine. It's just using triggers to activate movement or input states and events on objects, and give a good simulation of pushing. In most games, this is more than enough.

[Tesselode]

I think pushable/pullable objects can be implemented using techniques we already see in other games -- most games have a player state that is specifically for pushing, either activated by walking toward the object for long enough (such as topdown zelda) or by pressing and holding a button (such as 3D Zelda, Tomb Raider, or topdown Zelda if you're pulling). In both cases, the player enters into a push/pull state where the actual engine interactions change - the player's input is transferred both to the block and the player entity.

I think trying to use bump directly to implement pushing and pulling is asking to make it into a physics engine. Use the filters feature to send messages between the player and block where you put the player into a push state and allow the block to listen to input values simultaneously -- control the block directly with controller input, instead of making the block respond to actions from the player entity.

In fact, the "push state" concept can be very obviously seen in older topdown Zeldas (NES, gameboy, SNES) where the push trigger (pressing against the pushable) actually puts Link into an immobile state and freezes the whole game, while the pushable object moves a prescripted distance in the direction pushed.

In all cases above, there is no actual "pushing". The concept of pushing would be a physics engine. It's just using triggers to activate movement or input states and events on objects, and give a good simulation of pushing. In most games, this is more than enough.

Good idea, I'll give that a shot!