I like this idea.
A couple suggestions.
- Mark the tile index ints as const.
const int FirstRockTileIndex = 439;
const int FirstSandTileIndex = 1206;
- Mark the parameters as const references.
bool CanTileBeDozed(const LOCATION &location);
void DozeLocation(const LOCATION &loc);
void DozeRectangle(const MAP_RECT &mapRect);
- Add comments for terrain type:
GameMap::SetTile(loc, 1670); // Sand (or whatever is appropriate, I didn't check)
The reference makes parameter passing faster, and avoids needless object copies. You don't notice it at the source code level, but it adds a lot of noise at the assembly level. Adding const to the parameters (that are now references) allows variables that are themselves declared as const to be passed to the function. The location of a player base is likely to be declared as const. Normal variables can of course still be passed to a const parameter. The const just means the compiler will guarantee there are no writes to that parameter.
It might also be nice if people could comment on the suggested names (function names, parameter names, file names), to make sure they are clear, and fit in with the other names in the project. This can always be changed after an initial commit, but as names affect source code compatibility, particularly the function names, this should be reviewed before people start using the additions.
Taking a quick look at existing names, I see a few boolean valued functions named "Is...". Maybe "IsBulldozable" would fit better? I'm not sure I love the name. Perhaps you'll have a better idea.
You can potentially make use of function overloading and name both DozeLocation and DozeRectangle as simply "Doze". The different parameter types will be enough to distinguish them. Using clear variable names can also make the intent pretty clear. For example "Doze(baseRect)"/"Doze(baseArea)", or "Doze(meteorImpactPoint)".
Probably more consistent to strip "Helper" from the file names. That's used for the project name and main include file, but not the other include files.