Jitter / bouncy actor caused by colliding with multiple "Floor" actors?

[jaredegan]

Hi, I've been playing around with Excalibur, building off of the "sample-platformer" repo. That project has a Floor actor that draws rectangles and has big rectangular based Box colliders, and that floor works well for a platformer.

I added the ability to define a level based off of text to act as a quick level editor to tide me over before trying out something better like Tiled. So my code would take an array like this:

[
        '                      #                         ',
        '                     ####                   ',
        '#           P                                  ',
        '#          ####                            ',
        '#                                               ',
]

And loop over it like this:

const spriteSize = 8;
    const verticalOffset = 4;
    level.tiles.forEach((row, i) => {
      const chars = row.split('');
      chars.forEach((char, j) => {
        const x = j * spriteSize;
        const y = i * spriteSize + verticalOffset;


        switch (char) {
          case '#':
            const f = new Floor(x, y, 1, 1);
            console.log(`Adding floor at ${x}, ${y}`);
            this.add(f);
            break;
          case 'P':
            this.player.pos = vec(x, y);

            this.add(this.player);
            break;
        }
      });
    });

So my world will be built of 8x8 blocks. The floor made one 8x8 actor / collider at a time. The Floor class is essentially unchanged from the demo project.

The result is the attached gif. When my player walks along colliders constructed in this way, this jitter happens. There is some idle animation in that gif, but you can tell what I mean by the jitter. This jitter doesn't happen if I make the floor as the "sample-platformer" code had it. I assume this is the "odd oscillating behavior" mentioned in https://excaliburjs.com/docs/physics#limitations

Do you have any recommendations for me? If I make my floors / walls as bigger, continuous colliders, will that be a good strategy? What if my player is in a corner of a wall & a floor?

Thanks,

• Jared

[eonarheim]

@jaredegan I've taken a look, I'm able to reproduce this behavior when the floor collider is smaller width than the player collider width.
To work around the issue, making the floors wider than the player seems to remove this oscillation. I believe that when the player collider straddles two or more Floor colliders the upward resolution is applied from all floor tiles causing the observed over-correction unfortunately.

Appears to be a bug in the currently released Excalibur collision implementation. I think this is the culprit, instead of resolving position immediately after each pair, each collision is calculated then resolved, which allows multiple collisions to queue up that might no need to happen if the first was resolved. https://github.com/excaliburjs/Excalibur/blob/main/src/engine/Scene.ts#L382-L384

One wide actor, custom tiling draw

let platformX = engine.halfDrawWidth + 50;
for (let i = 0; i < 1; i++) {
    //  1 actor for 10 floor tiles
    const f = new Floor(platformX, 200, 10, 1);
    engine.add(f);
    platformX += 8;
}

Actor per tile

let platformX = engine.halfDrawWidth + 50;
for (let i = 0; i < 10; i++) {
    const f = new Floor(platformX, 200, 1, 1);
    engine.add(f);
    platformX += 8;
}

We are working on some improvements to the collision systems that I believe will eliminate this behavior (I will confirm that though) because the resolution takes into account collider separation at every velocity/position resolution step.

• feat: ECS based Motion + Multiple Collider Support + Improved Collision Simulation #1818 - v0.25 release

Unfortunately v0.25 is also coming with a few bigger changes in addition to the collision simulation improvements.

Potential workarounds/solutions

1. Wait for v0.25 to be released and upgrade, but there will be some effort involved to upgrade your game
2. Perform some custom tiling
   • To keep the level parse logic simple and similar to your current implementation modify the 8x8 Floor tiles to be CollsionType.PreventCollision then have a second pass to create an invisible collider Actor that is the full width of the platform
   • Or more complicated parse logic that can detect the "run" and figure out the run of tiles per floor new Floor(x, y, 10, 1);
3. Patch the compiled excalibur.js artifact and live in a custom world for a while, I can post a version of the excalibur.js file but the gist is
   • This splice does collision and resolve for each pair before proceeding (gist with patch applied)

   // line 10762
       DynamicTreeCollisionBroadphase.prototype.narrowphase = function (pairs, stats, delta, strategy) {
           for (var i = 0; i < pairs.length; i++) {
               pairs[i].collide();
               pairs[i].resolve(strategy);
               if (pairs[i].collision) {
                   pairs[i].colliderA.body.applyMtv();
                   pairs[i].colliderB.body.applyMtv();
                   // todo still don't like this, this is a small integration step to resolve narrowphase collisions
                   pairs[i].colliderA.body.integrate(delta * _Physics__WEBPACK_IMPORTED_MODULE_0__["Physics"].collisionShift);
                   pairs[i].colliderB.body.integrate(delta * _Physics__WEBPACK_IMPORTED_MODULE_0__["Physics"].collisionShift);
               }
               if (stats && pairs[i].collision) {
                   stats.physics.collisions++;
                   stats.physics.collidersHash[pairs[i].id] = pairs[i];
               }
           }
           return pairs.filter(function (p) { return p.canCollide; });
       };

   // In Scene.prototype.update line 23288
   while (iter > 0) {
                   // Run the narrowphase
                   pairs = this._broadphase.narrowphase(pairs, engine.stats.currFrame,collisionDelta,_Physics__WEBPACK_IMPORTED_MODULE_1__["Physics"].collisionResolutionStrategy);
                   // Run collision resolution strategy
                   //pairs = this._broadphase.resolve(pairs, collisionDelta, _Physics__WEBPACK_IMPORTED_MODULE_1__["Physics"].collisionResolutionStrategy);
                   this._broadphase.runCollisionStartEnd(pairs);
                   iter--;
               }

[eonarheim]

Apologies, this is an unfortunate bug in excalibur, hope this helps out!

[jaredegan]

Thanks for the thoughtful and very thorough response! I should be able to make one of these workarounds work, and I'll look forward to 0.25. This is very much a hobby project / prototype so it may be a few days before I can give it a shot.