There will be 6-10 on average in each class.

On current typical hardware these are the memory breakpoints that might matter:

(Most Intel L1 cache) 16k
(Most AMD L1 cache) 64k
(some L2 cache) 512k
(other L2 cache) 1024k
(again L2 cache) 2048k

If you are using more than a 512k dataset with the smallest possible datatype (the smallest common L2 cache size) then access patterns are more likely to determine your performance than the datasize itself, so use 32-bit because you avoid some write stalls which will always be there subtly undermining all smaller memory accesses.

If you can squeeze your data down to under 512k (but above 64k) by using a smaller datatype, then this will more often than not be a bigger optimization than access patterns. But its a close call. Profile after every subtle access pattern change.

If you can keep it under 16k (Intel) or 64k (AMD) then by all means use the smallest datatype. Absolutely no reason not to.

Typically,

reading from L1 cache takes ~3 clock cycles

reading from L2 cache takes ~10 clock cycles

reading from main memory takes ~100 clock cycles


Avoid the 100 clock hits if you can, and use an access pattern to minimize them when you must. Random access to more than 512k of memory will kill you.

From a performance point of view it also really depends on how complex the calculations you're doing with those ints are. Since CPUs are so much faster than RAM, if the calculations are simple enough a 2x reduction in space could give a 2x increase in speed.

But for an RTS, I really doubt this. If your maps are 5120x5120 that's potentially at most 2.5 million units, but if somebody really puts that many units on a map they shouldn't be that surprised if the game starts going slow.