From a cursory glance I don't see any obvious issues with the code. Although, I do have two small suggestions for slight code improvements.
The smaller change idea would be to change the declaration of "s" from a short to an int (or possibly even an unsigned char).
This is simply a (very minor) efficiency improvement. I know you don't need the full range of an int, but due to data alignment issues, either data type will take up 4 bytes of data storage. In the case of the short, those extra two bytes just become useless padding bytes. Also, since x86 code runs 32 bit natively, it takes a special opcode prefix for every instruction processing the data to switch to 16 bit processing, which takes up extra space in the code segment and more time to execute the instruction. So, shorts end up being the same data size, but produce larger and slower code. Basically, you should stay away from shorts for x86 code unless you either need to be compatible with something else, or you have an array of data (which has no padding between elements), and hopefully don't do a lot of processing on the data.
Btw, 8-bit values can usually be processed just as easily as 32 bit values (without an opcode prefix). Although, if they are used in an address calculation, such as array indexing, they must be promoted to 32 bits, which may take an extra instruction. Data alignment issues also apply to these, which may cause a single variable to also take up 4 bytes instead of just 1.
Some of that alignment padding can be eliminated by packing data types of similar sizes together so that none of them cross a 4 byte boundary. You would of course have to declare a number of variables with a data type smaller than 4 bytes. In theory an optimizing compiler could do this. In practice I've never seen the MSVC compiler do this except for struct declarations. In other words, freely declared variables such as you've used will never do this under MSVC.
Also, the code size expansion from using 16 bit data types may not always be noticable due to code section padding/alignment which may round the size of the code section up. This is usually done in 4KB increments. So using a short might just will more of a partially empty 4KB code page, or it might cross a boundary and cause the exe size to jump up by 4KB. The speed issue from having to process the opcode prefix still applies in any case.
The other suggestion is to replace the switch statement with an array lookup. If you notice your case values form a nice compact set of integers that could easily be array indexes. Further, the only change in the code from one case to the next is the numeric values being passed to the function being called. Instead, you could refactor the code so those values are placed in an array (probably an array of structs, where each struct contains an x and y value), and simply to a lookup in that array rather than use a case statement. The code will be far smaller and easier to maintain. It should also produce more space efficient machine code.
I'll take a stab at writing untested code as an example. Just don't be surprised if it doesn't compile.
struct Location
{
int x;
int y;
};
// Declare starting location data in an array of structs
Location startLocation[] = {
{30, 91},
{98, 38},
{30, 30},
// ...
};
// ...
// Modified code
// Go through each active player
for (int s = 0; s < TethysGame::NoPlayers(); s++)
{
LandRushCreator rushClass;
//Uncomment the next line to setup other starting resources
//rushClass.customRes = true;
// Get start coordinates with simple array lookup
location = startLocation[s]
rushClass.CreateFullLandRush(s, location.x + 31, location.y - 1);
}
I usually avoid case statements. I find whenever they are used, a more compact data driven solution is usually possible. Either that, or I find myself using virtual functions for some class hierarchy, which is pretty similar, but again, less code and essentially backed by a table based lookup scheme.