Dancing Hoskuld
Deity
Did you read that the recent earthquakes in the Indian Ocean may be due to the Indian-Australian plate beginning to break up because the Indian side is moving slower that the Australian side.
I'd suggest a probabilistic flooding algorithm.Something like a mud-crack algorithm, where a continent (area) is turned into generic polygon with more or less straight edges with the continent being part of the geometric polygon and includes part of an ocean to one side...
I'd suggest a probabilistic flooding algorithm.
Start from a random unmarked plot (one that is not yet assigned to a plate).
If it is an ocean plot, then consider the plate you are making an ocean plate, otherwise it is a continental plate.
Mark the plot as belonging to a plate.
You keep a list of plots that are next to your current plate. That list also assigns each of that plots a relative chance to be the next to be added to the plate. Keep track of the sum of chances. The chance is higher if it is next to 2 and even higher when it is next to 3 or 4 of your plate plots. Plots that are land plots for a continental plate or ocean plots for an ocean plate have considerably higher chances than the opposite plot type.
Get a random number up to the sum, then go through the list, summing up the chances until the current sum is higher than the random number. Add that plot to the plate. Mark it, remove that plot from the list and adapt your border plot list including the chances of neighboring plots and adding new neighboring plots to the list (adapt the total sum whenever you change a chance or add a neighbor plot).
Stop with a chance that increases from a certain size on.
Then start again from another random unmarked plot. If a plate cannot grow any more and is below a specific size, then assign the plots to a neighboring plate instead.
Map generation can be time consuming IMO, so long as the use of the simulation is optional (i.e. - people can still use old-style 'cheap' generators if that's what they want to do). Personally I'd be happy to leave a map generating while I have dinner or something, since playing the resulting game will usually take a month or more.
Yeah, a Gigantic PW3 can take up to ten mins for me. Hopefully merging some of the calculations into the SDK will speed things up, but still, that's pretty rough.
With the full simulation being worked on I was more thinking for 30-60 minutes. Personally I think that's fine - you have a choice as to whether to use such a generator, and for me map generation is a once per couple of months thing.
With the full simulation being worked on I was more thinking for 30-60 minutes. Personally I think that's fine - you have a choice as to whether to use such a generator, and for me map generation is a once per couple of months thing.
With the full simulation being worked on I was more thinking for 30-60 minutes. Personally I think that's fine - you have a choice as to whether to use such a generator, and for me map generation is a once per couple of months thing.
That'd be cool except that if you end up with an untenable starting location (or your partner does...) and have to start with a map rebuild... eugh...
I have no problem waiting a long time for the world to generate, but would there be a way to just reshuffle the starting positions ON that world without regenerating the map all over again?
Really? Wouldn't it go faster than a Python mapscript, which has to be run through the interpreter, because it is already compiled fully in the DLL?
Depends on what you are doing but in the case of serious number crunching like such a map generator is C++ is considerably faster (if done well of course).Not as much as you would think. A Python program doing the same big thing as a compiled C program does not have to be much slower even when both languages are programed well.
Depends on what you are doing but in the case of serious number crunching like such a map generator is C++ is considerably faster (if done well of course).
Yes, unlike the Python variant used by Civ4 which seems to use a global interpreter lock (I tried some multi threading for the PerfectMongoose map script a year ago).And parts of it could theoretically multi-threaded.
Small remark: Boost only provides the link between Python and C++, not the Python interpreter itself, which I think is CPython. As it compiles into bytecode, it is not quite as slow as direct sourcecode interpreting would be.Of course, for serious numerical simulation task (like this if it were to be done accurately [which isn't necessary for Civ]) GPGPU would massively trump any other method (probably by a couple orders of magnitude).
Realistically, for this sort of thing, given the constraints of the Civ environment (and the boost Python interpreter - note 'interpreter', NOT JIT) my best guess is that our best C++ effort would be around 20-50 times faster than our best Python effort.
@primem0ver: How will the GeoRealism generator link into the existing map generation? Will it have adjustable settings like a normal mapscript, or will it be hardcoded as an alternative to the current mapscripts? That has been the question that has been confusing me slightly with regards to this project.
Wow... truly amazing work. You mentioned in there that the system wouldn't keep running during the game? I thought you might be able to actually allow it to continue so that the map CAN make some drastic changes now and then (even though uncommon).