Category Archives: All

About Ancient Alien Civilization

As you may have already noticed among the planet examples a planet appeared in which the form of continents resemble letters. This is the result of application of the algorithm which I called the Ancient Alien Civilization method, as it is similar to the result of terraforming the planet by a developed ancient civilization. Of course, the form of the continents can be any with taking into account the minimum step of the planet basic heights grid.

mandelbrot planetThe method is based on the good old noise functions, but supplemented by what can be called the imposition of a stencil. When we calculate the value of a noise function at a point, we also check the value of a specific function at this point (the stencil), which can have a value of either 0 or 1. If it has value 1 we store the value of the noise function, and if it is 0 we assign to the result a value of 0.

Thus, the stencil function defines the shape of the continents. In the example of Mandelbrot planet it is zero everywhere except the location of the letters. Such kind of map details have a relatively large scale, in the size of the continents. To get smaller details of the map (for example, craters) we must apply them already on local grid of rombs. But this is still in development.

The last picture is the unfolded view of the Mandelbrot planet continents.

mandelbrot planet continents

The seditious ideas on how to use vector maps as in-game maps

Lets consider how you can use vector maps in games creating and what difficulties can be in this.

Current state of affairs

The game map of the world is an essential element of many video games of various genres. But even in the most advanced in the technical plan and popular games we see rather low detailed in-game maps. The map is especially important in games with a huge world, where the player need constantly determine his position in the world on the map. In many massive multiplayer online games the game map is a plain image of relief viewed from above and very uncomfortable. There is a natural and long overdue transition from image-maps to high detail vector maps.

On the other hand, if maps must depicture a large territory (even an entire planet) and/or has a high level of details, then the procedural generation of maps has no alternatives. Always keep in mind, that the generated map can always be supplemented with new details or it can be edited manually.

For many standealone and online games, there are map generators. But such generators are designed to produce small-detailed tile maps or each generated world is monotonous and does not correspond to the spherical geometry of a planet. While in massive multiplayer games, because of the difficulty of manually drawing large and detailed maps, game-devs prefer to use the same image of the world for unrelated gaming servers. And the emergence of another world is appeared as a very big event. With procedural generation new large and detailed worlds will become an ordinary event. Furthermore, it will be possible to make the games with a mechanism for generating or loading standardized in-game maps, and the action of different games can occur in the same world. As a universal map format, I propose to use the generally accepted data formats of modern GISs.

Relief (terrain)

The terrain in many games is an integral part of them and the map of a game world is in interrelation with the terrain. During procedural generation of maps, one can build the map on the existing relief (as it is done in this project), consequently the relief and the map will be naturally related.

Output relief data of the project is represented by SRTM hgt data. SRTM data format represents a heightmap, while in the most games the relief is some polygonal mesh. Therefore, the first difficulty is the translation of a heightmap into a polygonal mesh. The most likely solution is to use a heightmap as a base mesh, which can be supplemented with details during the transition to a polygonal mesh. In this case, if details added are smaller than the size of small details of the original relief, then no map adjustment is required.

The presentation of data in the SRTM has a major drawback; it consists in the fact that the data density is changing with the latitude. But we have the entire accumulated arsenal of available tools for SRTM data format. The project internal binary representation of the data that depends on the division of the planet’s surface into rhombuses is nowhere else accepted, so currently I prefer SRTM as the output format.

Vector map

Vector maps are not only provide an opportunity to highlight every detail of the world, but also the ability to change the world itself. And thus, the emergence of games in which the world itself is not only a background, but an active element of the game is possible.

I will give several possible examples which seem to me quite feasible today.

  • Apocalyptic games of various genres. The relief and map change with the development of events: craters and volcanoes appear, continents are flooded or rise.
  • Geographical discoveriesGeographical features are multipoligons and have strictly defined coordinates.
  • Multiplayer strategies. Players themselves arbitrarily set the boundaries of their states, and do not transfer pieces of territory pre-set by a game designer manually. Trade routes can go along rivers or arbitrary roads build by players.
  • Multiplayer role-playing games. Players can build houses, fortresses, dig channels and generally change the face of the world. Player’s home houses or guild’s HQs can be finally placed on the map.
  • Many other types of games with a huge world. One or all of this: the great extent and the variety of the game world, the possibility of terraforming and changing the world itself, really spherical world.

Map presentations

Since the maps are obtained with the help of GIS and are made for GISes, various manipulations with the map are permissible, as well as various representations of maps. What you can see on this site in the section of free maps is by no means the final appearance of maps. You can use different color representations and map types of your choice.

The color style of the free maps on this site was made in the TileMill tool, with the following generation of map tiles with Mapnik.

