See now that's why I prefer to put all entities into one table.
I'd recommend looking into a collision library like Bump which will let you have each entity type in its own table but still handle collisions between any entity anywhere. The only problem is it's a bit advanced.
So without bump I'll try to make it as simple as possible. Basically you need to loop over the same table for every item in that table by having nested for loops. Basically:
for a, e1 in pairs(entityTable) do
for b, e2 in pairs(entityTable) do
if a ~= b then
-- Handle collision here
end
end
end
You'll have to do that for every entity type that you want to have collide with its own kind. For bullets you'll want to not do this since who cares if bullets pass through each other, unless that's part of your game. (Maybe enemy bullets could be deflected by player ones) Either way, that's how you'd do it in a nutshell.
part is very important because otherwise they could collide with themselves. I tried something similar without this chunk(in short - faster squares stopping/slowing down if bumping into slower ones) and all squares stopped themselves.
I have another question.
Thing is that I made another "game" to test collision. I made fine collision check and reactions when player collides with map's boundaries, but I have problem when it comes to collision with square.
When player moves onto object, it "glues" to this, preventing "sliding" to sides.
When I made reaction that pushes player in opposite direction, player slides in one way, around the object, even if I still choose to directly "push" the object.
Probably it's because player's cube "pierces" the object, so it not only fulfils condition from one direction, but gets caught by one of the sides. (when player collides on x level, also gets into y's conditions, which means being pushed in one of random directions)
With split X and Y I mean that you change x and then y coordinates, not only colliding.
oldX will backup the x coordinate so you can reset it. It's looks better than simple stopping you.
I hope I have helped you.
So what I'm supposed to do is (basing on simple version):
— split movement function into X movement/collision and Y movement/collision
— to each part add local (I don't know why local, maybe because is used only in love.update, tell me) oldX or oldY
— move coord change outside of keycheck function
How I think it is supposed to work:
0. Game speed, collision with objects
1. Reset of all player's velocity
2. Check for pushed key for X velocity, changing velocity if check is true
3. Making back up of old coords
4. Old coords in normal variables changes to new coords
5. Collision check - if collided, program moves you to the oldX/Y position. It's saved properly because program went through it only one time
6.Because X and Y are split, program will check X first, preventing Y collision check from screwing up the proper reaction if player "pierced" the object.
7. Do the 2-5 steps for Y part.
8. Does other stuff if there is
9. Restart.
— to each part add local (I don't know why local, maybe because is used only in love.update, tell me) oldX or oldY
I use 'local' only because it's cleaner and because you don't need this variable again.
1. Reset of all player's velocity
If you want a smooth running effect, you should use velocity like in advance.love, but of course you can do this later, it's not so important at the beginning.
Thanks, I'm making super simple game now, but who know? Maybe I will make something bigger next time.
...
Is there a way to rotate these rectangles? I know it's simple with images, but what about generated stuff?
Neverming about previous question, I can just use images.
But I have more important one:
I started doing bullet making code and I have seen that I can't shoot bullets when I'm moving diagonally, except up-right, why? How to fix it?
EDIT: This is happening when I use space (" ") key to create single bullet, but when i binded it to "z" it works correctly. Why?