Little bit of progress today, it looks weird because it can’t yet detect when two line segments are lying on top of each other, however I think I know how to sort that out. Also needs more work on the connecting lines.
1 Like
Ok this took ages but it’s finally working ok. Pro tip: down name all your variables the same thing ha ha, if you do you’re gonna have a bad time.
When I next get round to this I’ll have a look at designing some tiles for it and seeing how that looks. It might a bit “squiggly” at the moment where there’s too many curves in the lines, not sure.
Oh nice, but yeah it looks a tad too squiggly. When I made my maps I put the turns near the boxes to avoid that look, another option is to aling all the boxes’ nodes (and in turn, the boxes themselves) so there are as few turns as possible
sorry for the weird posts earlier but its late and i accidentally posted before i was ready:
behold! (i suggest viewing this in a new tab to zoom in. or just read the explanations below)
This is a concept that i’ve been working on for a few weeks regarding the patch map in general. Mostly it’s just brainstorming trying to bring existing ideas together, such as the vertical boxes suggested by @tjwhale and the planet grid suggested by @Buckly in the Discord.
Apologies if the wording is confusing, it was really late when i wrote all this so i’m rather tired
Highlights and explanations: (warning: long!)
"Stacks" and Boxes
Here, “boxes” refers to a grouping of patches (like the three in the second diagram) while “stacks” refers specifically to boxes that organize ocean patches by depth.
In this concept I first briefly consider ways to compress groups of ocean patches sorted by depth, in the left side of the “‘Stacks’ and Boxes” section. I didn’t really come to any aesthetic decisions but I settled on some sort of icon showing, at least, the deepest patch in the stack and any features present within it. (Features being caves, hydrothermal vents, tidepools, etc… perhaps any geographical feature that can be considered to be essentially a single point on the map?)
The diagrams show a simple connection between two minimized stack icons, then the same connection but with both expanded, then finally the complete view of all actual connections between all patches involved.
Never in any of the images do the connections between patches change, only the method of displaying them. in the second, the connections between stacks, and between a stack and its own features, aren’t clear, and are instead highly simplified into a single line. However, these lines between boxes follow a consistent set of rules which will be detailed in the next section.
(Also ideally hovering over a patch would also highlight patches connected to it)
Rules
Here is where I try to determine the set of rules that define what that simplified line between boxes means. In-game, the rules should absolutely be constant, however I did quite a bit of brainstorming trying to figure out what those rules should be, and much of it is still really subjective, especially the two letter options.
Here I decided to name rulesets with a simple code: “X-#”; X representing a letter (just A or B) and # representing a number (1, 2, or 3)
Note that dotted lines represent divisions into stacks and unique patches.
The letter options determine how connections between the general “terrain” of oceans should work. that is, what patches should a water patch of a given depth connect to? a floor? And it doesn’t really affect the appearance or layout of the patch map as long as connections are simplified between boxes.
So essentially in A connections are only adjacent, while in B they include diagonals as well. (Plus some extra stuff about floors, I’d look at the arrows to get a better idea.)
The number options, meanwhile, determine how special connections with features are handled, which do affect the appearance and layout of the patch map, and are incompatible with some other methods of the patch map’s organization and creation.
The maps to the right show how the patch maps of the example terrain next to the rule number would look with that rule being followed.
1 really only works with the “columns” method of ocean division (see “Ways to divide oceans”).
So essentially, since features like caves and vents are always (hopefully) grounded, and they can also be accessed from the water, they simply connect to the lowest two patches of a stack - those being the lowest floor and the water of the same depth directly above it.
This rule results in, essentially, the patch map depicted in this concept art.
Patches
This only really works with the columns method, because only the columns method is guaranteed to have only one floor at one specific depth. If columns is used, then this works fine, but since I don’t prefer it, I looked for alternatives.
2 is more tailored for the “mushrooms” ocean division method (again, see “Ways to divide oceans”); though it wouldn’t break under the “columns” method, it would seem incredibly redundant and overcomplicated.
In rule X-2, each feature type has its own depth, which determines which floor and water patches it connects to via Box Connection Magic. Because this rule is based on a division method that allows multiple floors per stack, I had to adjust the way stacks displayed floors and came up with this.
If a floor for a specific depth is present, it will be put right next to the water patch of the same depth. Then, of course, the specified depth of each feature will connect it to the appropriate floor and water patches (and hopefully the game would know not to put a vent in the middle of the mesopelagic layer when the only floor is in the abyss. something something floating volcanoes)
Personally, I think the layout for this rule isn’t as pretty and satisfying as X-1 is. Plus it fails to take into account the possibility of multiple floors at the same depth, which don’t all connect to the same features. (and could also get messy)
i hope you like mesopelagic floors
3 is the final rule I came up with, this one also for the “mushroom” method. I tried to return to the thin look of 1’s patch map, while also solving the multiple-floors issue.
In this rule, all patches of a certain depth - both the water patch and any floor patches, plus any features on those floors - are all combined into one square, which can be “zoomed into” to show the individual patches that make it up.
Both floor patches connect to the water patch, but not each other (if the floors directly connected, they might as well just be the same floor), while the features connect to both the floor they’re under as well as the water patch.
I feel this rule almost compresses things too much, because I did like the look of the features being displayed visibly underneath the stacks. However it does also work with a division method I much prefer and turns what would be a large number of patches into a fairly digestible amount. (See “Ways to divide oceans”)
I do also have concerns that this may involve too much clicking and too much information hidden away at first glance.
Ways to divide oceans
In my mind, when Thrive actually generates maps, the game (when making the patch map) turns the oceans into thin horizontal slices of depth, then terraces out the ocean floors into floors based on those depths, resulting in something resembling the two side view images, minus the dotted lines.
Then, it’s up to the game to divide this terrain into a reasonable number of unique patches, which then cleanly fit into stacks. I’ve come up with two ways of doing that.
Columns
The first method I came up with very simply divides the ocean at any change in depth, meaning each stack would be a cross section of terrain with a virtually uniform depth. It’s fairly simple, and makes ruleset X-1 valid (see “Rules”), but also results in a fairly large number of unusually-shaped patches and stacks. (even if it does make the patch map look pretty)
Mushrooms
(notice me brainstorming for rules X-2 and -3 in the wrong section!!!)
I called this one mushrooms because, in a stack, any water patch will be less or equal in size to the one above it, resulting in stack shapes that widen near the top. like mushrooms!
The division would be less predictable and perhaps more arbitrary based on how large we/the game decide the stacks should generally be. Perhaps separate generally deeper areas from more shallow ones, like in the example?
The patch map is not as big as that of Columns, though X-2 is so bulky it gets close anyways. X-3, meanwhile, is fairly compact.
Grid Intro
In the Discord, Buckly suggested we use an overview of the generated world with regions separated via a tilemap, like this:
I think they’re onto something, because previously the patch map was mostly imagined as a scattered web of interconnected patches on a 2D plane, all representing the entire world.
This became fairly prone to clutter, especially if we tried to group them by latitude and such. But adding a grid allows the map to be even more large and global, while also grouping patches into reasonable chunks. If the grid is represented on a sphere, it also easily solves the issue of how to represent planet looping, which was quite problematic on a 2D plane.
Maybe not a rectangular grid though…
There is the problem that seeing the spherical grid in front of them might reveal too much to the player by showing them the latitude and longitude of various places. However, based on the type of grid, and perhaps how the camera behaves, the player might not even know which way is north or where the poles are.
Finally, the grid could be used to communicate the range of the player’s species across the planet at a glance.
Grid
In the next two sections, I experimented with two ways of actually organizing patches and stacks within the grid.
In this method, the game takes the patches/stacks present in each grid square, and simply places them inside those squares. (the color wheels “squares with patch content shown” shows which patches/stacks are in each square, without referencing position within them.)
The same patch/stack can be present in multiple squares.
These notes summarize my thoughts on this pretty well:
Though what I mean by the third bullet is this:
If you have the upper-right square selected (which contains an abyssopelagic-depth stack), how does it connect to the yellow vent in the bottom-left square? If we follow the first few sections, the yellow vent is part of that stack. meaning that if it’s the same stack in those two squares, the vent would be accessible from the top-right square. But that also doesn’t make sense, because it’s located in a square that’s really far away!
I may also be overthinking this, because the geography isn’t fully visible to players at this stage of the game so they might not even notice! Though, it is pretty noticeable to have the same vents and caves available from any square that has their stack. Is there a way to make vents be part of a stack, but also localized to one square? Needs more thought, I guess. I’m tired.
After that I thought about ways to make the fact that squares can share patches/stacks more apparent. If the player can navigate through the squares while zoomed in and looking at the patches/stacks, shared statches could scroll into the new selected square instead of scrolling offscreen with the old one.
(I suppose I shouldn’t say squares, since rectangular grids aren’t good on spheres. I’ll keep saying squares for consistency but “cells” seems like a better term. as long as it’s not confused with actual microbes)
Blocks
I wasn’t confident that the grid method in the previous section wouldn’t be confusing, so I tried something else. (actually this part was the first one I started working on in this concept, but ignore that)
So here, patches/stacks can be present in ONLY ONE block (though blocks can have more than one patch/stack inside of them!) This method allows the combination of squares into blocks in order to maintain this rule. To the right there are some notes on how I divided the patches/stacks in the second example, and I also voiced most of my concerns there. Basically it’s awkward, inconsistent, potentially geography-revealing, and also I don’t actually know how it works.
On dividing patches into squares:
This might seem like a reasonable compromise between the Grid and Blocks methods; patches and stacks are divided by the grid so that no one patch is in multiple squares without having to combine squares into awkward-looking blocks. However, as mentioned in the concept, this would create way too many new, near-identical patches.
2 Likes
Very nice and thoughtful concept you’ve made. I gotta put it in the GDD in the future (or you can do it yourself wink)
The grid and block ideas can be used in the future, when species have more knowledge about their world, but i think a planet can be represented with the current design pretty well. I really like the X-3 ruleset, collapsing patches will make things less cluttered. However, in the case a player wants to travel from one floor to another below, how will it be displayed in the patch map? I suppose that collapsed squares can be expanded by just clicking them, so it should be possible to open several squares at the same time. That may make things too messy if there’s not enough space, but we can make rules about placing the expanded patches, like if the player opens a meso and bathy groups of one column one group would be on the right of the column and the other on the left.
I’m also open to dividing large areas of the ocean in different patches, even if there are no big differences between them, like what you did with the epi layer on “Ways to divide oceas”, i think rulesets X-2 and X-3 work well in that regard. But I still think environmental conditions are the most important factor for dividing the ocean patches rather than which features are below them or their size.
2 Likes
However, in the case a player wants to travel from one floor to another below, how will it be displayed in the patch map? I suppose that collapsed squares can be expanded by just clicking them, so it should be possible to open several squares at the same time.
I made a quick sketch based on this question. The golden ‘@’ symbol and outlines represent the “current” patch, while the green outlines highlight which patches are accessible from it. The map to the right shows the stack it’s based on, with the colors representing floors of that depth. (there aren’t any epi-colored shapes in it because the epi layer doesn’t have any floors, it’s just water)
Maybe the expanded views of the collapsed patches can be dragged around freely with the mouse? And of course hidden when not needed; the first floor in the lowest group would still be accessible even with the other group closed.
Doing this concept made me realize that it’s not really a good idea though. Without knowledge of the actual terrain, the connections will be arbitrary and unintuitive. The collapsed patches just aren’t following any consistent rules when connecting to each other.
For example look at this stack, which has a map that is totally identical to the other one in appearance, yet the connections are different because of something entirely out of the player’s knowledge. This method would require lots of trial and error to navigate, which isn’t very good.
Maybe a way around this is to use rule x-2, and just ensure that stacks only have one floor of each depth when creating them? I dunno
1 Like
Thought about this a bit more.
So, first of all, as a friend of mine pointed out, I’m doing a lot of complicated stuff in order to both accurately and digestibly convey all the ways all the different patches in a randomly generated world connect with each other. It feels like a lot of work on something that might be confusing to players because an actual visual map would be several times more intuitive.
However, that very much goes against the theme of discovery we’ve been wanting. being able to see your planet’s geography immediately ruins the process of slowly mapping it out in the society stage, or finally getting a clear picture of it when the planet is photographed in the space stage. But an actual map is so much easier in so many ways. Maybe a way of displaying it so symbolically/abstractly that it’s hard for the player to actually see what their planet looks like until those later stages where it’s “colored in”? I have no idea how that would look though.
Anyway, with all that said, here a few more concepts I’ve done in the past few days. This is all based on a series of lengthy posts I made in the discord yesterday, but actually since I haven’t really updated this thread with my ideas lately I’ll include stuff from earlier.
This is a “chunk” of ocean, made up of water and floor patches. (previously i’ve just been calling them “oceans,” but that’s a bit misleading. chunks might not be a good name either but I’ll use that for now) All the water on a planet would be divided into some number of these in order to organize the patches instead of leaving them a jumbled, world-spanning mess. Each chunk is made up of both a network of water and floor patches.
The water patches are organized by depth, starting with a single epipelagic patch at the top. As the topography of the ocean lowers in multiple places, creating holes, the water patches “fork.” (e.g.: one mesopelagic patch for the one mesopelagic hole, three bathypelagic patches for the three bathypelagic holes, and then some more abyssopelagic patches for the abyssopelagic depressions in two of the bathypelagic holes. This is done because, for example, if there were just one patch for each water depth in a chunk like this, it would be possible to be situated on the floor of an abyssopelagic pit, swim up into the abyssal water, and then teleport to another abyssopelagic pit, even if they’re divided by much higher terrain.
Meanwhile the floor patches are organized via a sort of hierarchy system:
floor patches can have a single parent (a patch, plus or minus one depth, which surrounds them entirely) and multiple children (patches, plus or minus one depth, which they surround entirely). The resulting tree of patches can be a little confusing since it’s not vertically sorted by depth like the one for water, but I’m not sure if a hierarchy tree sorted by depth would work in all cases.
Also I haven’t really thought of a way to show which water patches connect to which floor patches.
Here’s a bunch of chunks, with two of them rendered in high quality 3d, alongside some blue outlines for all the water depths, plus the water and floor trees.
Here’s the same group but with more uniform colors, and a zoom-in on a certain patch in a certain chunk
Some more elaboration on the zoom-in in the last image; it’s a way to show a selected patch’s connections, including those in other chunks.
The patch in the center is the selected one, and its parents and children are to the left and right, respectively. Any features (vents, caves, tidepools, etc.) are to the bottom – features are somewhat “contained” within their respective patches, though features like cave entrances may link to the main “body” of their cave, which exists disconnected in a void because it may connect to entrances potentially all over the world. (need to think about patch distances btw)
At the top are all of the directly adjacent patches (same depth) that are located in other oceans.
Finally, I thought about how chunks would work with the planet grid, and how big they’d be in general.
If chunks are larger than the cells on the grid, and a patch or a feature (like a vent) in a selected chunk is located in a part that’s in a different cell, does it show up? can it be traveled to? Does this question matter at all
Also, for individual chunks, how big should they be? large enough that there’s only a few per world, and they mostly serve the role as oceans? Or smaller, so the topography each represents is simpler? If they’re smaller, that means more ocean patches overall, which might get overwhelming. However patches too large means there won’t be much diversity among large sections of the ocean (assuming all patches are homogeneous)
4 Likes
Hey Narotiza, you have been doing incredible work here with your concepts and designs, and I mean it! I really agree with not having a completely visual map to preserve the sense of discovery in later stages. (It’s not like cells have little maps in their exploration kits in real life.) but you’re right about it being difficult to come up with a good solution for that. I imagine a sort of abstract map being a vague greyscale representation of topography but I am not sure.
I think we could perhaps house a specially marked patch between chunks. This marked patch would act as a gateway of sorts that once traveled to, places the player in the next chunk with the previously visited patch from the last chunk still remaining on the map as the new gateway to the previous patch. Could this work when traveling between planet hexes? I am not sure.
I think a decent chunk size could be 1/3 of the size of a hex, so three chunks could fit into one hex… A size around there could keep things more manageable and less overwhelming, but maybe 1/4 or smaller is better? Is this something we could experiment with?
I wish I could be of more help but I am really at a loss of ideas here. For whatever reason, map systems of this scale seem to be beyond me. But regardless, I will try to contemplate the system as well.
1 Like
@Buckly My idea was that any patch that’s adjacent to another patch in a different chunk could act as a gateway. By “scoping in” to a patch, you would see all the other patches connected to it, including those in other chunks. This does seem a bit inconvenient though. lots of extra clicks to get to where you want to be. Depends on how often the player will need to guide their species, I guess.
Here’s a concept I worked on a little earlier in an attempt to find some patterns that could be used to help generate a “fake” patch map, which isn’t based on actual topography, but instead is randomly generated according to principles inspired by “real” patch maps that are.
I didn’t really come up with anything but it was my first real attempt to show how the overall map of an entire planet might look.
Anyway, with all that out of the way…
Despite all the work we’ve poured into figuring out a node-based patch map, I honestly think a visual map might be a lot simpler at this point. It turns out that representing all the patches in the world and their connections in an understandable way is kinda hard to do, and I’m not sure if going through all this work just to hide information from the player is worth it.
so one way to visually convey the map without revealing the whole globe all at once would be to have only one small section of it be viewable at a time (such as a single square/cell, if the planet were divided with a grid similar to this:)
(ocean “chunks” aren’t being considered here at all, and the hexagonal and pentagonal cells are only here to divide the planet into smaller, viewable pieces)
Players would be able to see the general topology of the currently viewed cell, perhaps somewhat “black and white” (symbolically speaking) so as to not give away the general look of the world, while still accurately conveying the highs and lows, which are relevant to the player.
The player could maybe move a cursor around in the highlighted cell, which would show which patches are directly under it.
Here is an example of an alien planet, divided in the way shown above. A single, hexagonal cell is highlighted and zoomed in on, with the cursor hovering over the ocean and showing the patches underneath it. (note that the cross-section underneath doesn’t correspond to the terrain in the cell, it’s just a diagram with exaggerated terrain to show how selecting patches works)
While this prevents players from immediately seeing their entire world all at once, someone could potentially painstakingly go through every cell and copy its contents until a complete globe of the planet exists. One way to prevent this, at least early on, would be to only have cells near your species’ populations visible, with the rest covered in a fog of war until your species expands near them.
With the whole world grayed out and replaced with what looks like an advanced football, it might be easy to lose track of where things are, so perhaps the cells could be shaded in regards to different things. In the concept I showed highlighting according to player population, so players can know where their species is, and land percentage, so players can see where they (mostly) can and can’t go.
5 Likes
I think that it is, vastly, vastly, harder to make an entire planet generator that splits things into patches so that the microbe stage can be played there. Especially because people want things like plate tectonics, and terrain being eroded by water and stuff.
Instead of all of that hard stuff, I say we just go with the original plan of having a patch map that looks like this:
Only taking basic planetary conditions into account for what kind of patches, and how many to include in the map. Patch connection numbers and restrictions can be tweaked manually until the random results look good.
Laying out a bunch of 2d nodes with connections on them, that are unwrapped so that a minimal amount of connections overlap, is a problem solvable with computer science. It sounds like a computational graph theory problem that could be in some list of challenges.
We won’t ever for a long time get the procedural patch map done, if people won’t accept anything else than 1-to-1 representation of a fully simulated planet that is turned into a map of 2D patches.
5 Likes
So I am reviving this post to give my opinion on the actual forum, since I’m realizing I never did that.
I basically agree with HH here for anything microscopic. I think it does not make much difference as a tardigrade or algae cell whether you are playing in a water droplet you can’t traverse across over one side of the planet or the other. The tectonics and land formations don’t matter and (as far as I am aware) we don’t have plans to give players to observe their planet until they have technology or are big enough to stroll around it.
When it comes to not microscopic (so like, a fish / early aware) the planet will have to be considered but that can be simple if we make it so. Basically, the number and types of patches should match the patches generated on the planet (I shall give my opinion on that too in the proper thread) and you’re good. So I suppose it can’t be insanely random.
3 Likes
It’s been some time since we first began discussing the patch maps for later stages, and for good reason. The move from the microbial scale necessitates an ever expansive view of the world; The complexity of which requires careful thought and consideration.
After discussing with everyone in our developer chatroom and reviewing our forums concepts, I have taken the time to consolidate and refine all of our numerous discussions into one comprehensive concept, which should serve as a foundation for future designs.
Keep in mind, that this is intended for later stages, and not the microbe/early mutlicell stages. Our early stages shall utilize a patch map system much like that proposed by TjWhale in the past.
Generation of The World
In all of our concepts, it seems that the icosphere has reigned as the dominant medium for the patch map due to it’s natural similarity towards other systems in Thrive (Or maybe we are just obsessed with hexagons). It’s nature effectively allows us to isolate and define specific regions across a globular surface, which means we can arrange the familiar patch system along the entire planet; Thus I believe that sticking with this familiar sphere is our best course of action.
Before the map can be generated, we must create the world, or at least it’s climate conditions.
The physical world will need to be generated to the specifications set at the start of a game, using water content, atmosphere, mass, etc, in order to arrange the overall layout of climate on the planet. The exact specifics of how this will be achieved is an entirely different discussion, which is best left for another thread.
Once the climate has been created, Each tile will be assigned with a biome identity based on local characteristics like temperature, moisture, etc. For example, high humidity/low elevation tiles would be identified as “ocean”.
I couldn’t draw an icosphere, sorry. Have a Heroscape board instead.
Unfortunately, this many tiles creates a large amount of redundancy as the patch map is littered with swathes of nigh identical isolated patches. This makes the map painstaking to navigate, and individual locations hard to identify. “Oh, primum doofus has speciated in Shallow Ocean #85? Where is that?”
The solution is to group similar tiles into “regions”.
Adjacent tiles with matching biomes will be grouped together to form a complete region with variable capacity and resource availability based on the total amount of tiles included within. Each region will have a maximum amount of tiles in order to increase total number of regions for diffentiation if necessary. (Exact number will need to be decided through testing.)
“Ah, primum doofus speciated in the Dealian Sea, that’s pretty close to me. Time to greet the new neighbors.”
Now that the world is divied up into distinct regions, the player will have a much easier time navigating it while we still have the added bonus of strictly defining where each species might reside for simulation purposes.
Of course, this is merely scratching the surface. The ocean isn’t just one big environment; It’s many environments all nested within one region!
Regions and Patches
Each region can contain an assortment of environments that further differentiate them such as oases and caves on land, or pelagic regions and vents in aquatic environments. Each environment will be listed as a patch in a sub-menu that appears when the region is selected. Think of regions as something analogous to things like the Sahara desert, or Mediterranean sea. Both of these are regions but have numerous unique environments localized within them.
By selecting a region, you can access it’s internal patch-map which will list all of the environments contained within it’s borders.
These environments are not closed systems; Predators on land can prey on fish in a pond, scavengers on the sea floor can sustain themselves off of corpses fallen from the surface. To inhabit a patch is to identify it as your home environment, but you will still be part of the greater ecosystem of a region, and thus will be able to navigate freely throughout. Much like how a frog lives in a pond, but can freely move to the surrounding forest as needed.
Migrating should work much the same way as it did in the microbe-stage patch map, but I am still uncertain on the specifics of how it should work now that the player might be able to travel between patches during gameplay. With the increase in scale, the player might be able to freely migrate between all of the environments in their local region each generation but they will still be limited to adjacent regions only.
Does this concept seem feasible? Does it suitably cover our needs? I would like to hear what everyone thinks of this, so don’t be afraid to discuss.
5 Likes
Seems pretty good to me. Of course when someone actually gets to coding these features, we’ll discover a bunch of edge cases and parts that are surprisingly hard to program.
2 Likes
Here are some thoughts on how the patch map can change dynamically.
Dynamic Patch Maps
Involving some sort of dynamism with patches in the Microbe Stage will be pretty important to the setting of Thrive as millions and millions of years pass on. However, implementing complex simulations based on tectonic plates, and maps that are able to dramatically transform and look completely different isn’t necessary in the Microbe Stage; locations are so abstract that defined geographical features are very difficult and unnecessary to convey.
Therefore, I think dynamism in the patch map throughout the Microbe Stage can be represented adequately just through these features…
Potential for Surface Patches to Change - The depths are historically known for being relatively stable environments throughout most of Earth’s history. Most changes to the environment occur on the surface - shifts between estuaries and regular surface water, frozen patches, etc.
Ability for Connections Between Patch Clusters to Shift - Throughout time, the ability to go from one group of patches to another could shift. In other words, the lines between patches might disappear or reappear.
I think the second point is relatively self explanatory. One thing to note is that we would likely want to indicate when a patch is going to disappear. Making the lines dashed for a turn before could be a good way of representing this.
The first point requires some consideration. Realistically, there are four surface patches to consider: the epipelagic, coastal, estuary, and frozen patches. Shifts between the epipelagic and coastal environments won’t represent dramatic shifts from each other in the Microbe Stage. The real shift is the chance for glaciation, which will represent a considerable challenge for organisms and players existing on the patch.
One important question: how should we indicate that a patch is about to change? We probably don’t want to straight up just tell the player exactly what’s going to happen and what to do, but we should definitely make clear that the patch is going to change.
I think one simple way is to have a descriptor in the auto-evo reports tab in turns prior to the change. Along with changes in the graphs, a line of text which changes depending on the environment about to occur can be seen.
For example, a shift to polar seas can read: “Temperatures are getting colder and colder. The patch will change in X turns.” I’d say a 3 turn forewarning would be enough.
It makes logical sense for patch changes to be pretty limited based on the nature of the patch. By that, I mean that an epipelagic patch realistically won’t become an estuary. Here is the spread:
Epipelagic - Can become a shallow sea or a frozen patch. If becoming a shallow sea, cloud compound proportions all generally increase. If becoming frozen, temperatures drop and sunlight decreases.
Shallow Sea - Can become either of the other three. If becoming an estuary, becomes freshwater. If becoming epipelagic, compounds generally reduce and sunlight decreases. If becoming frozen, temperatures and sunlight drop.
Estuary - Can become a frozen patch or a shallow sea. If becoming a shallow sea, becomes saltwater. If becoming frozen, temperature and sunlight drop.
Frozen Sea - Can become any of the three. Temperature general increase and compounds grow to reflect other patches.
These can generally be expressed as chance, though if temperatures are low, the chances of becoming frozen can increase. Environmental events can dramatically alter local conditions; shifts outside of environmental events aren’t very likely.
I think the relative simplicity of patch shifts in the Microbe Stage will serve as a really good and simple introduction to the challenges one will face in the later stages, where patches will be more explicitly defined.
Environmental Events
Here is a write up on environmental events. A lot of this is existing concepts written up to be more actionable.
Volcanic Eruption - Affected regions experience initial warming, and later some temporary cooling. Sunlight is significantly reduced. Sulfur becomes much more common, along with phosphate and ammonia. Can last anywhere from 3-5 turns.
Meteor Strike - Very similar to volcano, but more short-lived. Affected regions experience initial warming, and then a less severe cooling. Sunlight is reduced. Effects can last 1-2 turns.
Glaciation - General climate trend. Some surface patches become icy seas, and temperatures get somewhat cooler globally. Some variance, but shouldn’t necessitate significant adaptations in all patches. Depths shouldn’t be significantly affected.
Global Warming - General climate trend. Icy seas reduce in frequency, and global temperatures generally increase. Some variance, perhaps enough for icy seas to completely disappear, but shouldn’t necessitate significant adaptations in all patches. Depths shouldn’t be significantly affected.
Snowball Earth - Glaciation which all of almost all surface patches on Earth freeze over, and most mesopelagic patches get colder. Some variance, but can last anywhere from 3 to 6 turns. Depths shouldn’t be significantly affected.
(Bonus) Earthquake - I don’t think this one is necessary, but the concept existed for a while. Currents on a patch change completely during gameplay.
EDIT: I’d like to note that if it is too much of a headache, I think attaching patch changes to environmental events only is adequate. This would exclude changes between estuaries , epipelagic, and shallow seas, but glaciation and global warming are the two most common and significant environmental changes throughout history.
5 Likes
I like these concepts, however something to keep in mind is turn length. Each “turn” (player generation) represents 100 million years. If a Volcanic Eruption is an event lasting 3-5 turns, that’d be 300-500 million years.
To my knowledge, the longest volcanic event in Earth’s history was the eruption of the Siberian Traps, which spanned roughly 2 million years and was the primary cause of the Permian-Triassic extinction.
I don’t believe there’s a real solution to this. Turns could perhaps be reduced to 50 million years, but any shorter and the player would become eukaryotic and multicellular on vastly shorter timescales than we know to have happened on Earth.
I think that there should be two kinds of events: in-gameplay events, like the Earthquake you mentioned, that briefly change gameplay in a patch, and events that affect large areas of the planet on timescales of tens or hundreds of millions of years, such as Glaciation/Snowball Earth.
4 Likes
That is a good point, though like you mentioned I wouldn’t really know a solution that makes sense besides perhaps treating environmental events differently when it comes to keeping track of time. Even the longest Snowball Earth event in Earth’s history would essentially be one Microbial generation. It might just have to be another point to concede in that old Thrive inaccuracies thread we have here - the fact that thrivian environmental events last much longer than real ones do.
2 Likes
Some possible ideas: Increase the patches available in the world. This would allow for differences around a land mass which could also help in the efforts towards the planet generator since the patches and landmasses generated would be tied very close to one another.
Variations in the patches that currently don’t have a cold or hot or neutral temperature variant (for glaciation and hot house environmental events). The tide pool is one such location that would need variants to make it work with environmental events.
Patches being able to vanish or appear based on tectonic activity since such things occur. (adding patches would be like the forming of the Atlantic as Africa and South America split apart and removing patches would be like India slamming into Asia)
Also Global Warming should be Hot House as Global Warming/Climate Change is used regarding human activities changing the environment at an unnatural pace. Hot House is the termed generally used for Earth’s hotter periods
2 Likes
Extra Patch concept that Aaronmkersh uploaded on the Podcast discord chat that I thought I’d post here as well
3 Likes
Thanks for posting these, it slipped my mind to put them here. I’ll briefly elaborate on what’s shown here:
First are extra patch types that microbes live in on Earth. The Seamount is an underwater volcano. According to various observations microbes can live in the Troposphere and Stratosphere layers of Earth’s atmosphere, though to my understanding there is not consensus on if, or how many, microbe species truly thrive and reproduce up there or if they are merely carried by the wind currents. Microbes are also known to exist as much as 3 km under the ground, represented by the Subterranean and Aquifer patches.
Second are patches representing ice shell worlds with subsurface oceans like Europa, with hydrothermal vents and geysers / cryovolcanoes that sometimes blast water into space. It is possible life exists on worlds like these, and there are tentative hints in support of it, but ultimately it remains unknown. Certainly, it is theoretically possible.
Third are patches where microbes may be found on Mars. Like with Europa, there remains the potential for life but no confirmation as of yet. Recurring Slope Lineae are places where water seasonally leaches out through sides of craters, canyons and other features, creating small streams visible on the surface. Oxidized Regolith is the soil of mars, which the Viking missions in the 1970s may or may not have detected signs of microbial life in with their experiments. Again, inconclusive, but life is theoretically possible. It is worth noting that we believe Mars once had a water cycle and oceans, where life could have arose, and which were eventually lost. Mars also has an ice cap on its south pole, under which may reside liquid water kept warm by geothermal activity, represented by the Subglacial Vents.
Fourth is a single patch for Venus, representing the temperate layer in its upper atmosphere, which is actually the most Earth-like location (in terms of pressure and temperature) in the entire solar system. The main exception is the high amount of sulfuric acid, but there are theoretical ways life could endure such conditions, and many tentative hints that microbial life may indeed exist in its upper atmosphere. Again, though, not confirmed, but theoretically possible.
Fifth are patches representing various locations on Titan, which is utterly fascinating in its diversity and strangeness, and its potential for exotic, non-carbon-and-water-based life. It has methane and ethane rivers, lakes and rain, tons of surface variation, and all that on top of a likely subsurface water ocean. There’s far too much to get into here, and it really is fascinating, so I recommend just taking a look at the Wikipedia page for Titan, and other resources.
Sixth and finally are mantle patches, representing the environment for HIGHLY theoretical silicon dioxide (lava) based life. If life exists in these environments, it would be like nothing we have ever known.
This Wikipedia article broadly covers alternative biochemistries, including liquid hydrocarbon based life which may exist on Titan, silicon dioxide based life, and many others:
I will note that I do not think excessively theoretical biochemistries such as silicon dioxide should be included in the main scope of Thrive, but they are prime real estate for modding, and I plan on trying my hand at some of these eventually.
2 Likes
I have already stated that I would like to see more patches in the game. Particularly new patch types that allow players and auto-evo to evolve more unique and environment specific microbes. In general, I would like to see patches that represent environments with unique advantages and challenges.
Examples of some interesting patches would be:
- Hot springs, which would allow photosynthesis, chemosynthesis and thermosynthesis in the same patch. This would also enable possible sulphur photosynthesis which I believe was suggested a couple of times.
- Lakes and Rivers, particularly once Environment Tolerances are implemented. The interesting aspect of these patches would be the difference between sweet and salt water as well as having to deal with strong currents in rivers.
What do I propose?
However, I think other than having compounds and gasses in the environment change both over time and between patches, more specific “traits” should be used for certain patches or even entire regions.
For example, a certain patch might have a trait called “toxic chemicals”. This patch would have a vastly increased amount of environmental toxins. The player would see this trait on the patch map when selecting the patch, probably as an icon somewhere on the UI. If the player wanted to move to or through that patch, they would have to adapt to the new conditions. In this case it would be simple: increase health.
Alternatively, traits could be applied to entire regions. A trait like “trace ammonia” would mean greatly reduced quantities of ammonia in the patches of the region. This could serve as an incentive to evolve nitrogen fixing organelles which don’t see much use currently.
Other interesting traits might be:
- “Frozen Waters” - reduces amount of lux and causes ice chunks to spawn (this could affect entire regions)
- “High Geothermal Activity” - causes hydrogen sulfide to spawn (this would apply to patches other than vents, or entire regions)
- “High mucilage concentrations” - causes mucilage to spawn naturally (this would only appear once there are enough microbes in a patch)
- “High glucose concentrations” - causes a lot of natural glucose to spawn in the patch
Why should this be implemented?
I believe this system of patch/region traits would serve both as challenges and opportunities for players. This would make every planet and every game unique, with different opportunities for evolution and different challenges to face. It would be a way for the environment to affect the life on the planet, even before actual planet generation.
Moreover, I think this is more than just a “quick fix” before the planet generator. Actually, I think it would work well in tandem with a more advanced planet generator to represent local environments, or more broadly continents or regions. The planet generator would determine which traits could be generated.
I think it’s a clear system, that players understand. It is not too complicated to follow, and I have seen similar systems in other games. It is probably also easy to generate without getting into the nitty gritty of planet generation.