This cart demonstrates basic wall collisions, animation and actor-based world objects. I hope it's useful either as something to study for ideas, or as a starting template for a platformer or overhead map-based game. I noticed a few carts reusing stuff from Jelpi, which is great -- but Jelpi might be a little complex to get started with.
See move_actor() for the important part:
if not solid_area(a.x + a.dx, a.y, a.w, a.h) then a.x += a.dx else -- otherwise bounce a.dx *= -a.bounce sfx(2) end -- ditto for y if not solid_area(a.x, a.y + a.dy, a.w, a.h) then a.y += a.dy else a.dy *= -a.bounce sfx(2) end |
The collisions work like this:
- wall sprites are tagged with flag 1 (orange) in the sprite editor
- solid_area() checks to see if a given rectangle in the map overlaps with any walls
- each actor has a velocity (a.dx, a.dy)
- in move_actor(): before moving an actor along each axis (x, then y), the new potential collision rectangle of the actor is tested against the map. Note the "+ a.dx" in the call to solid_area() to give the candidate position rather than the current one.
- If the candidate rectangle includes a wall, then the movement along that axis is rejected (and it bounces instead).
This means that as long as actors start outside of walls, they should never end up inside a wall.
There are many minor improvements that could be made -- for example, placing the actor exactly against the wall after it collides. But I've tried to keep it simple to demonstrate only the important concepts.
Note that none of this is the 'right' way to do collisions or anything else in pico-8 -- it's just the way I happen to do it.
If you have any questions about how it works, don't be shy!
EDIT: another example -- this time also with actor collisions.
Exactly the same principle, but instead of looking for solid walls, it searches through all the actors and checks for overlapping actor collision rectangles.
Thanks Zep. Actually took a break from a pico 8 game and started work a new one as I was having trouble with wall collisions using the flags.
This proves that I overcomplicated it all :P Might rewrite that game from the ground up following this.
Nice one -- I'm glad it will be useful.
I added another demonstration -- extending the first cartridge to also deal with actor-actor collisions and pushing stuff around.
I modified the example to make it support actors of any size and to inform the side of the collision using callbacks.
I planned to do a full super mario bros to demo these features adding animation and jumping, but i ended adding only the jump and using the tile graphics from this mockup - ( thanks :D - )
I don't know how many tokens i ended up using because there's lot of debug code to show the status of the characters.
Nice demo! Things that I'd change:
-
Remove that clicky music (my head hurts after listening to it only for few seconds)
-
Make character hitbox smaller
- Make character fall slower - current speed while may be realistic, doesn't seem like fun at all.
@zep: Two things:
- I hope this cart will be bundled as demo with 0.1.2
- Your collision system seems to be reactive instead of proactive.
Reactive collision systems, while working (somehow), may sometimes result in object sinking ever so often into other objects/ground.
Proactive systems are much better as if movement you're about to perform will result in a "colliding" state, the movement won't be performed and so object will only move as close to the wall as possible, but not closer (which may happen with reactive collisions at times)
Hi darkhog
I assume that you talk about my demo in the first post because you talk about gravity, wich the zep one doesn't have.
About the things you suggested:
-
That clicky music is result of not working with headphones xD it happened because the zep demo in wich i based on has that sound for collision with walls, and in my demo there's a floor acting like a wall too. I'll update the demo later removing the sound when hitting a floor or a character.
-
The character hitbox size is only to show that the hitbox can be greater than one tile. i can make it smaller and make bigger one of another actor, but i don't know if it matters because it's a tech demo.
- The gravity is more or less (more it seems) like super mario, but i did it mostly to test the high speed movement with the collisions.
Thank you!
Second post was entirely addressed to zep, while first was to you.
I'll probably make one, but not now. For now my Pico-8 priority is to finish Heavy Duty Sprinkler. I'll need wall collisions for my next game tho (it being a platformer), so probably will try to make example. If I won't do it, it will be in the game anyway.
@darkhog anyway, i think that is the actor collision what is reactive in the examples, but the tilemap collisions are proactive. actually, in all three examples, the actor stops before touching the wall without making the movement, and it moves in the frame after it stop. so it's like it bounces but i happen with "bounce" 0 anyway. It's shows better in my example because of the fast speed of falling.
i'll try to minimize the token use for the example i uploaded and then i will try to make the missing step of putting the character along the wall on collision.
Edit:
Did it. 1600 tokens, dobled zep's :P
Please let me know if there's any bug, i'll use this in TMNT
To see "reactiveness" of player collision, try ramming player in zep's example into a wall. You'll see that it goes in for a bit, then bounces off - collision is reactive. If you can't see it, try ramming into wall from different direction, eventually you'll see it.
//edit: Changing player sprites into a solid 8x8 square may help you see it.
This really helped! Hopefully pico-8 will one day be loaded with stuff like this for newbies like me! Thanks Zep and Nineraser
[Please log in to post a comment]