# On the topic of bits, I have heard that certain game uses different bit counts for maintaining different data of the game. How often decide which bit count (16/32/64 bits) goes to each data counter, and why don’t 64 bit games just use 64 bits for everything?

Some readers may not realize it, but you’re actually asking a math question here. A bit is a value that can be one of 2^1 = two different values - 0, or 1. Thus two bits can represent up to 2^2 = four different values - 00, 01, 10, and 11. Three bits can represent up to 2^3 = eight different values - 000, 001, 010, 011, 100, 101, 110, 111. 10 bits can represent up to 1,024 different values, 16 bits can represent up to 65,536 different values, 32 bits can represent up to 4,294,967,296 different values, and 64 bits can represent up to 18,446,744,073,709,551,616 different values.

As you can see, 64 bits has a much larger range of potential than, say, 8 bits. However, just because it can store a lot of different values doesn’t mean that you want to use 64 bit values everywhere. Imagine that I’m working on a game that has committed to four playable races - dark elf, hot elf, keebler elf, and santa elf. If I used a 64 bit value to store the player character’s race, I’d wasting a large amount of that usable space - I really only need two bits to represent the four different possible races on a character so I would essentially wasting 62 bits of memory to store that one value. However, locking myself in to two bits for the player character race means that I’m also committing to never adding a fifth supported race (e.g. hers elf) for the lifespan of the game, because I would need additional bits to represent the fifth race. If I were forward-thinking, I might split the difference and give myself four bits (16 total races, room for up to 12 additional races) for the lifespan of the game.

Your question topic is known in programmer space as “bit packing” because the most efficient solution is to use the fewest number of bits possible to store the data. This way we don’t waste computing resources that could be utilized elsewhere. A lot of clever engineering is about utilizing facts we know about the game’s design (like the number of supported player races) and using that to shave down the needed bits to represent the data. This usually results in immediately improved performance and problems down the line if the game continues for years and the old assumptions get broken (which is often what happened when many old live service games needed to convert from [32 to 64 bits]).