Well, I don't want scripts built into the map for strictly design proposes. Even if we have to create 3 layers (the map and two meta-data layers) under the scenario and campaign, I'm not a big fan on forcing things to be bundled when there's a high likelihood that people would want to use them separately. This also makes it harder to re-use the work of others.
As for the picture being embedded in the map, that's not something I'm opposed to. In order for GAE to dynamically render such an image, it would have to load the map and a tileset, setup the 3d engine, etc. quite a lot of work. I'm not opposed to the idea of the pic being separate, but I like the idea of embedding the image much better, especially since it's reasonable to restrict it to a small size (e.g., 128x128). Even for a true color uncompressed bmp, that still only takes 48k. None the less, the map header does not have to be a static size as it is currently:
struct MapFileHeader {
int32 version;
int32 maxFactions;
int32 width;
int32 height;
int32 altFactor;
int32 waterLevel;
int8 title[128];
int8 author[128];
int8 description[256];
};Of note, I've already changed the "maxPlayers" to "maxFactions". And a bit off-topic, this struct is defined in three different places throughout the code! (very naughty!) I'll eventually be moving all of the code related to map format and I/O into the shared_lib sub-project.
I think restrict the players to 8 in the GUI but allow for 16 in the code (unless it would be better to restrict it in code now then extend it later). It will be hard to display all of the players until I can get them to scroll.
Sorry I didn't respond to this thread sooner. I think 8 players in the UI is plenty fine for now!
Also, I've modified the new game menu a considerable amount in the 0.2 branch to accommodate changes in the networking code. It's no big deal for now, but I'm just about ready to have you jump in and start helping there if you have the time.
