Hi, I'm making a 2D game and I have a short question regarding where the logic of border collision should be placed.

For my 2D game, I made a small collision engine. In game design, should the collision engine have direct access to sprites? For example if the collision engine detects a collision between the sprite and the border of my game, should the collision engine then directly change the sprites position / velocity? If the collision engine detects collision between two sprites, should it be the one that directly access information such as sprite health bars etc?

My aim here is not to make a game engine, I am simply making a small collision engine for my game to abstract away collision logic, and have possible re-uses for the future. In order to accomplish my aim I would like to understand if it is good practice for the collision engine to access sprite data when a collision is detected. Or if there is a better / more standard design to do this.

Edit* Currently I am setting sprite coordinates from within the collision engine if a collision is detected.

One way you can implement this is for your collision code to have direct control over the state of the sprites, as you've already described. With this design, however, you'll find that things are not well encapsulated. Your collision code check for collisions, decide how to respond to the them, and then act out those responses as a side effect. I think it's better for your collision to be more "functional" and stateless, meaning that it takes as input some objects which potentially collide, find collisions, calculate a suggested response to the collisions, and outputs those suggestions. These suggestions can then be consumed by another piece of code which doesn't have to do any calculation, it simply acts. In this way, your game has smaller, simpler components which are easier to test, debug, and reuse.