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) The Stonehenge Bug: 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. :)
Last edited by Wuzzy on 16 Nov 2019, 23:40, edited 1 time in total.
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 831
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: 654
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: 831
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: 654
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby acme_pjz » 29 Sep 2019, 16:05

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


Please check the latest version in git master branch. I think all other bugs regarding box crushing were fixed, except for this one:

2019-09-29 225820.jpg


The left one will erroneously crush due to wrong processing order (currently the boxes are sorted by their y-coordinates, then x).
Currently I can't find a way to fix it. :(

Please test if there are other types of bugs.

Wuzzy {l Wrote}: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.


Not implemented yet. :(
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 654
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby Wuzzy » 02 Oct 2019, 12:22

I found a new bug:

Image

The moving block will move left and right, pushing the bottom box away. As soon the stack of boxes falls, the top box will be destroyed.

20cc163f6e0084b6409876cb406e8fb469c86e30
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 831
Joined: 28 May 2012, 23:13

Re: Box physics problems

Postby acme_pjz » 03 Oct 2019, 08:31

Wuzzy {l Wrote}:I found a new bug:

The moving block will move left and right, pushing the bottom box away. As soon the stack of boxes falls, the top box will be destroyed.

20cc163f6e0084b6409876cb406e8fb469c86e30


I think it's fixed in 97f5782. However I prefer rewrite the collision resolving code for pushable blocks completely :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 654
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby acme_pjz » 16 Nov 2019, 18:44

Finally I think I fixed all of the bugs regarding box squashing, by implementing topological sort. Please test that if there still are any bugs or regressions about it.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 654
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby Wuzzy » 16 Nov 2019, 23:54

I am unable to find any other crushing-related bugs. But TBH, the box crushing effect looks odd. Does MnMS still use the same GFX as for fragile blocks?

The other problems remain (Stonehenge, conveyor belt; see 1st post).
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 831
Joined: 28 May 2012, 23:13

Re: Box physics problems

Postby acme_pjz » Yesterday, 07:10

Wuzzy {l Wrote}:But TBH, the box crushing effect looks odd. Does MnMS still use the same GFX as for fragile blocks?


Yes. I remembered that you had provided an alternative crushing animation here. However IMO it doesn't look good either.

Can you compare these two animations and give a feedback? BTW here I provide a modified version:

{l Code}: {l Select All Code}
diff --git a/data/themes/Cloudscape/theme.mnmstheme b/data/themes/Cloudscape/theme.mnmstheme
index 3d2dcc6..51bda9f 100644
--- a/data/themes/Cloudscape/theme.mnmstheme
+++ b/data/themes/Cloudscape/theme.mnmstheme
@@ -768,22 +768,12 @@ block(Pushable){
    }
    transitionState(default,broken){
       oneTimeAnimation=6,broken
-      # FIXME: use fragile block broken animation for placeholder
       object{
          positioning(repeat,repeat)
          animation=6,0
-         pictureAnimation(tiles/tiles.png){
-            point(150,50,50,50,1,2)
-            point(250,50,50,50,2,2)
-         }
-      }
-      object{
-         offset(0,50,0,-50)
-         positioning(repeat,repeat)
-         animation=6,0
-         pictureAnimation(tiles/tiles.png){
-            point(150,100,50,50,1,2)
-            point(250,100,50,50,2,2)
+         pictureAnimation(tiles/boxcrush.png){
+            point(0,0,50,50,1,2)
+            point(100,0,50,50,2,2)
          }
       }
    }
@@ -856,22 +846,12 @@ block(ShadowPushable){
    }
    transitionState(default,broken){
       oneTimeAnimation=6,broken
-      # FIXME: use fragile block broken animation for placeholder
       object{
          positioning(repeat,repeat)
          animation=6,0
-         pictureAnimation(tiles/tiles.png){
-            point(150,50,50,50,1,2)
-            point(250,50,50,50,2,2)
-         }
-      }
-      object{
-         offset(0,50,0,-50)
-         positioning(repeat,repeat)
-         animation=6,0
-         pictureAnimation(tiles/tiles.png){
-            point(150,100,50,50,1,2)
-            point(250,100,50,50,2,2)
+         pictureAnimation(tiles/boxcrush.png){
+            point(0,50,50,50,1,2)
+            point(100,50,50,50,2,2)
          }
       }
    }


Wuzzy {l Wrote}:The other problems remain (Stonehenge, conveyor belt; see 1st post).


Coming Soon™.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 654
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Box physics problems

Postby Wuzzy » Yesterday, 22:47

The animation tweak is bit better than before but the color's still off, I believe.
I like bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)
User avatar
Wuzzy
 
Posts: 831
Joined: 28 May 2012, 23:13

Who is online

Users browsing this forum: No registered users and 0 guests