It's always unfortunate when you don't know exactly what to google for. What would you call an algorithm that takes care of collisions in a block-pushing game? Not the collisions themselves, though. But if two objects try to converge on the same space, or are moving in the same direction when the lead object suddenly gets blocked... dealing with all those issues, yknow. It seems like something that has probably been done better than I'm doing it. Right now I have it so all of my objects attempt to set a destination in some direction depending on how they're controlled. Then I do a bunch of checks, some fairly expensive, between all the objects in the playing area to figure out who should carry out their destinations and who should cancel. It's just on paper right now and I'm not positive it will work, or that it's a good idea... anyone have a good place to point me for this?

You can try searching for collision response though I doubt you will find relevant information to your problem.

Most block pushing games that I have seen are tile based. As such they use an array to represent the tiles on the screen. If you start at your current tile position and look at the position in the array in the direction that you are traveling, it should become possible to see if there is an obstacle at that position.

I hope this makes sense.

Good luck!

Yeah they're usually tile based but i wanted half tiles to be available as well. I could just keep things done that way internally,m but i STILL run into problems like this

|>| |
| |^| <- 0,0 and 1,1 are both planning to move to 1,0 at the same time.

Technically neither are blocked. What i'll probably do is check against both the other object's position AND its destination.

If you want half-tile moves then simply make your internal grid representation twice the size.

2 objects trying to move to the same position at the same time may seem complicated on paper, but when it comes down to actually programming it there's no such thing as "the same time" (lets assume youre not threading). One block is going to decide to move to a position before another block is, even if they both are going to try on the same frame. The block that gets evaluated first is the block that gets to move there. That block marks the grid location as occupied. The next block runs it's logic to move, decides it wants that same grid location, checks, and sees that it's occupied and does whatever a block does in your game when it can't go somewhere it wants.

[edit]
Depending on what kinds of behavior you want, you can also add a bit more information and decision making to this process. For example, perhaps block 1 gets evaluated and says "I want to move to grid 1,1. I am currently X units away, travelling Y speed, and have Z powerup or ability". So now grid 1,1 has an "intent to occupy" state with some information, but block 1 hasn't moved yet. Block 2 gets evaluated, also decides it wants grid 1,1. Block 2 checks the stats of the block that has an "intent to occupy" (block 1), and if block 2's X Y and Z are better than block 1's, block 2 puts it's data in the intent to occupy position and notifies the previous block (block 1) that it can no longer move there. At this point you can either tell block 1 to not move, or you can even re-evaluate what it wants to do now that grid 1,1 is unavailable.
[/edit]