I've been playing around with collision detection methods for my game and have become interested in seeing how one would implement a collision system separate from the movement logic. A lot of collision systems I see depend on the object storing its future position after moving and checking if that future position collides with the map and modifying that position accordingly before finally moving to that new position.

However, I know that some games separate the collision logic from the movement logic so the object just moves to its future position and instead a separate global system loops through objects and handles collision itself. Does anyone know how I could go about implementing this type of system?

Would this separation of movement and collision logic also prevent objects from communicating their intent of moving to the collision system?

If that is not the case, you could queue every intent of object moving to the collision system which would check the destination coordinates against the restricted set and return a go-ahead or a reasonable replacement destination.

Would this separation of movement and collision logic also prevent objects from communicating their intent of moving to the collision system?

If that is not the case, you could queue every intent of object moving to the collision system which would check the destination coordinates against the restricted set and return a go-ahead or a reasonable replacement destination.

I see how that could work. Would being able to check the velocity in the collision system be an example of the collision system knowing whether the object intends to move work? Also, would there be a need to ensure that the collision system ticks at a certain rate relative to the object? Or is it ok if the collision system ticks at a different rate from the object?

Would this separation of movement and collision logic also prevent objects from communicating their intent of moving to the collision system?

If that is not the case, you could queue every intent of object moving to the collision system which would check the destination coordinates against the restricted set and return a go-ahead or a reasonable replacement destination.

I see how that could work. Would being able to check the velocity in the collision system be an example of the collision system knowing whether the object intends to move work? Also, would there be a need to ensure that the collision system ticks at a certain rate relative to the object? Or is it ok if the collision system ticks at a different rate from the object?

For the first part I'd say that would be a bad practice if the number of objects grows. You would have to keep track of every object that can move and check it's velocity every tick to figure out whether you have to do anything to it or not. These loops would probably slow down your performance. What I would suggest is more of a trigger system or an event based system where an objects that wants to move triggers an event which tells the collision system the next time it ticks to take action on the object that triggered the event. Which pretty much also answers your second part of the question. Events can even be triggered by objects on other threads so no you don't need syncronous ticks.