Games, of course, require a lot of motion. Characters and bullets need to be able to fluidly move even if the background is static. To accomplish this, video game hardware makers came up with the concept of sprites. While I have yet to find a definitive reason why the term sprite was chosen, it is the word used to describe images with partially transparent regions that can be moved on the screen without destroying the image behind it. While this can be done in software, doing so in hardware is much faster and is often the way that game consoles handled sprites.
In theory sprites can be any size, though console hardware tends to use uniform sprite sizes and requires programmers to combine multiple sprites if they want one larger than the default size. 8x8, the same size as tiles on the tile map, is the common default size. The next question is how many sprites? This is actually a more complex question than it sounds. Hardware sprites commonly had issues with there being restrictions on how many could be displayed on a single line at the same time. I am going to assume my chip designers are really good and managed to allow for 16 sprites all of which could be displayed on the same scan line. More importantly, the sprite data can be changed on the fly so by using raster-line tricks, more than 16 sprites can be displayed. In case you are wondering, the specs for the various 8-bit systems that I looked at supported 64 sprites (4 times as many as I am going to support) but only were able to display 8 sprites per scan line.