Oh wow, 10 million km in width and height seems quite large.
Just think of an unlimited map. The exact size does not matter.
The map has a lot water, I'm guessing this can be changed using the seed?
Currently the seed does not influence the total amount of water. But it could be the case for future versions. Currently the seed only influences terrain shapes, so that no map looks like the other.
I also love the scroll out mini map idea.
The terrain view and the mini map have different purposes. The terrain view shows your objects, vehicles etc. The mini map shows statistical information. Sometimes you want to see terrain view and mini map at the same time. I will stick to the current seperation of terrain view and mini map. Videos say more than thousand words, so here we go:http://www.youtube.com/watch?v=QQ9Ac-c0XDE&noredirect=1
One last thing: why not going for real runway lengths when maps are this huge?
You already explained why (see above). The maximum zoom must be able to show most of the runway. And there are several other issues. For example the terrain generator must generate very long flat stripes, so that you can find a place for your extreme long runway.
I think you won't be happy to get a map larger than 10k x 10k. Raw integer in Java is 4bytes. So if for example you store grid coordinate in two integer (x,y) you will have to support 100 000 000 * 2 integers what gives about 750 MB. And that's only a tip of the iceberg, because, I guess you store some height data also so in this example taking one float per grid would be additional 340 MB. So this gives 1GB of data. But still this is only the top more has to be there like objects. And all this has to be stored in some kind of collections. My guess is so big map would easily eat about 4GB of data. And still there's memory overhead Java adds for objects which is 8 bytes per object. Also there are CPU performance related reasons - the more objects you have the more updates per frame have to be done. I think a 2048 x 2048 will be the way to go in this case. Of course - if you have an i7 CPU with 6 cores and the game will be heavily parraller in execution , and 16 GB of RAM - things may look better.
The terrain is calculated based on a random generator seed. The terrain heights are not stored. As soon as you scroll around the map, the currently visible terrain heights are calculated using the
current seed and displayed. (The only heights being stored are the ones edited by the player) Have a look at the bottom right corner of the video ("memory usage" in the monitor window) You see that there are less than 100 MB used.)
There is also a thing I've figured out that the off-screen elements must not be updated every frame, because player can't see them, so there could be a little cheat that vehicles outside the screen are updated every 1/4 of a second. This is the only way to optimize such a extreme environment.
Yeah. This is quite the way P1SIM is calculating currently invisible mobile objects.