Box physics problems

Box physics problems

Postby Wuzzy » 20 Jun 2019, 09:19

The box physics are still pretty weird in 0.5.1 Alpha:

1) If a box is on a moving block and is pushed right into another block, the box will either just move through these solid blocks like a ghost or it will fall down, through solid blocks. You can force boxes to go through walls this way.
2) If you build boxes like Stonehenge and push first the left box a bit, then the right box, the upper box behaves differently. One time, it stands still, the other time, it moves with the box.
Like so:
{l Code}: {l Select All Code}
AAAAAAA
 B   C
 B   C
 B   C

(3 boxes total, each letter is a box)

3) If you build two conveyor belts horizontally next to each other, the left one with speed -5, the right one with speed 5, and put a 2×1 box right on the middle, the box will move right. Set the speed of the left conveyor belt to -20, the box will still move to the right. The “force” of the left conveyor belt is completely ignored


Suggestions for fixes (Note none of this has been tested):
1) Crush and destroy boxes when they end up in anything solid, like players
2) The upper box should not move in both cases since it still has the other box to rest on
3) Basically, take the average speed of all conveyor belts on which the box is on. Set X=0 and N=0. For each pixel of the bottom of a box, check if it's directly on a conveyor belt. If yes, add the speed of that pixel to X and add 1 to N. The final speed of the box is X divided by N. To prevent the speed becoming 0 due to rounding errors, force the minimum speed to be 1 (or -1, depending on direction) if X does not equal 0.

Example: For the box in the example above in 3) (speed -5 left, speed +5 right), this would be a box speed of exactly 0 because (50 pixels*-5 + 50 pixels *5) / 100 pixels = 0
Example 2: With the conveyor belt speeds -20 left and +5 right, the calculation will be (50 pixels * -20 + 50 pixels * 5) / 100 = -7.5


Please post other problems with box physics here. :)
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 776
Joined: 28 May 2012, 23:13

Re: Box physics problems

Postby acme_pjz » 04 Jul 2019, 06:14

The box physics is indeed a nasty part in game.

Suggestions for fixes (Note none of this has been tested):
1) Crush and destroy boxes when they end up in anything solid, like players


I don't think it is a good idea, since you can make use of it to bypass box obstacles.

2) The upper box should not move in both cases since it still has the other box to rest on


But what if the two lower boxes are pushed by player and shadow simultaneously? In same direction or in opposite directions?

3) Basically, take the average speed of all conveyor belts on which the box is on. Set X=0 and N=0. For each pixel of the bottom of a box, check if it's directly on a conveyor belt. If yes, add the speed of that pixel to X and add 1 to N. The final speed of the box is X divided by N. To prevent the speed becoming 0 due to rounding errors, force the minimum speed to be 1 (or -1, depending on direction) if X does not equal 0.


I think this is doable.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 639
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby Wuzzy » 04 Jul 2019, 10:39

For 1)
I think this is up to the level designer to consider this. We only have 2 levels with moving blocks and boxes so far, and neither would break. In fact, they would get fixed. Level designers needs to make sure that box crushing is simply not possible when it's not desired, or make it so that it cannot be used to proceed, or make it part of the puzzle when it's actually desired.

The only levels with boxes and moving blocks atm are Prison Break and Bridge Over Troubled Waters from Cooperation and in these levels you can stack boxes in such a way they get pushed into other blocks. But in neither level you could use box crushing to bypass anything, actually. Actually, the player wants to prevent boxes from getting crushed here. Therefore, I think this is totally sensible behaviour. And in fact, in Prison Break, you can currently glitch through some boxes through moving blocks by clever stacking, which allows some kind of cheat.

The other logical solution would be to block movement of moving blocks when they try to push boxes into invalid positions. But that would be insonsistent behaviour when compared with what happens to players and also sounds kind of tricky. :(

For 2)
Revised box speed rules:
2a) When box rests on any solid surface: Ignore all box surfaces, only take the solid surfaces into account. On normal blocks, this means no movement. For conveyor belts, we have rule 3)
2b) When box rests on 1 box: Move box simultanously with lower box
2c) When box rests on 2 or more boxes: Take average movement speed of all lower boxes, in a similar fashion to conveyor belts, but including boxes with 0 speed as well
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 776
Joined: 28 May 2012, 23:13

Re: Box physics problems

Postby acme_pjz » 19 Jul 2019, 09:04

I think now we need the box crushing sound and animation. I plan to find the sound on OpenGameArt. As for the animation, currently I use fragile block breaking animation as a placeholder. :|

[EDIT] The box crushing experiment is on git master branch. It's extremely buggy due to the limitation of current box physics logic, for example, the stacked boxes on a moving-up moving block will crush automatically. :(
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 639
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Who is online

Users browsing this forum: No registered users and 1 guest