Most games will use float simply because "it just works" (most of the time). If a game has special requirements, such as levels that span 100's of kilometers, then you'll often see other solutions used, such as double-precision float, or 64-bit integers.
Older games (e.g. SNES) would've done everything using integers, because back in that era, floats either weren't supported in hardware, or were very slow.

I know this by "sniffing" at the packets received

This doesn't necessarily tell you the truth -- many games use floats internally, but then will quantize to a fixed-point integer format for transmission over the network.

1) Look up 'fixed point' arithmetic. You can use an integer and choose how many decimal places of precision you require. You can convert to and from float if/when required.
2) Make an increase of 1 to the integer value represent a very small amount of distance, like 1mm.
At 1mm precision, a 32-bit integer allows for a ~4000km map width.

3) There's endless solutions... If your game objects are only ever allowed to be positioned either at a node, or performing an (uninterruptable) animation/slide between two nodes, then you can use one integer to specify which node they're at, and another integer to represent a fraction of how far through the movement animation it is -- e.g. you could say that -99 means that it's moved 99% of the way through an animation to the left, 0 mean it's not moving and 99 means that it's 99% of the way through an animation to the right.
e.g. some very simple movement code:

int position;//where is the player
int fraction;//how far through their movement animation are they
int playerInput;//1 to move right, -1 to move left, 0 means no input

onUpdate:
if( fraction == 0 && playerInput != 0 ) //not moving at the moment, and player is asking us to move
  fraction = (playerInput>0) ? 1 : -1; //start moving either right or left
else if( fraction > 0 )
  ++fraction;//if we're already moving right, move another 1% of the way there
else if( fraction < 0 )
  --fraction;//if we're already moving left, move another 1% of the way there

if( fraction == 100 )//if we're finished animating to the right, then update the position
{
  ++position;
  fraction = 0;
}
else if( fraction == -100 )//if we're finished animating to the left, then update the position
{
  --position;
  fraction = 0;
}

//If the renderer wants a floating-point position, we can give it one:
float renderPosition = (float)position + fraction/100.0f;

n.b. this code doesn't take frame-rate into account -- it's hard-coded so that one move takes 100 frames.

Then instead of using two variables (position and fraction), fixed-point allows you to put both those values into a single packed integer variable (whole part and fractional part).