acme_pjz {l Wrote}:Yes, the half-baked collision detection code (written in 2012--2013 ?) has a lot of nasty bugs. I managed to fix most of them (see git rev 5269929, 1234a8f, 4a0fbf4, ... ) but there seems still bugs, for example in level 19 "subway surf" in Akos level pack you'll be squashed when you standing on a block moving up while another block moving up at a higher speed.
![Sad :(](./images/smilies/icon_sad.png)
Yeah, the collision system is indeed not great and it seems that a fix/tweak generally has some undesired side-effect. The current state of master seems okay, apart from one thing: pushable blocks
I tried simplifying the collision system as a POC, using the following notions:
- All blocks except pushables can be updated without problem (as they don't influence each other)
- All pushable blocks will update after all other blocks have moved
- Rather than combining "base velocities" and movement "velocity", change it to two phases: "forced movement" and "voluntary movement"
- Rather than pushing the player, his shadow or pushable blocks iteratively, determine the "forces" and push them out of the blocks (makes this step order independent)
The "forced movement" is the movement coming from the delta of the block the player or pushable block is standing on. After applying this movement, a check is done to see if there are any overlaps with blocks, if so a push "force" in each direction is determined to push the player or pushable block out of it. The current code for that can behave differently depending on the order of the blocks, the POC approach doesn't.
If the player or pushable block no longer collides after "forced movement", they can start "voluntary movement" (which does include gravity). This now becomes a lot simpler as it's simply seeing how many of the desired pixels it can move before it hits something. The standing on check is still a bit complex, to handle the 50% on conveyor belt and moving blocks scooping the player/pushable block up.
Even with those changes, quite a few problems remained, and they all had to do with the order in which the pushable blocks were moved. I tried to sort them using a heuristic that ensured any stack of pushables would be updated from bottom to top. But even that is not sufficient as not being part of a chain, does not mean you are not influenced by pushable blocks in the chain (or even will become part of the chain in that update). In the end I didn't manage to find a reliable ordering, so I opted for having the pushable blocks indicate failure and processing it in multiple rounds until stable or after X amount of rounds. The end result works, but not very nice
I've committed the code to a branch on my repo (wip/collision) if you want to try it out, I've also attached some testing levels I've used, which illustrate several of the problems/difficulties.
acme_pjz {l Wrote}:I think activate multiple switches at once is OK. Personally I don't like the approach that only activates the nearest switch. Plus, it certainly will break old replays.
![Thinking :think:](./images/smilies/icon_think.png)
I'm fine either way, I also think it's generally not a great idea to place switches in adjacent blocks, anyway. What should be done IMHO is give visual feedback which switches are going to be activated. Perhaps with an outline or something?
That way the player won't be surprised if they are overlapping the adjacent switch by only a pixel or two.
With regards to breaking old replays, we should indeed avoid it where we can, but almost any changes to the collision/movement/activation might break replays.
At the very least we should ensure we don't break levels with the changes we make.
I don't know... do we need to remove them?
![Sad :(](./images/smilies/icon_sad.png)
I don't like that.
I also wouldn't like that, on the other we can't have levels/levelpacks with unclear licenses in our repo. Most of them will still be around on the forum, so they won't be totally gone.
In any case, I have contacted everyone and awaiting there response, I have good hope that we will hear back from most of them
acme_pjz {l Wrote}:@Edward_Lii, my plan is release V0.5 Beta version next weekend, at around Aug. 19. There are no code-wise tasks left in my checklist. Is this time period too short for you to find bugs?
My biggest concern at this point are the pushable blocks. For the most part they work fine, but they are so sensitive to the block order, that it can be very tricky to make levels with.
If we were to release them in the state they are in, I would probably only use pushable blocks in "controlled environments", which rule out certain level ideas I had.
Other than that, I think next weekend would be nice for a beta release. Throughout the week I can find some time to do some final extensive testing.
Afterwards, it would be all making levels, playtesting and translating.