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.