When a character in a game walks, no one is moving a skeleton around. In most 2D games the walk is a flipbook: a handful of drawings, each showing one pose, shown one after another so quickly that your brain sees movement. Each drawing is called a frame.
Games rarely store those frames as separate files. They pack them side by side into one image called a sprite sheet. The game then cuts out a small window of that image, a few dozen pixels wide, and slides the window along the strip. Slide it to the next pose, and the character takes a step.
Your game might draw 60 or 144 times a second. The walk animation does not need to change that often. Hand-drawn game animation commonly changes pose around 8 to 12 times per second, and that is plenty for the eye to read it as motion. Drawing a new pose every screen update would need many more frames and the walk would look like a blur.
So a game keeps two things apart: how often the screen is redrawn, and how often the animation moves to its next frame. In the demo above, the slider only changes the second one.
Good games also count in real time, not in screen updates. If a game says "advance one frame every 0.1 seconds" and tracks the clock, the walk looks the same speed on a fast PC and a slow phone. If it says "advance every 6 updates", the walk would run faster or slower depending on the machine.
You could keep 8 separate image files for one walk, and a game with many characters, each with walking, jumping, attacking and idling, would end up with thousands. Loading that many tiny files is slower and messier than loading one image, and graphics hardware generally prefers to switch between fewer, larger images. Packing the frames into a sheet (often called a texture atlas when it holds many different things) keeps everything in one place.
The cost of a sheet is that every frame must be the same size, or the game needs a small data file that says where each frame sits. Many beginner tools and engines read that data file for you.
A walk cycle is a loop: the last frame must lead smoothly back into the first. Look at the sheet above. The character's body rises and falls twice per cycle, and the arms and legs swing in opposite directions. If the end pose did not match the start pose, you would see a small hitch every time the loop restarted.
Three habits help beginners:
Small sprites are usually drawn tiny and scaled up on screen. If the game smooths the enlarged image, the crisp edges turn blurry. Most engines have a setting for this, often called "nearest" or "point" filtering, and turning it on keeps pixel art sharp. The demo above uses it: the character is only 64 pixels wide on the sheet and is shown larger.
Draw a four-frame animation, even a bouncing ball, in any free pixel editor. Export it as one horizontal strip, load it in your engine of choice, and play it at 8 frames per second. Then change the speed and see how the character's personality shifts. Once that works, add a second animation, such as standing still, and switch between the two when the player presses a key. That is the core of how nearly every 2D character comes to life.