You could define your movement in terms of "design units". In other words, you figure out how much "logical" distance a sprite would cover in a certain amount of time, which is then scaled dynamically based on the window resolution.
To do this, first, visualize your game screen as a grid, perhaps 100 by 100, or 160 by 90 (to fit 16:9 resolutions), or some other value. Each asset is placed along this grid on the X/Y axis, as appropriate. First, you calculate where the thing would be in terms of its logical location, which is then upscaled to the device's resolution.
In this system, 160 by 90 would be exactly 12 pixels per unit at 1080p, exactly 8 pixels at 720p, etc. So in one resolution, the sprite would move 12 pixels, and on another only 8 pixels, but would move the same physical distance on the screen (assuming screens of the same size), or the same relative distance (e.g. expressed as a percentage).
Some languages, like Flash/ActionScript have a default resolution expressed in logical units, others allow you to design your own, and others still will require that you do all the scaling yourself. If possible, consider using some variant of SVG (Scalable Vector Graphics) instead of bitmaps (PNG, JPG, GIF, TIFF, etc) in order to minimize the visual artifacts.
You haven't specified your platform, so the precise answer about how to do this will vary, but the general idea is that you should separate the logical units (where things are placed in relation to each other) from physical units (pixels).
Note that you could still choose to use bitmap-based graphics, but the quality will suffer somewhat. Typically, games like this tend to look "blocky", but that's often done intentionally for nostalgic purposes, as if it were an 8-bit game created in the 1980's instead of a modern game. There seems to be a lot of that going on in the market today, so you might decide that's your look. Try searching on your favorite search engine for "retro game design" if you're not sure what I'm talking about.
