Everything a game draws has to go somewhere, and "somewhere" is always two numbers: how far across, then how far down. Nothing else. A player, a coin, an enemy, a bullet, the score text in the corner: every one of them is two numbers being updated a few dozen times a second.
It works like a street address. The first number gets you to the right street, the second gets you
to the right house. Written down, we put them in that order and separate them with a comma:
(340, 120) means 340 across, 120 down.
In math class, the y axis points up: bigger y means higher. On a screen it is the opposite, and that surprises everyone the first time.
The reason is that screens were built to draw the way English reads: start at the top left corner,
go across, then move down to the next line. The very first pixel a screen ever drew was the top
left one, so that corner got to be (0, 0), and everything counts away from it.
So on a screen, a bigger y means lower on the screen. To jump upward in a game, you make y smaller. That one fact catches out every new game programmer exactly once, and then never again.
Nothing stops a number from going past the corner. Walk your player left off the edge of a
640-wide screen and its x keeps counting down: 3, 2, 1, 0, and then -1, -2.
The player still exists, still has a position, and is perfectly fine. You just cannot see it.
Negative coordinates are not errors. They are the answer to "where is it?" when the answer is "off the left edge." That is also exactly why games need a way to keep a value from wandering past a limit, which is the next thing you will build.
In your toolkit, every function you write from here on takes positions like these. When coordinates and the coordinate plane show up in math class, you will already have spent hours inside one.