collision

Be not worried. There are libraries which work with collision like box2D but your headache will not go away so easily anyway. Start by small steps and learn on your own how it works.

Or do it like in old days where game had only limited cpu power and gpu could only render a simple canvas. This works even for platformers. So use a canvas let’s say 800x600 pixels and draw on it some images. This is only graphical and will not serve as collision because the pixels could be overdrawn by layers that move or backgrounds. But this is how they worked. GetPixel is a function that would return some color number and that number decides the collision happened or not.

One step later i decided to use an collision image that is doing the thing correctly. First i draw it onto canvas as graphics the original image. And then onto another collision canvas i draw the collision mask of another image with perhaps similiar shape. Now the player can walk on ground and will not fall down through geometry. Nice and fast. But only when you do not overdraw the collision canvas each draw or update call. Why? Because the function that retrieves the rgba values from the collision canvas is slow and allocates new memory.

So either use the canvas method which will be slower even today where canvas was overthrown by libraries using physics cards or mathematical shapes to represent collision properties. My problem with this is that without good setup you will even fail at making a simple arkanoid game. Yes, better do the job by using another approach and that is own collision methods that calculate the ball vs wall vs brick vs pad and do the things they need to do when hit.

That is all. But there are games which do not need such collision madness. For example rpg maker where player moves 32 pixel every step and it is tile based will not suffer from collision errors and will do fine. Iddle games where you only have animations are too, no need for collision there. Decide and go only where you can do the math correctly.