Notice
You won't be able to use the teleporter (mouse) because it's used to debug, not a part of the game.
Hope you enjoy.
How to best deal with things being squished in a platformer depends on the game's design. You could have the thing get destroyed and removed from the physics immediately. This is the simplest solution, but also the most likely to feel unfair. You could ban movement that would squish something, but that requires juggling responsibility for the physics. Judging by your map design, I think the best way would be to push the player toward the closest empty space, but doing that accurately might still be complicated.
Here's a way to change the code that almost does that last option, but simplified a bit: you remember the last good player position and move the player back only when the box that squished the player is gone.
First, add a shorter version of the solid() function that only checks for boxes. This is needed because this method requires knowing when the problem box goes away.
function occupied()
for b in all(box) do
if boxes_touched(b.x,b.y,7,7,pl.x,pl.y,pl.w,pl.h) then
if (b.col==pl.col) b.detacted=true
if (btn(4)) pl.xv+=b.xv/20
return true
end
end
return false
end |
Next, add a check for if the player is embedded in a wall before the player movement applied. Specifically, add this code right before the for loop with i=1,20 in the player update:
if not rect_afget(pl.x,pl.y,pl.w,pl.h,0) then
pl.old_x,pl.old_y=pl.x,pl.y |
Lastly, add the following code at the end of the movement loop so it will occur if the above check is false (so right before "if time()-pl.gnd<c then"):
elseif not occupied() then
pl.y,pl.x=pl.old_y,pl.old_x
end |
That should cause the player to be momentarily stuck when squished by the moving boxes, but then to be freed once the moving box moves again.
If that's not good enough or you just really want the boxes to stop when the player is blocking them. You could also try adding a check in the box movement code to check if there's both the player in the way and a wall on the other side of the player like so:
if (rect_afget(b.x,b.y,7,7,0) or rect_bmget(b.x,b.y,7,7,0)
or (boxes_touched(b.x,b.y,7,7,pl.x,pl.y,pl.w,pl.h) and
rect_afget(b.x + sgn(b.xv)*pl.w+1,b.y,7,7,0)) then
-- code for box moving horizontally
end |
The problem with that method, though, is that you would need to decide how the boxes respond to that situation. I tested just putting in the above check and it causes the boxes to trap the player because they're still trying to finish their movement.
Wow! thanks a lot. This is awesome! I'll try it later. :)
Finally, I've had a plan like... This.
- change velocities
- player's x += xv
- touch wall? -> go back
- touch boxes? -> go back
- boxes' x += xv
- touch player? -> move player
- player is still touching something? -> die
- player's y += yv
- touch wall? -> go back
- touch boxes? -> go back (player's falling? -> ground = true)
- boxes' y += yv
- touch player? -> move player
- player is still touching something? -> die
- boxes' on the end of track? -> boxes begin to back
Hi @lily.kensa
I'm just not very good at Celeste style games :)
I didn't notice "weird physics". The players flow seems fine to me.
I played it through again. Regarding the difficulty, personally, its pitched just right for me. Every new room takes a few deaths as I work out where the best jumping position is or at what point I need to be changing colours. I know its in the early stages but if there's a way to get the Yellow Circle I don't know what it is, but I'm happy to wait to see how the game progresses. I quite like these slow reveals to the full game - at least I can practice the early rooms.
I really think Celeste is awesome, although I definitely admit it's hard :P
I've changed the order of the first 3 rooms. It's used to make players more familiar with the physics.
By the way, needs the skill, Wall Kick, to get to the Yellow Circle.
[Please log in to post a comment]