If you were interested in maps creation, then probably you are familiar with the hillshading type of earth maps. Such a representation of maps can be made with the maps obtained with the project, but in my opinion, satisfactory hillshading maps will be received only when higher resolution maps will be enabled in the project.

Also, by the means of gdal library, you can draw a contour height map (as in a topographic maps). But applying them to the SRTM data of an entire planet can require a very long run time. In my plans to make the height contours in the project itself. Obtained contour data will be included in the standard supply of the planet’s data.

When using the Web Merkator projection area near the poles are strongly stretched horizontally. But it is always possible to choose a different projection, in which the selected territory will have minimal distortion. As an option, it is possible to divide the world into pieces with less distortion (with a suitable projection) and display the map parts instead of the full planet map.


The Map Generator

I think it’s time to explain the map generator design. This may shed light on the reasons for taken decisions and can explain the appearance of obtained results. Finally, I hope that the criticism of the approach will help to identify ways to improve the project.

First, the project is almost entirely written in Haskell. At the moment there are about 30,000 lines of Haskell code. The choice of language was due to the fact that it allows you to produce a productive compiled code, and the functional approach ensures a good structuring of this rather complex project.

(Earlier I had dealt with some hypostases of the functional programming, and therefore it was not so difficult for me to master the Haskell at a sufficient level.)

The whole process of planet map generating can be divided into two main stages: generating of planetary relief, and then, obtaining data and drawing the map over the existing terrain. Now we list these stages and their main divisions.

  1. Generation of the initial base relief grid by various methods (fractional brownian motion, generalization of the midpoint displacement method, and functional approach). The resulting grid is then further subjected to the further transformations.
  2. The values of the grid are taken modulo and scaled. Then the sea level value is determined from the given ocean/all planet surface ratio (usually it is around 0.7).
  3. The positions of land mass areas are determined.
  4. In the land areas there are points of local minima (pits) and a significant number of them are eliminated by raising the values of the grid to the level of surrounding points. The remaining pits will serve as a places for possible lakes.
  5. Here, we make the distribution of the height values of the land relief similar to what is observed on the Earth (see Mathematical modelling of mountain height distribution on the Earth’s surface).
  6. We build river-lines relying on the base grid height values, so that each next point of the river-line is not higher than the previous one. As a result, the set of tree like structures of the river-lines is obtained, in which a river-line is the bunch of separate pieces belonging to different rhombuses.
  7. Further, using a special procedure separately in each rhombus we build a relief based on the nearest values of the heights on the river-lines.
  8. At this stage, the values of the heights of the base grid may not coincide with the new values at these points. Therefore we correct the base grid.
  9. Here, the generation of maps begins. First, we create DEM files (Digital Elevation Model Data). Then we generate Geotiff raster tiles for one or more resolutions.
  10. We turn the river-lines into full rivers by giving them a width and smoothing their banks.
  11. The shores of the lakes are determined.
  12. We determine the outlines of land areas and inland waters (these are lakes with a height of the surface at the ocean level; named as lowlakes).
  13. The resulting data is recorded to the spatial database store (PostGIS).
  14. Then we validate all obtained map features and make their correction (with PostGIS tools) if necessary.
  15. Currently we use mapnik with the defined style to generate PNG tiles.

Finally, for visual display we can use one of the web libraries (LeafLet, OpenLayers, etc.)

Next is a few comments on the mentioned stages.

  • At the stage when the base grid of heights is build, the rhombuses is formed on the surface of the cones. In each rhombus we introduce a local grid as mentioned in one of the past posts. And then, ignoring the distortions, we consider a rhombus as a square, and the local grid becomes very similar to the usual grid in the Cartesian coordinate system (although not completely similar; we must take into account the valid proximity of the points to each other). Further we are dealing only with this simplified system of base and local grids.
  • Currentlly,  we avoid situations where planet poles are contaned in land masses. Alse, we avoid land masses laying on the time line (180 degree meridian). This is due to some complexities for the relief generation process, but even more so due to use of map display in Web Mercator projection and possibility of obtaining non-valid map features which are difficult to divide into parts (in left and right hemispheres).
  • If you still intend to locate the continents at the poles, I recommend the transformation of the map data (rotation of the sphere around an arbitrary axis) with the subsequent change of the map projection.
  • In river system constructing we place only one river source in each romb. In order to get very different types of relief on a planet, it is planned to gradually change the number of sources along with the change in numerical parameters of the relief (local fractal dimention and scale).
  • Also in the map data there is no information now to which lake or river this river flows into. While constructing river-lines, this information is available, but when we put a lake on a map, some rivers become an inflow of this lake, instead of a tributary of another river. Valid information should be obtained at the PostGIS level. Which is planned to be done.
  • The resulting map vector data is a ESRI shapefiles which is the generalization of the dBase IV format.