Constant veloren_common::terrain::map::MAX_WORLD_BLOCKS_LG

pub const MAX_WORLD_BLOCKS_LG: Vec2<u32>;

Base two logarithm of the maximum size of the precomputed world, in meters, along the x (E/W) and y (N/S) dimensions.

NOTE: Each dimension is guaranteed to be a power of 2, so the logarithm is exact. This is so that it is possible (at least in theory) for compiler or runtime optimizations exploiting this are possible. For example, division by the chunk size can turn into a bit shift.

NOTE: As an invariant, this value is at least TERRAIN_CHUNK_BLOCKS_LG.

NOTE: As an invariant, (1 << [MAX_WORLD_BLOCKS_LG]) fits in an i32.

TODO: Add static assertions for the above invariants.

Currently, we define the maximum to be 19 (corresponding to 2^19 m) for both directions. This value was derived by backwards reasoning from the following conservative estimate of the maximum landmass area (using an approximation of 1024 blocks / km instead of 1000 blocks / km, which will result in an estimate that is strictly lower than the real landmass):

Max area (km²) ≌ (2^19 blocks * 1 km / 1024 blocks)^2 = 2^((19 - 10) * 2) km² = 2^18 km² = 262,144 km²

which is roughly the same area as the entire United Kingdom, and twice the horizontal extent of Dwarf Fortress’s largest map. Besides the comparison to other games without infinite or near-infinite maps (like Dwarf Fortress), there are other reasons to choose this as a good maximum size:

• It is large enough to include geological features of fairly realistic scale. It may be hard to do justice to truly enormous features like the Amazon River, and natural temperature variation not related to altitude would probably not produce climate extremes on an Earth-like planet, but it can comfortably fit enormous river basins, Everest-scale mountains, large islands and inland lakes, vast forests and deserts, and so on.

• It is large enough that making it from one side of the map to another will take a very long time. We show this with two examples. In each example, travel is either purely horizontal or purely vertical (to minimize distance traveled) across the whole map, and we assume there are no obstacles or slopes.

  In example 1, a human is walking at the (real-time) speed of the fastest marathon runners (around 6 blocks / real-time s). We assume the human can maintain this pace indefinitely without stopping. Then crossing the map will take about:

  2^19 blocks * 1 real-time s / 6 blocks * 1 real-time min / 60 real-time s

• 1 real-time hr / 60 real-time min * 1 real-time days / 24 hr = 2^19 / 6 / 60 / 60 / 24 real-time days ≌ 1 real-time day.

  That’s right–it will take a full day of real time to cross the map at an apparent speed of 6 m / s. Moreover, since in-game time passes at a rate of 1 in-game min / 1 in-game s, this would also take 60 days of in-game time.

  Still though, this is the rate of an ordinary human. And besides that, if we instead had a marathon runner traveling at 6 m / in-game s, it would take just 1 day of in-game time for the runner to cross the map, or a mere 0.4 hr of real time. To show that this rate of travel is unrealistic (and perhaps make an eventual argument for a slower real-time to in-game time conversion rate), our second example will consist of a high-speed train running at 300 km / real-time h (the fastest real-world high speed train averages under 270 k m / h, with 300 km / h as the designed top speed). For a train traveling at this apparent speed (in real time), crossing the map would take:

  2^19 blocks * 1 km / 1000 blocks * 1 real-time hr / 300 km = 2^19 / 1000 / 300 real-time hr ≌ 1.75 real-time hr

  = 2^19 / 1000 / 300 real-time hr * 60 in-game hr / real-time hr

  • 1 in-game days / 24 in-game hr = 2^19 / 1000 / 300 * 60 / 24 in-game days ≌ 4.37 in-game days

  In other words, something faster in real-time than any existing high-speed train would be over 4 times slower (in real-time) than our hypothetical top marathon runner running at 6 m / s in in-game speed. This suggests that the gap between in-game time and real-time is probably much too large for most purposes; however, what it definitely shows is that even extremely fast in-game transport across the world will not trivialize its size.

  It follows that cities or towns of realistic scale, player housing, fields, and so on, will all fit comfortably on a map of this size, while at the same time still being reachable by non-warping, in-game mechanisms (such as high-speed transit). It also provides plenty of room for mounts of varying speeds, which can help ensure that players don’t feel cramped or deliberately slowed down by their own speed.

• It is small enough that it is (barely) plausible that we could still generate maps for a world of this size using detailed and realistic erosion algorithms. At 1/4 of this map size along each dimension, generation currently takes around 5 hours on a good computer, and one could imagine (since the bottleneck step appears to be roughly O(n)) that with a smart implementation generation times of under a week could be achievable.

• The map extends further than the resolution of human eyesight under Earthlike conditions, even from tall mountains across clear landscapes. According to one calculation, even from Mt. Everest in the absence of cloud cover, you could only see for about 339 km before the Earth’s horizon prevented you from seeing further, and other sources suggest that in practice the limit is closer to 160 km under realistic conditions. This implies that making the map much larger in a realistic way would require incorporating curvature, and also implies that any features that cannot fit on the map would not (under realistic atmospheric conditions) be fully visible from any point on Earth. Therefore, even if we cannot represent features larger than this accurately, nothing should be amiss from a visual perspective, so this should not significantly impact the player experience.