The World Generator: A Dynamically Generated GIS

I have been working on the world generation system for a while now, and I would like to discuss my findings so far along with a proposed solution:

Defining the Problem:

Thrive will need a world generation system that can support as realistic of a simulation as possible not only for the earlier stages where the focus is more on the biological evolution of organisms, but also the later stages where the evolution of realistic societies will be the main focus. Many of the features that the earlier stages require from the world generator will continue to be useful for the later stages, such as the basic terrain generation and dynamic climate system. However, I posit that the later stages will need to generate much more than just world terrain on demand.

The earlier stages are able to simulate the world at a low level of detail (LOD) without seeming to compromise too much on the quality of the simulation. For example, the microbial stage currently runs its simulation on a small amount of patches representing vast areas of the world, and this seems to be a good fit for it. This allows for the simulation to run on the scale of the entire planet without having to simulate it using thousands of patches, which would require a sacrifice in terms of the amount of detail each patch could be simulated to. It also reduces complexity for the player, as they aren’t overwhelmed by a huge patch map when all they need is a basic overview of the world.

However, for the later stages it will become increasingly important to be able to simulate the world at finer resolutions, all without making the computation time grow exponentially. At the very least, this will have to be done for the terrain generation part of the world generator, as the world’s terrain would be far too large a data set to generate at the highest LOD initially. The higher LOD of the world’s terrain would be generated dynamically, as it is needed. This is a fairly normal thing done in these types of large scale procedurally generated worlds, as it is basically required as the alternative would be to generate gigabytes worth of just terrain data in order to get a barely decent level of detail on a world that is similar to Earth’s size. For example, an available GEBCO global terrain elevation data for just a 450m resolution grid, is about 8GB of data. (
We would need a better resolution data than that in order to have the terrain look very good for at least the multicellular to society stages, as that would be the primary stages that would be closest to the terrain, and require high resolutions to look any good.

This is still pretty typical though, and games have been doing terrain LOD for quite some time. However, I posit that much more than just the world’s terrain will need to be generated at high LOD to allow for the realistic simulation that we want.
Besides just the terrain data, any climate data will also be needed to generate at high LOD in order to have the climate able to correctly interact with the high LOD terrain. If the climate data was to stay at low resolution relative to the terrain, then there could be ugly discontinuities and artifacts visible at the earlier stages when exploring regions with complex, high resolution terrain and low resolution climate data that can not match the terrain’s detail.

Another feature needed is the ability to partition the biome patches at high LOD. At the start of the game, in the microbial stage, the world would only want to generate and simulate at a low LOD in order to allow for the world to be simulated at the global level. Once the game progresses to requiring higher LOD for the world, the biome patches will also need to be adjusted to be consistent with the low LOD versions while adding in the high LOD elements to the patches, making them more complex and detailed. If the biome patches were just to stay at low LOD then the individual patches would remain huge and monotonous due to the huge scale of the world. And if the biome patches did not conform to the higher resolution terrain and climate data, the biome patches would become a worse match to the actual terrain as the LOD increases.

All of this already requires a robust world generator that is able to generate extremely high detail regions that must remain consistent with previous lower levels of detail so that the world’s development remains consistent across the early stages. But, there is even more that the game will have to support in order for the later stages’ society evolution to be done realistically at these large scales.

According to a random google search, there are many more than 10,000 cities in the world right now. There are also many more smaller urban areas, such as towns or villages (Much more than 100,000). There are also about 200 different countries on Earth, and this is after a large amount of consolidation over the centuries. It seems unlikely that all of the disparate communities and civilizations that there should be across a realistic sized world would be able to simulate at a reasonable LOD at a consistent level globally. And it would be completely infeasible to have all of the cities or urban centers simulate at a high LOD due to the sheer amount. These different and numerous urban centers would have to develop naturally over time, from nothing to villages, towns, and sprawling metropolises. This seems to be a very similar situation to the world’s terrain generation, only now it is dealing with data (cities, etc) that would be extremely dynamic over the course of the simulation. This requires a system that can create detailed parts of a society as it is needed, whether it is creating new cities from scratch on demand or just increasing the LOD allocated to a region that was previously only created and simulated at a low LOD. Only the regions close to the player (or are otherwise relevant) will need to be generated and simulated at a high LOD, and the rest of the world could either simulate at a lower LOD or just be generated on demand. There are many more considerations that a dynamically variable LOD for society generation and simulation system would require, but I think this is sufficient for now. I might make a new post about the society simulation as it relates to world generation at some point. The main point is that societies will not be able to be generated and simulated at a consistent LOD across the world without limiting either the scale or depth to be far less than real (Earth’s) scale. This could be solved easily by reducing scale to something like Spore scale worlds, but I doubt I need to explain why that would be problematic for Thrive…


After looking at all of these different requirements that the game would need for detailed simulation of a realistic scale world, I propose that developing a Geographic Information System for Thrive would help solve many of these problems in a neat and logical package. A Geographic Information System (GIS) is a system that can store, manage, analyze, edit, output, and visualize geographic data (source: Wikipedia). This is typically implemented as some kind of spacial database that stores all of the data that is associated with the world. What is relevant for us is that we need a system that will manage all of the data that relates to the world, from terrain data to locations and population numbers of different organisms or societies. This differs from typical GIS though in that our world would have to be generated dynamically, but would otherwise be very similar in requirements to a normal GIS. This is essentially taking the standard dynamically generated world terrain of procedural planet generation methods to its logical conclusion. By merging the dynamic generation of a game’s planet generator with the power of a GIS, it should make the design of the game much easier to deal with by neatly modularizing parts of the game’s codebase. I doubt that the idea of having the features of a dynamically generated GIS in a game is a very unique idea, but clarifying exactly what things the world generator needs to do by calling it a GIS makes the idea of what features it will need to support much clearer.

I will be calling the system Dynamically Generated GIS (DGGIS) for now, but I am not sure if that is the best way to label it.

To learn more about Geographic Information Systems, this is a nice short introduction: 2. Introducing GIS — QGIS Documentation documentation
ArcGIS by Esri is another large GIS used widely, and so there is much information out there on it if you wanted to see how it is used. Also, check out ArcGIS CityEngine (Procedural 3D City Generator | 3D City Design for Urban Environments), which integrates with the ArcGIS system to enable procedural city generation. This is related to what we would want Thrive+DGGIS to be able to do, only focused more for real world applications.

Thrive’s Dynamically Generated GIS (DGGIS):

Now, to define exactly what it is that I am proposing in detail:

DGGIS is essentially a combination of a World Generator with a Geographic Information System (GIS). Its purpose is to support most GIS features, but with the ability to do so on an internal set of data that can be generated on demand. Some aspects of the geographic data will be persistently stored, while others will be generated dynamically as the client (Thrive’s simulation or renderer) needs it. Some of this data can also be stored persistently but at a lower resolution than it was modified on in order to save on space when full resolution persistence is not needed.

The system will mainly be composed of various data planes storing different types of information. These data planes will be split into chunks representing different geographic areas of the world, thus subdividing it into a manageable amount of data. These chunks will be organized in a hierarchy such that low resolution (low LOD) chunks can be used to represent large areas for faster simulation purposes or to represent large areas when viewing and manipulating the world at large scales.

One potential implementation is to use a quadtree or similar data structure to split the data planes into ¼ size chunks per lod level. This would result in a simple to implement version of the GIS, and could efficiently support queries to specific regions. This method is what I am already using for the basic prototype world generator, and is what many other simple world generators use. More advanced methods can be researched in the future. This is only one part of the GIS system though, as we will discuss later in the partitioning section.

A major distinction between different forms of data that is stored in a GIS is vector vs raster data. Vector data is data that is represented as points, lines, or polygons while raster data is stored as a grid aligned set of data points. This is basically the same as vector vs raster formatted images (like SVG vs PNG). It is likely that DGGIS will need to be a hybrid between a vector and raster database. The choice between the two will be based on the specific case of how each data plane would be best represented.
The functional differences are that the vector data might need to be rasterized before being used in some cases, for example the terrain data would need to be rasterized before being sent to the GPU as the terrain mesh if it was stored in a vector format. (Don’t confuse GPU rasterization, which is done on the final terrain mesh given to the GPU to render, with the GIS rasterization which converts the vector formatted heightmap data into a discrete mesh of vertexes)

If you are wondering exactly what the raster would be, in typical GIS a raster would be a square(ish) grid. This is not a requirement though, it is completely possible to have the raster be a hex grid or triangle grid. Google’s S2 Geometry library uses a ‘square’ grid ( while Uber’s H3 uses a ‘hex’ grid (H3: Uber’s Hexagonal Hierarchical Spatial Index | Uber Blog), and others are definitely possible. Note that these are actually hierarchical spacial indexes, and the actual data in those specific applications can be stored in a different raster format or just use vector format, but that isn’t too important here. This distinction shouldn’t be too important for us because we will be generating all of the data ourselves, so we can align the data regularly and consistently.
If you have any comments about the vector vs raster format, you might want to look at the post on World Tiling/Grid (World Tiling/Grid) first. I think that any discussion about using a grid (whether square, hexagonal, free form, or other) should be had there, in order to make the discussions more organized. If the discussion is specifically about it in relation to the GIS design, and not about the game design aspect of it, then it should be done here.

One important aspect of the system would be a partitioning system. This would be the system that generates the biome patches by looking at the world’s terrain and climate data, and partitioning it into distinct patches. It would also manage other regions that need to be partitioned such as civilization borders. The partitioner would have to manage all of the spatial connections between adjacent patches and communicate this to the client so that Thrive can run simulations using this information. These partitions would generally form graphs where the nodes represent each region (such as a biome patch, or a society’s borders) along with the ability to get properties of that region from queries to it (such as population numbers, or region boundaries).
The partitioning system would need to be able to resize patches when different conditions change. For example, if the global temperature rises, a desert biome patch might expand. Or, if two societies are at war with each other, one might capture a city causing the society boundaries to be repartitioned so that the city is within the correct society’s borders, and the other society’s border would shrink accordingly.

For the microbial stage, the partitioning system is one of the most important aspects of the entire system. The microbial stage can basically just have the DGGIS system generate the world at a low LOD, generate the corresponding biome patches (partition the world), and then give the biome patches to the game. The system will also have to support whatever simple queries to those regions, such as whenever the simulation is wanting to know what organisms currently are associated with a patch. It might also want to know simple things like light level of a patch, or oxygen level. This should not be overly complicated to design, and if done right could make expansion of the system into the later stages easier to do.

I would also propose that the entire world generation system (DGGIS) be created as a separate project from Thrive. It would still be developed specifically for Thrive, it would just be done in a nicely separated manner. Thrive could then define an interface along with a specification and list of features so that the system could be designed in a clean and modular way. By designing the project like this there would be numerous benefits. A big one is that it could increase confidence in the system being able to be eventually realized. By having the specification separated from the implementation, if one implementation of the project does not turn out or any developers working on it disappear, the system should have been documented and defined well enough so that someone else could pick it up. Or, completely separate versions of the GIS could be swapped out later if the interface hasn’t changed which could be fantastic for Thrive’s modability. Or it could enable more complex configurations or sets of different world generators for use in Thrive.
DGGIS could thus be developed in parallel with Thrive initially. This would allow time for the interface design to stabilize to avoid annoying refactors in the main Thrive codebase that would use it, or getting stuck with badly designed interfaces. It would also allow for quicker iteration of the system and allow for more experimentation. Simple demos or tests could be created that use the DGGIS system to test out different features without having to deal with the large Thrive codebase. The main downside with this method is that it would likely take longer for the system to get to the point where it seems stabilized/developed enough to be integrated into the main project. This might be able to be mitigated somewhat by designing a simple/cut down version to use just for the first couple of stages in order to provide a better transition to the full version of DGGIS. This all depends on when the world generation system is needed, and what the pace of development of DGGIS would end up being.

Designing DGGIS as a cleanly separable project would also open up the possibility of having the world generation system able to be used in more projects and games than just Thrive. This is similar to the Story Engine discussed here earlier: (Story Engine). Having more parts of Thrive that are available to be used in other projects could attract more developers to contribute, or it could just make it easier overall to get involved with developing Thrive if its components are well-defined, with smaller codebases to be involved with and have to understand. I personally like this ability to use in other projects because I would like to be able to make some nice demos that could show off what the world generation system is capable of without having to heavily modify the Thrive code to do so, even if the features would be intended for use in Thrive later.


Because of the sheer scale of Thrive’s realistic simulation and the requirements of generating detail at high resolutions, Thrive will need a system that can manage world scale amounts of data in a coherent and intelligent system. Creating a Dynamically Generated Geographic Information System (DGGIS) is my proposed solution to this, which will abstract all of the complexity of managing world data into a single system, and relates well to how real world geographic data is actually managed: in geographic information systems like ArcGIS or QGIS.

Now, if you have read all of this and think that this system is far too complex or will likely never be done: don’t worry! Just like Thrive’s organisms and societies, DGGIS can start out simple and evolve over time, gaining more advanced features as it develops. At its core it isn’t really doing anything very novel at all, and my very basic prototype world generator that I have been working on could already be called an extremely primitive GIS. The main point of this thread is to discuss whether this overall idea could work, and exactly how this should be implemented if so. How should the interface be structured? What are all of the features you think the world generator/DGGIS should support? And of course, is this the right system/abstraction to use for Thrive? If this idea can be refined into a specific set of specifications and goals, then this should make it far easier to design both the world generation system on its own as well as Thrive as a whole.

Also, if something doesn’t make sense about my explanation, please tell me. I had a far longer document that I had to cut down and splice into this because it was getting too long and perhaps off track, so there is a change that some part of the context could be missing. I split off the entire discussion about grid systems as well, because I don’t want that to clutter up this thread as I foresee it could.


Quick question: by “later stages” are we talking about aware and awakening, or society and industrial?

I am referring to the ‘later stages’ as the ones that are focused on the development of societies and civilizations as opposed to the development of biological organisms. This would primarily be the society, industrial, and space stages.

Ok, I just wanted to confirm. I recall from months ago that there was talk about making society and industrial stages hex-based, which I assume would render this level of detail unnessicary in those stages, lightening the load of what this algorithm needs to do. I’m not very up-to-date on that conversation, but I would advise checking if you haven’t already. That said, maybe it would be easier to over-prepare, since development of those stages is a long way off.

1 Like

I did see this, however part of the problem with that idea is that real scale worlds would need a huge high resolution grid in order to actually make the size of the individual tiles be usable in a realistic way. And even still, it would require some extremely large scale changes between the stages that would switch to this global tiling for the society stages, which I think is far too large a scale change to work well. It would make continuity between realistically sized small societies to larger scale civilizations not work very well, and is part of what this system is trying to solve. It would also require huge amounts of unnecessary detail and computation power to simulate these huge regions without having a comprehensive LOD system. This is especially challenging for the space stage, where you will be able to visit and interact with lots of new worlds that all must be generated on the fly, and having a 5 minute loading screen for each planet you visit in the space stage because the entire planet is generated at a high level of detail would be terrible. I think most of this problem of scale as it relates to the game’s vision can be resolved by looking at the real world for a bit. I have been using Google Earth recently to get a sense of scale for what the world will have to do to be realistic in scale.

Here is a quick zoom I made into New York for example. (New york is rendered pretty well in google earth) It shows how small even a large city is on Earth, so you would need tiles at least as small as that for the scale to be correct for these cities. And the numerous towns and villages would be far smaller.

New York Zoom

1 Like

Then it sounds like we have two topics in this post:

  • The algorithm for generating this terrain, which will be needed regardless.
  • The case for using this algorithm in later stages.

I guess I am the one who brought up the second one really, but in the interest of focus I’m going to suggest we table that for now and focus on application in macroscopic through awakening stages. We’ll have plenty of time to figure that part out when we get there, and I assume (having not read all of your post yet) that not having to worry about maps at that scale yet makes the challenge a little simpler.

1 Like

While that is definitely a possibility, and seems to have been the current consensus for how the world generator would be developed, the reason that I am proposing designing the system like this is because I think that it would not require much more effort (even in the short term) to actually create the system this way as the more advanced features could be added in as needed. It would avoid the need for a huge redesign of the project later if the world generator ends up simply incompatible with the design of the later stages.

I don’t know much about this topic, but it’s great that you documented it to this level on the development forums. I will second what @Thim was saying: it is good to be foreword thinking, but don’t try to worry yourself sick about the later stages in Thrive, which we realistically wouldn’t even begin conceptualizing in considerable detail for at least a decade. Though I see that you emphasized the iterative approach we can take to such a system in the OP.

I’ll also document a few other topics which are possibly relevant. Apologies if you already read through this material yourself; it would nonetheless make information more accessible in the distant future!

The whole thread has a lot of content, but this post from @Nunz in particular is pretty relevant to our approach currently:

@Buckly wrote up on how we were planning to deal with patch designation in the multicellular and aware stages as well, which references Nunz’s post above:

1 Like

I agreed with you entirely up to this point in your post. I’m going to still claim that we don’t need to do that. We just simulate only the lowest LOD, the grandest scale (lowest and highest are a bit inaccurate here so I’ll use “grand” as a term related to grand strategy where you manage large areas). And the higher LODs are just generating good enough looking data based on the simulation to work. So I still will claim that the world generation is not really that different to this, and doesn’t really need any extra consideration other than the fact that we need a way to go from a general representation (here’s a city with x population) and generate actual building data based on a seed in a relatively stable manner. We never should have to think about simulating society at different LOD levels at once, that’s just insanity.

Having it be a separate project that needs constant changes in both Thrive and the separate project, does not sound very good. But I’ll allow it if the end result is good enough.

I think overly specifying the system is way too complicated ahead of time, as you said working on this piecemeal is the only way to go. So I don’t really see a benefit to splitting this out.

My idea for the world generation was just to write the code for generating various data at different LOD levels, that would then interact with a simple caching system that would store most important info that is heavy to generate to disk.

I’m working on prototypes and I’m not exactly finding that good of a place to switch to hexes… a continuous map would fit better with the rest of the game.

1 Like

I would agree that we won’t need to actually start designing the simulation (either auto-evo or the society simulation) to be LOD aware anytime soon. It shouldn’t affect the microbial stage either way anyhow as no different LOD would even be generated during that stage as the scale remains constant. It would only become a potential problem in the later stages when scale changes do occur.

The society simulation is quite a ways off still, but simulating on different LOD might be needed earlier for auto-evo for the aware stage onwards (perhaps late multicellular as well). We talked about it a bit on Discord and I thought Deus explained the idea best:

“with regards to auto-evo: maybe we can reduce the number of biomes/patches auto-evo has to run through based on the distance of said biomes from the player. Let’s say you are in the Sahara Desert, or inhabiting a biome right next to it; and let’s say the sahara desert would be made up of five distinct “biomes” for the player to interact with. With that proximity, auto-evo will run an individual simulation for each biome. But, let’s say you were on the other side of the world, in North America for example. With that proximity, auto-evo will just treat the Sahara desert as one biome. So practically, living next to the Sahara desert will result in more species diversity and a more detailed simulation, while living on the other side of the world will result in a more homogenous mix of species. Would that be feasible? 1. Auto-evo itself wouldn’t be changed at all, and the Sahara desert would still ultimately be composed of 5 biomes/patches. But auto-evo will just treat all 5 biomes of similar conditions the same, running it once for similar conditions”

This idea doesn’t even need to be aware of the different LOD of the things it is simulating, but the world generator at least would so as to not have the low LOD patches containing the subdivided high LOD patches be simulated as well. Making the simulation aware of these LOD levels could also help it try to ‘even out’ the evolution somehow so that the grander scale results of evolution are not impacted as much by this concentration of simulation effort on the more local regions. Or it could compensate for the reduced LOD when moving closer to areas that were previously simulated at a grander LOD, but are becoming potentially more relevant. This might still not be necessary, but it would become a more important issue to at least consider sooner. I think that it is worth having the world generator at least make sure that ideas like this could be done easily. The world generator will already have to generate the different levels of detail anyway, so making sure that the simulator could access/modify them in a logical and coherent manor would not be too much more to add. Even if it ends up not being required for the game to work and the experience is fine just simulating everything at the same LOD, it might still save some performance/simulation time that could be better used elsewhere or just lower the performance requirements.

Again though, I don’t think that anyone working on auto-evo now needs to worry about implementing it until we get to simulating the stages with the scale change (after multicellular) and determine if it is needed. I do think it would need to be strongly considered for the world generator though, as those stages would be the the ones where it would actually matter to have a real world generator. I believe that the huge scale differences involved with having both a world wide simulation and extremely localized gameplay will be one of the primary challenges of the world generator.

1 Like

The intention of having it be a separate project would be specifically to avoid needing to change the main codebase frequently. Having the interface change often would indeed severely reduce the usefulness of it being separated. The world generator is certain to initially go through a lot of revisions, but it would do so while still separate from the main codebase. Once the world generator has a good, stable interface is when it would be integrated with the project. It should essentially contain any changes made to the internals to the world generator project. It would be designed as similar to a normal database as is possible, so you can upgrade the version without having to worry about the compatibility issues most of the time. It still can’t be ‘just’ a database, but making it as conceptually close as possible to one would make the separation as cleaner.

As for it gaining more advanced features over time, that should all be done internally, with the interface remaining constant whenever possible. The idea is that all of the main features that would require changing the interface would already have their interfaces created by the time it is used in Thrive, and have at least basic implementations made for the more advanced features. Some of these features, like ones more useful in the later society stages, might go mostly unused for some time but should still be at least present for the ability to continue prototype work on the later stages.

I suppose I have not been entirely clear on this: I am not proposing that the entire system be rigidly defined at the beginning, before it is even started. I have already started prototype work on this world generation system and that has partially informed some of what I have written here. And it still has some ways to go before a stable interface can even begin to be defined, but I do need to know at least what the potential features it would need to support are before a prototype can be made of those features. This will require some speculation, and potentially involve work on features that will end up with different requirements when they are finally used in the main project and will need some amount of redesign. But, I think that this risk is acceptable, especially because the world generator itself is a feature mainly for the later stages of the game. I believe that trying to reduce the amount of major redesigns of the world generator will be a good tradeoff for the initial amount of time invested into its design. This proposal is mainly to start discussion on those features (which has already been useful for me in seeing what all is required of the world generator) and to give a plan for developing a system over time that should be flexible enough to work in the long run with all of the features that will be required of it. After a more developed prototype is created using this information is when a more specific specification can be made.

I’m of the opposite opinion, but I’ll let you try your approach. I think the mess of managing which Thrive version goes with what world generator version will be much worse than having everything in the same repo so that a single commit identifies the entire software configuration. I have a bit of professional experience with the nightmare that having 2 repos with interlinked features causes, you need to always be asking people if they have the right commit from both repos and talking about what new feature branch is related to what other branch in the different repo.

Granted, it won’t be the first time Thrive works with separate projects. Leviathan engine comes to mind, and as had been shown before, it’s not exactly the most problematic (except perhaps the usability), Godot is literally a separate project and our implementation completely depends on it. Few interlinkage would be good but in the end it’s inevitable.

Given the current circumstance, I believe separating it out as a separate project is the lesser of two evil since the generator wants to be developed now but Thrive isn’t fully ready for it yet.

I think the opposite really is true, putting the code in the Thrive repo even if it doesn’t interact with anything will be easier, especially as you can just put very random test scenes in the specific folder reserved for them to for example test rendering of world data. Once the stuff is already in Thrive and working with our Godot project settings, incorporating it into the existing game scenes will be much easier.

Depends on how this would be implemented which I can’t say for sure…

If I’m not mistaken @HyperbolicHadron did mention that he plans to integrate the generator with Thrive once 4.x switch is done.

I don’t want to sound overly committed to the world generator remaining a separate project from the rest of Thrive. I believe designing it as a separate project would be the best option in the beginning, as that is when most of the rapid prototyping and changes would occur. And I think that there can be many benefits of it continuing as a separate project in the future. But if the benefits do not end up sufficiently outweighing the costs, then I would fully support changing the way that the world generator is integrated. I am sure that this will need to be reevaluated multiple times over the course of the project if this path is taken, but I think that it will be worthwhile to do it this way. Especially if there is consideration for other parts of the project to also be designed separately. Thinking about how this could all work seems useful for designing the world generator and other potential separated Thrive projects, but I would not think that we will be able to reach a more definite conclusion until more work and testing is done.

Right now, I am predicting that the world generator would be integrated with Thrive sometime after the Godot 4.x switch occurs. Mostly because it seems like it will take some time for the world generator to be developed, and also that it will take some time for Thrive to get to the point where it will require the world generator. There is some balance between integrating the world generator early, so features depending on it could be begun in Thrive itself, and waiting longer until it is needed, so that any code using the world generator would not need to be redesigned while the world generator design is still being worked out. How long it will take to develop the world generator is difficult to predict now, but that should be able to be done better once the prototype work develops more.

As far as what the predicted ideal time to integrate the world generator would be, I would like to hear more opinions on that. The roadmap does not primarily focus on the stages after microbe until after 0.9, but would there be enough development of those stages anyway to require the world generator? (Of note, the roadmap has the “Planet Generation and Customization” listed under 0.8.x: Release Roadmap - Thrive Developer Wiki)

There is also the PR side of things to consider, how important should it be for Thrive to have the world generator as part of the game, even if it is not yet important for gameplay. This could include features such as real time cinematics for a new world creation showing off the world generator. It would not enhance the microbe or early multicellular gameplay any, but could show that efforts towards the later stages of the game are being developed in an exciting way. How useful would that actually be to Thrive? I know that I personally am excited to see the convolution surfaces finally implemented, and I see that as a similar, though far more immediately important, feature for Thrive. Even a basic version of the 3D organism editor with convolution surfaces would be a major win for Thrive in my opinion. For reference, Spore’s creature creator was impressive enough to be released on its own before Spore’s own release, and seemed to be pretty effective. I think that the world generator could be in a similar position as the 3D organism editor & convolution surfaces in terms of its outreach potential, but I am a bit biased here as this is pretty much my singular focus for developing Thrive. Knowing what others think about this would be useful to see what areas of the world generator should be focused on in the nearer term.