Here’s my ideas of a Planet Editor, based on our discussions on Discord.
By starting from a bunch of configurable parameters, which can be set with a list of presets, the game uses a random seed to generate the planet at an “epoch 0”, that is the time for abiogenesis aka when the game begins. This is the simplest editor, but it’s only good to have a setting for a new game.
The issue here is that such an editor is basically a configuration for a new game, but it’s useless to visualize what’s actually being generated, and how it will be simulated as the eras progress. I’ll start separating the two concepts, referring to them as “Planet Configuration” and the actual “Planet Editor” in the following way:
The Planet Configuration
This allows the player to configure a custom setting for a new game. It includes all the parameters to define climate, geology, size, physics, composition etc… for the starting planet. This planet will be rendered in this configurator as a starting-point. I’ll discuss how this rendering happens in a moment.
The Planet Editor
My idea of an actual editor is different, because just like the Auto-Evo Editor I believe we need a tool to simulate, visualize and gather data from the initial parameters (Planet Configurator) that evolve as the eras progress. This simulation includes global events like glaciations and impacts, and a discrete simulation of a simple model of plate tectonics.
So, just like the Auto-Evo Editor shows how the algorithm functions as the generations progress, the Planet Editor is of good use to create a planet, evolve it, and then even use viable states as a starting point for a new game. This way you can first simulate the planet and then choose an ideal point in time, if viable, to initiate abiogenesis and start the gameplay. I believe that this, if implemented, should be counted as a cheat.
As the planet simulation progresses through the eras, each point in time is shown not only on a timeline, but also on a rendering of the planet.
The planet visualization
Since when I started thinking about a planet editor, I had in mind exactly something like this:
Both a 2D and a 3D visualization are viable, and are not too difficult to implement for the scopes we have been discussing. In fact, I produced a few concepts with a simple python script some months ago that can be easily implemented in our code.
In the image on the left, I used an irrational sampling of a sphere based on the golden ratio, where each angle relative to the vertical axis is \varphi_i=i\pi(3-\sqrt{5}). This produce an uniform mesh for our sphere that approximates both the convex hull of the sphere and the Delaunay triangulation of it.
In the center, you can see the approximate Voronoi tessellation, which is computed as the dual of the approximate Delaunay graph. This tessellates the sphere in micro-plates that are roughly of the same size. Each one of these polygons are useful to visualize heatmaps on the sphere: climate, temperature, physical properties, plates, plus they are fundamental to simulate plate tectonics cheaply.
On the right, I ran a very simple stress calculation with example plates, producing a few continents at a very low resolution in no time. I believe it conveys the concept well, as it shows the usefulness for both the visualization of the data and the simulation for plate tectonics on a sphere.
Rendering a 2D map is as simple as projecting this sphere on a 2D surface, that be Mercator or any other projection. In the following example I used an equirectangular projection.
Is this terrain generation?
Yes and no. This is certainly a starting point for a heightmap to be used for terrain generation, but it’s definitely too simple for true terrain especially because the gameplay takes place on a very small scale. It can be used to render the planets in the editor and in later stages like the space stage, but it must be integrated with other algorithms to have a true terrrain generation.