I actually put a decent amount of thought into this a few months ago. Honestly, generating the map wouldn't be hard at all. What would be hard is linking the territories up so that this site could adjudicate it. If you just wanted a map and use a human GM, I think it would be fairly trivial to code.

Here's the thread where fk, draug, myself, and some others discussed it. Seems as though it lost momentum.
http://webdiplomacy.net/forum.php?threadID=724055#724084

Right abge, I would want it to interface with the current system, not have a human GM... I'm a pretty mediocre coder though it would be a fun exercise.

I'm a very advanced coder, which the generation wouldn't be tough, rendering the image of the map WOULD be tough (or would be not fun to look at, like a checkerboard).

And there would be SERIOUS balance issues, unless you had a killer and overly complex algorithm for the generation.

(see the old post... it has my thoughts in there)

Heh, rereading that old thread, its quite a list of names from the mod/dev team.

If only it wasn't for convoy's, it would be very easy to get such a map in the webdip format, but they make it a lot more difficult to do. If you're happy without them, then its very simple to implement, simply by editing the interface layer to do the legal move tests, then having the adjudicator work on a complete graph of possible moves rather than restricted

Why couldn't you get mini-maps that were known to be balanced. Then put them together randomly. both location and orientation. It seems to me the key would be where the supply centers started. Maybe have exclusions at the extremes, for example every country gets one or two units at the border and two or one units in the interior. Just a thought...

Interesting concept.
So, instead of a truely random map, you're suggesting more a jigsaw setup.
However, this again leads to the issue of how do convoys work, unless you ensure that no two pieces end up with sea at their borders.

Perhaps we should start with a land-only map. We'd just include more permaDMZs (Switzerlands).

Huh?

This confuses me. I've read (parts of) the original thread, and I can't figure out what the problem is. Note that I'm not a programmer, but a mathematician/physicist, so maybe I underestimate the difficulty.

To me a map consists of an undirected (flat!) graph, in which each node is sea or land. If you've got that, a convoy is simple to arrange (isn't it?).

It's easy to write an algorithm which generates such an undirected graph, with supply centers and everything. Even I could manage that. Making sure it's flat is more difficult, but there are bound to be mathematical theorems which help. Creating a "world map" which looks kinda nice (and coming up with interesting province names?), is that the problem?

On a side note, can someone explain how the convoy algorithm works?

A land only map wouldn't be too hard to do.
simply input a relatively full map into the database, then randomly choose selections of borders that cannot be used for a certain game. This would then be implemented when generating the javascript map cache, so the user wouldn't be bothered by it, and obviously in the order-confirmation code to ensure noone has modified the ajax data.

sorry, I should be more clear what I'm thinking of bas.
Yes it would be quite easy to make a map that could be used for diplomacy and play a game on it.
However, the issues would be between either how you draw it, or how you allow more than one game to occur concurrently with different maps.

It would be simple to make a variant which periodically changed the edges for everyone playing it, but a random map should surely stay the same for the length of your game. As such, there ends up being another abstraction layer between the database version of the game (which would have to be general enough to work for all possible games that may occur) and the users version (which would be very different each time).

In simplistic terms, the convoy algorithm works out from wherever you are, spreading across as many sea territories as it can, then looks at all the land bordering them. Easiest way to learn about it is probably just to look at it in the code though!

So in principle it's not so difficult (ignoring the 'drawing the map' for now), but the current code isn't geared to do this? As in, we would need to modify the core code just to make this possible?

Yes, I'll have a look at the actual code again. I did that once before, but I didn't understand it. I just happen to be completely unfamiliar with php code (or any java script for that matter).

Just to direct your hunt, the convoy algorithm is run client-side in javascript rather than server-side as it once was.

No, it wouldn't be too hard to do, but working out how to allow multiple games to have different maps was my stumbling point. The method I outlined above would work fine for land-only maps, but would not expand to sea maps, because the system wouldn't know if a territory was sea or coast, which matters for convoy-checking. I would also need to check the convoy code to confirm this, since having started thinking about this again I've become a lot less confident that this would be a problem, and am starting to wonder if it would actually be fine with just one more change - ie to the server-side convoy code (if this exists)

