yaahc / gameoff

Our entry for https://itch.io/jam/game-off-2018
Other
7 stars 7 forks source link

Collisions #8

Closed yaahc closed 4 years ago

yaahc commented 5 years ago

blocks #2

The next step is to add some basic collision logic. The initial plan is to have every tile that is not a walkable tile be treated as entirely impassible. Many of the walls in the current test sprite set actually have half of the wall tiles looking like floor so it will end up looking like the character cant get all of the way to the walls, but I'm thinking that wont be an issue if we base the collision on the center of the character model vs the edge of the floor square, rather than edge to edge.

No idea how collisions work in amethyst, next topic of research. :)

yaahc commented 5 years ago

First look doesn't show any collision specific logic built into amethyst itself. But ncollide looks quite promising. https://www.ncollide.org/collision_detection_pipeline/

Beyond that I'm guessing that for collisions with tiles using a broad phase / narrow phase collision algorithm stuff is stupid overkill. It should be pretty trivial to calculate exactly which tile we're trying to move to given the updated position from a move, and we can have a 2d array that tells us if said tile is passable or not. We'll reserve ncollide for things like enemies and projectiles.

cobalthex commented 5 years ago

depending on the level of collision detection we want, we may be better off doing it ourselves. esp some of these full blown physics libs are way overkill for a lemmings type game.

yaahc commented 5 years ago

If we're keeping the number of entities that we actually have to check for collisions with the player down then I absolutely agree, iterating through 20-30 projectiles to see if any are touching the player is pretty trivial.

However I am pretty interested in seeing the state of the current ecosystem for rust gamedev libraries, so I do want to play with ncollide if we have time.

cobalthex commented 5 years ago

best way to handle collision detection is to break up into some sort of spacial representation and only check things that are nearby. we could probably get away with only a broad phase (if that)

yaahc commented 5 years ago

My understanding is that is exactly what ncollide2d does

yaahc commented 5 years ago

gabes planning on working on this task.

yaahc commented 5 years ago

The work on collisions is I think closely related to the work that needs to be done on projectiles so you might want to do these together. Paige already gave us a bubble asset so I'd start there. Make it so you can press a button to shoot bubbles (temporary filler, not planned to be how attacks actually work). Then have these move on their own and resolve collisions between them and enemies or walls or w/e and have those do damage as applicable.

One thing to keep in mind is that right now movement as shown by the player movement system is tied to framerate which is no bueno. Theres documentation in amethyst for how to separate this and make the movement depend on the time delta between frames.

use this as reference https://www.amethyst.rs/book/master/pong-tutorial/pong-tutorial-04.html#create-systems-to-make-the-ball-move

We don't necessarily want to do collisions how they do it though, but use your discresion. I'm leaning towards using ncollision2d but feel free to implement it however you want, so long as it works without killing performance :).