FreeGameDev

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.

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.

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

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:



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.

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

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

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.

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

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

The animation tweak is bit better than before but the color's still off, I believe.

Hi Wuzzy,

the (2) and (3) are also implemented, but I only implemented (3) by taking all blocks (both normal blocks and pushable blocks) into consideration, because I believe that the 2a) is too weird.

Can you check that if there are any bugs introduced by this implementation?

It seems to work good now. I don't think things have broken because Land of Boxes is still functional.

I found a minor thing:

If you place boxes like this:

{l Code}: {l Select All Code}

12
3333


3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2. This is a bit strange, but doesn't seem to be serious as it's only a tiny offset. But I still mention it, just in case.


By the way: I see you added achievements. Please don't forget to update Weblate.

Wuzzy {l Wrote}:I found a minor thing:

If you place boxes like this:

{l Code}: {l Select All Code}

12
3333


3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2.

Oh, this sounds not good. Can you check that if it already occurred in previous versions (e.g. one or two git commits earlier) ?

Wuzzy {l Wrote}:By the way: I see you added achievements. Please don't forget to update Weblate.

Yesterday Hosted Weblate had some quirks. I'll update pot files when they are fixed and before the next alpha (or beta) version.

I tested again, and it also occurs in dadea5643ad2ae3a3a732351822724007af25491.

Wuzzy {l Wrote}:I found a minor thing:

If you place boxes like this:

12
3333

3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2.

...

I tested again, and it also occurs in dadea5643ad2ae3a3a732351822724007af25491.

I think I can't fix it in an easy way. There is no such bug if the player push the box to the left. If you use the moving block to push the box, then the same bug occurs, no matter if you push it to the left or right.

Also, this bug can be abused to push multiple boxes at a time, for example:

{l Code}: {l Select All Code}

  1234
P 5555 <-M->

P is player and M is moving block, if you keep pushing block 5 and 1 to the right, you can push all the boxes 1,2,3,4 down to the ground