@figle

I don't understand why different maps is a problem for multiple games. When some starts a random map, it would just be temporarily added as a variant and then disappear when the game finishes. Obviously, this requires code changes, but so would anything else, so I don't see why that's a stumbling block.

@abge, that might work, but it also gives the map powers to create directories, and do all kinds of htings which i don't think the variant codes currently supports (or should support - for security reasons) - now i might be completely wrong on this because i haven't actually looked at the code...

nice to see that there is some interest here. Abge you should rock this out.

Just to throw some more complexity in there: what about a map that randomly (and perhaps quite chaotically) changes *during* a game?

I guess there are some variants (proposed, but I doubt ever widely implemented or thoroughly play tested) that involve a map that changes over the years. One of these variants (Wall of Ice) involve these changes evolving semi-randomly, but all of these variants are quite rigid in how the board gradually and predictably evolves.

http://www.maproom.co.uk/maps/wallofice/wallofice.html
http://www.maproom.co.uk/maps/deluge/deluge.html
http://www.maproom.co.uk/maps/sahara/sahara.html

But what about a map where such changes are more chaotic than that? Like land bridges the might or might not show up each spring. Flood plains that may or may not flood, destroying your army. Dimensional vortexes that may or may not just throw everything all around.

Sounds fine.... for a mod. I don't like making decisions with imperfect knowledge though... imo any element of randomness after the initial layout increases the chance of less skilled players to get a win they don't deserve (yes, I know I might be one :P, but the point stands)

I think the complexity of multiple maps of different types is how to store the information. Figle's probably thinking of the db (mySql?), but will probably have to switch to a different style of db, like nosql/big data dbs.

@bas: Yes, it is a 'simple' graph theory problem/algorithm (did I just use 'simple' and 'graph theory' in the same sentence???). The biggest problem I forsee is drawing the map. If you do just a standard node-line graph, it'd be much simpler, but not really look like what diplomacy players are 'used to'. Maybe we could go the 'jigsaw' approach to map drawing? I dunno...

To focus on the webDip variant interface aspect: The current system is very flexible, but there are some changes variants make which all code should respond to.
e.g. If your variant uses another map it makes no sense to have to rewrite the generic code which finds all available supply centers, because all maps have supply centers.

This is done by having a mapID for all territories and borders; the variant specifies the mapID, and the generic code can find all available supply centers but just limit it to the appropriate mapID, and the correct SCs are found without the variant needing to modify that code.

If a map's territories and borders have no fixed mapID associated with it there'll either be a /lot/ of generic code to override, or there'll need to be some sort of workaround where each newly generated map creates its own mapID, along with territories and borders, for each game, and the mapID is taken from the game instead of the variant.
The latter would be easier, but unless you've got a lot of variant dev experience I doubt you'd get far.

Long story short: Theoretically yes, but practically it'd be a tough project requiring some good webDip internals know-how

I was about to ask why you need territory AND borders, but I forgot about the stps, frances, and bulgarias of the game (which is different than the kiels, denmarks, and constantinoples....
Kestas, the idea would be to randomly generate the mapIDs. The map would be generated at game start and become static. So, in theory, the 'randomizeMapper' would generate all the mapIDs with their associated land/border/etc... I still think the hardest part is generating the actual 'picture' of a map. The rest is math.

"If a map's territories and borders have no fixed mapID associated with it there'll either be a /lot/ of generic code to override, or there'll need to be some sort of workaround where each newly generated map creates its own mapID, along with territories and borders, for each game, and the mapID is taken from the game instead of the variant.
The latter would be easier, but unless you've got a lot of variant dev experience I doubt you'd get far."

ok, i think i understand, so can you set aside mapIDs) for each game, and then do the generation based on a newly create graph (i know it's different for each variant, but they also include a install step of some kind)

This way you can store map per game, and everything is hunky dorey. Just need a place to sotre the mapId, small amount of code to override.... (though for keeping the history of old 'random' maps played you'll need to keep each old map available...)

This seems like a better work-around.

if we can ignore northcoast/southcoast countries (stp, fra, bul, etc...) it would make it a TON simpler. At least in the first iteration...