At least now floors make sense, but yeah it looks a bit weird. Maybe floor icons should be redesigned so they look like a continuation of the icon above them. I’ll work on it.
I’ll post here the work I’ve been doing so it doesn’t get lost on discord. Here are the icons I was talking about.
And I’ve also made a mock up of the patch report based on MirrorMonkey’s and Narotiza’s own concepts:
So I’ve been thinking a bit more about this. I think maybe a good approach to the proc gen side is to have a tile based, free form generator.
So by tile based I mean a tile is a little section of map, maybe with one patch on it and some connectors, maybe has an ocean stack on it, maybe has a few little boxes connected together each of which has a couple of patches.
By free form I mean the tiles can be placed anywhere, not in a grid, and can then be connected with interesting connections not just horizontal and vertical.
I think this might give a good balance between control of being able to design the tiles and freedom where the maps can look relatively fluid.
Here’s a few examples of things, cut from the patch map we’ve drawn, which could be tiles and then could be connected up. I think the trick is to have the tiles be big enough to keep things neat while being small enough to allow a lot of different feeling worlds to emerge. All feedback welcome.
I guess that as long as it’s done right it can work, the main issue i see with it being free form is that tiles may end up scatered all over the place. Another issue is that these tiles have rectangular shapes with only right angles, while conectors might end up being diagonal contrasting too much with the map’s overal aesthetic. One option might be having premade conectors so we have even more control.
I guess we’ll have to wait and see how it looks.
So I had a little go at doing something a bit more freeform. This is boxes which are snapped to a grid but not tesselated like the tile prototypes. I think it has a nice balance between randomness and order.
Feels a bit like Christmas too
I guess the patches will go inside those boxes right? Those layouts look interesting
Yeah each box would be drawn from a tile library. Like 3 posts up I put a few examples of the sort of thing which could be in the library. So it might be a stack of ocean patches, or an estuary with a few tide pools branching off.
I like it because we could define cool features, like the two tide pools connected by a cave, and have that show up.
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.
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)
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.
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.
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)
(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.
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.
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)
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.
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.
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
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)
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.
@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.
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.
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.
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.
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.
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.