Well, a few points I'd like to make here. First of all, that project of mine that was mentioned was meant to be more of an idea test for auto filling regions in the mapper. That kinda takes a lot of the difficulty of fairness away since the person doing that mapping can accept or reject what the algorithm outputs well before a game is started.
As for the possibility of a random map type of level, and ignoring fairness for the moment, it's quite possible from a technical perspective. The map generation code can be placed in a level DLL. Having everyone randomly generate the same map isn't a problem either. When the game starts, all people in the game share the same random number seed, so if you're using the random number generator that OP2 exports functions for, you'll all generate the same sequence of random numbers. Thus, you'd all generate the same map without having to send it to other people. That's one way the game stays in sync without adding a large communication overhead. Instead of sending things like random weapon damage during combat, every client just generates the same random number themselves, so the only data that needs to be sent are the actual player commands.
Also, I'd like to point out that any map that's randomly generated would need to have player start locations accessible from one another. It'd be no fun if players were put on either side of an impassible ridge with no way to get across it. Or even worse, if one player was stuck on a small "island", and the other player(s) weren't. It'd be especially bad if the so called island was small enough that everywhere on it was within weapons distance of people off the island. Mind you, that's not such a hard problem to solve. Just do a breadth first search traversing all passible tiles from one start location, and see if it reaches the other start locations. You can also create some sort of template base area to ensure fairness within the immediate region around a base, but there may still be issues for the surrounding regions. Things like narrow mountain passes on the rest of the map, or the number of paths from one base to any other given base location, and the distribution of resources would all be concerns.
I'd also like to point out that the current map generation algorithm has certain glitches. The easiest to notice is that not all tiles it places next to each other really fit next to each other graphically. This can be improved or eliminated by using a better data set. The next big problem is the order in which tiles are generated, and the restrictions adjacent tiles put on each other causes transitions between terrain types to appear along diagonal lines from the top left to the bottom right. With the current test code I was using, it's very unlikely that a sequence of random numbers would allow for much transition along any other line. There is a change to the algorithm that I know of and would fix this problem, but it could greatly increase the memory and time needed to generate the map. Which brings me to my next point. The current test project (written in VB) is much to slow to really be used in generating a full sized map. The test project only generated 32 x 32 tiles. Also, ignoring the problem of speed, there is also the problem that it might never finish. It is possible for this type of algorithm to get stuck in an infinite loop and never finish outputting a map. It depends largely on the data set used, and the order in which tiles are placed. I see no easy way to know before hand if the data set allows for this possibility, and no way to reliably detect if the algorithm is stuck, or just being slow.
