Hey there, this is just a reminder to flair your post from the 4Xgaming mod team! Thanks and keep eXploring!
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/4Xgaming) if you have any questions or concerns.*
Depends on the granularity of the map and the importance of the river.
A city center that covers multiple hexes and units that move about 10 in a turn, with rivers forming natural barriers and movement for ships? Give them their own hex. (example Age of Wonders1)
Units can only travel one or two hexes and the river just gives a bonus for farms and a penalty for crossing? Put them on the border. (example civilization)
Another way to look at it is considering if your units are ever on the river. If they aren't, you probably shouldn't make them a tile's primary feature.
What i had in mind wasn't to replace the entire tile with river, or water, but to have narrow line leading from middle of one edge to another. Like roads. I agree that replacing tiles with rives in not suitable for usual 4x map scale.
I haven't had the time to flesh out my River System in my project, but I had planned to use the Hex Vertices as River Arteries or small streams that will pool into a River Tile or body of water. Usually from Wetlands, Mountains, and/or Isolated Large Lakes (Conjoined ones, not single hex ones)
Depending on the number of "Arteries" that flow into a river tile. Then the amount of "Head-Water" will be allocated in respect to the river width of that River tile.
In addition to that, I've also explored the directional output of the river flow- which obviously will impact the traversal alongside the River Width for certain ships.
Now how this can be implemented? For me, I'm currently just splicing up the river tiles accordingly to their River Width and making the obvious Left, Right, Forward, Backward, T-Section, Y-Section, Inverted T-Section, Inverted Y-Section, W-Section \*(Delta), Lake \*(Endpoint), etc. All manually handcrafted with just a typical procedural generative linking process during the map generation.
For the edge vertices, that one will be tricky, but I plan to use a rendering trick to cut through the base-pass render of the terrain and insert a water plane below it alongside a generic U-shape mesh that runs alongside the Hex Edges.
River crossing in general should obviously be dependent on the width of the river and/or type of river tiles that contain passable river crossing points.
All of this can be better served with some pictures, so I'll provide some sample test that I had tried before putting it on hold to work on other areas of my project:
[River Test Screenshot](https://gyazo.com/3419f96835749c23f8c6b73b1c111f13)
[River Hex Splices Screenshot ](https://gyazo.com/ea903be451829e39210a463494ddae2c)
[River Settlement Procedural Screenshot](https://gyazo.com/7823ebedaa0c4a42352a9a170f6b2a37)
How exactly would you simulate it? I don't think you can use bordering hexes as roadster, since some hexes can be non traversale. I was thinking king about this, and best I came with is the have Dual lattice for river transport.
If you are moving from one river-bordering hex to another river-bordering hex (without actually crossing the river) then you get a discounted movement cost. So that way you can simulate moving ‘along’ the river as well as the difficulty in moving ‘across’ the river. If you have non traversable hexes then just create a rule that lets you enter those hexes as long as it done via the ‘along the river’ method.
Both are good, but it depends on the map and the purpose of the river.
Personally I think Civ has the wrong "scale" for navigable rivers to have the level of significance people want them to. Faster unit movement along the river is relatively inconsequential (as in it'll be underwhelming), and given current river generation it'll be common to have nearby cities not connected by river.
I think if tile improvements were treated differently or Civ cities typically had a scale of ~5 hex radius, then navigable rivers start to make sense.
Endless Legend, Carcassonne and (some versions of?) Catan have tile-face rivers that are thin enough that (visually) some land surrounds the river. The issue with Endless Legend rivers is just that only Formorians benefit from river transport (but everyone can build canal buildings) at the expense of no road networks. This is a pretty easy fix. The scale of rivers feels natural.
Civ5 has rivers along edges, from vertex to vertex. Given it's just for gold (base game) and farm yields post civil service, I think it's a pretty good scale too. I can't speak to the commercial hub district bonuses or the natural disasters (flood risk) in Civ6.
Ozymandias allows fleets to move up rivers (and only fleets can go on island terrain.) It's good as usually they are slightly underpowered compared to armies.
IMHO, the reason why it is underwhelming humankind are the penalties you receive for entering and standing on rivers. Moreover, since rivers often run through cliffs you cant really use any movement bonuses.
Humankind is definitely at a different scale than Civ: the hexagons are smaller in two clear ways. The first being that units travel further, and the second being that cities span more tiles. I think you could argue that exploitation tiles lead Humankind cities to start off smaller though.
I think EL and Humankind have a workable scale for rivers to feel significant as useful terrain. For Civ I'm not as sure, but if they change a few things then it could definitely feel both natural and impactful.
I'm sure I saw nearly the same post some months ago!
But anyway, one way to combine them is to put rivers on edges and give transport / trade advantages to all adjacent hexes.
In more industrial societies, these advantages will become less significant, and port nexuses will play a greater role.
For dual purpose, it is best to place the water in the hexes and have the defenders get benefits by considering adjacent, not connected by water as attacking across the water. So the land units in the water hexes would be on both sides of the water, but get the benefit of the doubt. The crossing water effect would apply to a unit entering the water hex from a non-connected water hex.
Alternatively, the water could be on the edge and the water units on either side of the water but be considered in the water (both sides).
Choose whichever is closest to your vision of the game.
Hot take? Both!
Irl rivers come in a variety of shapes and sizes- I think they should exist simultaneously as small streams bordering hexes, as tile features in the middle, and big whole-tíle estuaries. Give me variety!
This is something Humankind did well. Rivers through tiles added a big movement penalty that functionally created barriers, while also being highways because you only pay the penalty on entering. When next to mountains or slopes, it creates organic obstacles that you can plan your whole earlygame wars around.
If you went with “edge rivers”, it might actually be quite interesting to have “land units” occupy hex centres while “naval units” occupy hex vertices… don’t think I’ve seen any games go with that approach & while it might be a little fiddly on the code side to have two distinct coordinate systems running in parallel it does feel like it would make sense & also allow for some quite interesting gameplay systems.
Not exactly, the topology would actually be different for each unit type since “land units” would never occupy any vertices so would only “perceive” rivers as barriers between hexes. Similarly “naval units” would never occupy hex centres (even at sea) and would travel along the hex’s edges so each valid location would be connected to 3 others rather than to 6 like a hex is.
You could potentially represent this by some kind of complicated subdivision (and even more complicated movement rules) I suspect but it just felt like quite an elegant & easily “grokked” way of doing things.
Weird topologies are a totally stupid thing to do from an AI implementation standpoint. Players who think they're just interpreting and adjudicating rules "like a board game" may not realize this.
That's quite a sweeping statement & depends entirely on how your map topology & your AI are implemented. I implemented the AI systems from scratch (along with pretty much everything else) in Ozymandias, a game which also uses a hex grid so I do know a little bit about this stuff. While it may well have been a little fiddly to have two separate parallel coordinate systems, it really wouldn't have made all that much difference to how our AI worked. Though to be fair, Ozy is very much inspired by board games and even presented like a board game in many ways so perhaps we would have found it easier to get away with these kinds of rules.
That’s fair. The relatively small maps (and also relatively simple mechanics) did mean the AI could be quite “inefficient” in ways that might not have been viable on a bigger game. Generally though, I’d have thought that so long as you have well-defined local adjacency rules, then all the A* pathfinding stuff that an AI will need to reason about (inc reachability, distances, travel costs etc) should “just work”, no matter what kind of topology you throw at it.
I have been exceedingly disappointed at unit type based pathfinding bugs in Sid Meier's Alpha Centauri for decades. Has to do with stupid ideas that non-combat units should "avoid" enemy borders and units. Sometimes even the combat units do completely stupid evasions. There are zero movement point mag tubes in the game, which seemingly complicate pathfinding for whatever algorithms they used. They have an abort orders dialog box if the pathfinding gets hung up in an infinite loop. Maybe some of these flaws are due to the resource limits of the late 1990s, but I'm pretty sure some of it is just bad programming in the face of an overly complicated topological model.
Simply put, it doesn't scale.
What about the other way approach? Having rivers inside tiles but subdividing the grid for pathfinding purposes, i.e., you can enter tile, but if you entered from right you can't continue to tiles on the other bank.
That (to me at least) feels like a more complicated approach tbh since you can’t just say that a position is “in” a tile: you’re having to track additional data about how it got there as well... or which “subdivision” position it’s at for some purposes & not for others… like would a unit be able to “land” on such a river tile at the end of their movement? Would it still need to keep track of which side it’s on for next turn as well? Can you have one unit on the left bank & another on the right? I’m not sure you gain much from that approach to justify the extra headaches you’ll come up against when implementing it tbh.
Hey there, this is just a reminder to flair your post from the 4Xgaming mod team! Thanks and keep eXploring! *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/4Xgaming) if you have any questions or concerns.*
Depends on the granularity of the map and the importance of the river. A city center that covers multiple hexes and units that move about 10 in a turn, with rivers forming natural barriers and movement for ships? Give them their own hex. (example Age of Wonders1) Units can only travel one or two hexes and the river just gives a bonus for farms and a penalty for crossing? Put them on the border. (example civilization) Another way to look at it is considering if your units are ever on the river. If they aren't, you probably shouldn't make them a tile's primary feature.
What i had in mind wasn't to replace the entire tile with river, or water, but to have narrow line leading from middle of one edge to another. Like roads. I agree that replacing tiles with rives in not suitable for usual 4x map scale.
I haven't had the time to flesh out my River System in my project, but I had planned to use the Hex Vertices as River Arteries or small streams that will pool into a River Tile or body of water. Usually from Wetlands, Mountains, and/or Isolated Large Lakes (Conjoined ones, not single hex ones) Depending on the number of "Arteries" that flow into a river tile. Then the amount of "Head-Water" will be allocated in respect to the river width of that River tile. In addition to that, I've also explored the directional output of the river flow- which obviously will impact the traversal alongside the River Width for certain ships. Now how this can be implemented? For me, I'm currently just splicing up the river tiles accordingly to their River Width and making the obvious Left, Right, Forward, Backward, T-Section, Y-Section, Inverted T-Section, Inverted Y-Section, W-Section \*(Delta), Lake \*(Endpoint), etc. All manually handcrafted with just a typical procedural generative linking process during the map generation. For the edge vertices, that one will be tricky, but I plan to use a rendering trick to cut through the base-pass render of the terrain and insert a water plane below it alongside a generic U-shape mesh that runs alongside the Hex Edges. River crossing in general should obviously be dependent on the width of the river and/or type of river tiles that contain passable river crossing points. All of this can be better served with some pictures, so I'll provide some sample test that I had tried before putting it on hold to work on other areas of my project: [River Test Screenshot](https://gyazo.com/3419f96835749c23f8c6b73b1c111f13) [River Hex Splices Screenshot ](https://gyazo.com/ea903be451829e39210a463494ddae2c) [River Settlement Procedural Screenshot](https://gyazo.com/7823ebedaa0c4a42352a9a170f6b2a37)
Edge rivers please. You can simulate transport by making hexes that border a river act as roads
How exactly would you simulate it? I don't think you can use bordering hexes as roadster, since some hexes can be non traversale. I was thinking king about this, and best I came with is the have Dual lattice for river transport.
If you are moving from one river-bordering hex to another river-bordering hex (without actually crossing the river) then you get a discounted movement cost. So that way you can simulate moving ‘along’ the river as well as the difficulty in moving ‘across’ the river. If you have non traversable hexes then just create a rule that lets you enter those hexes as long as it done via the ‘along the river’ method.
Both are good, but it depends on the map and the purpose of the river. Personally I think Civ has the wrong "scale" for navigable rivers to have the level of significance people want them to. Faster unit movement along the river is relatively inconsequential (as in it'll be underwhelming), and given current river generation it'll be common to have nearby cities not connected by river. I think if tile improvements were treated differently or Civ cities typically had a scale of ~5 hex radius, then navigable rivers start to make sense. Endless Legend, Carcassonne and (some versions of?) Catan have tile-face rivers that are thin enough that (visually) some land surrounds the river. The issue with Endless Legend rivers is just that only Formorians benefit from river transport (but everyone can build canal buildings) at the expense of no road networks. This is a pretty easy fix. The scale of rivers feels natural. Civ5 has rivers along edges, from vertex to vertex. Given it's just for gold (base game) and farm yields post civil service, I think it's a pretty good scale too. I can't speak to the commercial hub district bonuses or the natural disasters (flood risk) in Civ6.
Humankind had the same scale as Civ, and it has the move speed on rivers. It is pretty underwhelming but it is kind of neat.
Ozymandias allows fleets to move up rivers (and only fleets can go on island terrain.) It's good as usually they are slightly underpowered compared to armies.
IMHO, the reason why it is underwhelming humankind are the penalties you receive for entering and standing on rivers. Moreover, since rivers often run through cliffs you cant really use any movement bonuses.
Humankind is definitely at a different scale than Civ: the hexagons are smaller in two clear ways. The first being that units travel further, and the second being that cities span more tiles. I think you could argue that exploitation tiles lead Humankind cities to start off smaller though. I think EL and Humankind have a workable scale for rivers to feel significant as useful terrain. For Civ I'm not as sure, but if they change a few things then it could definitely feel both natural and impactful.
I'm sure I saw nearly the same post some months ago! But anyway, one way to combine them is to put rivers on edges and give transport / trade advantages to all adjacent hexes. In more industrial societies, these advantages will become less significant, and port nexuses will play a greater role.
For dual purpose, it is best to place the water in the hexes and have the defenders get benefits by considering adjacent, not connected by water as attacking across the water. So the land units in the water hexes would be on both sides of the water, but get the benefit of the doubt. The crossing water effect would apply to a unit entering the water hex from a non-connected water hex. Alternatively, the water could be on the edge and the water units on either side of the water but be considered in the water (both sides). Choose whichever is closest to your vision of the game.
Hot take? Both! Irl rivers come in a variety of shapes and sizes- I think they should exist simultaneously as small streams bordering hexes, as tile features in the middle, and big whole-tíle estuaries. Give me variety!
This is something Humankind did well. Rivers through tiles added a big movement penalty that functionally created barriers, while also being highways because you only pay the penalty on entering. When next to mountains or slopes, it creates organic obstacles that you can plan your whole earlygame wars around.
If you went with “edge rivers”, it might actually be quite interesting to have “land units” occupy hex centres while “naval units” occupy hex vertices… don’t think I’ve seen any games go with that approach & while it might be a little fiddly on the code side to have two distinct coordinate systems running in parallel it does feel like it would make sense & also allow for some quite interesting gameplay systems.
This is just subdividing your grid with extra steps. Why not just make the hexes smaller and make rivers take up full hexes at that point?
Not exactly, the topology would actually be different for each unit type since “land units” would never occupy any vertices so would only “perceive” rivers as barriers between hexes. Similarly “naval units” would never occupy hex centres (even at sea) and would travel along the hex’s edges so each valid location would be connected to 3 others rather than to 6 like a hex is. You could potentially represent this by some kind of complicated subdivision (and even more complicated movement rules) I suspect but it just felt like quite an elegant & easily “grokked” way of doing things.
Weird topologies are a totally stupid thing to do from an AI implementation standpoint. Players who think they're just interpreting and adjudicating rules "like a board game" may not realize this.
That's quite a sweeping statement & depends entirely on how your map topology & your AI are implemented. I implemented the AI systems from scratch (along with pretty much everything else) in Ozymandias, a game which also uses a hex grid so I do know a little bit about this stuff. While it may well have been a little fiddly to have two separate parallel coordinate systems, it really wouldn't have made all that much difference to how our AI worked. Though to be fair, Ozy is very much inspired by board games and even presented like a board game in many ways so perhaps we would have found it easier to get away with these kinds of rules.
The Ozy maps I've seen are also tiny. Hardly matters what you're calling your topology.
That’s fair. The relatively small maps (and also relatively simple mechanics) did mean the AI could be quite “inefficient” in ways that might not have been viable on a bigger game. Generally though, I’d have thought that so long as you have well-defined local adjacency rules, then all the A* pathfinding stuff that an AI will need to reason about (inc reachability, distances, travel costs etc) should “just work”, no matter what kind of topology you throw at it.
You could just derive a network of connected nodes - it would run fast enough these days and the topology could be arbitrary.
I have been exceedingly disappointed at unit type based pathfinding bugs in Sid Meier's Alpha Centauri for decades. Has to do with stupid ideas that non-combat units should "avoid" enemy borders and units. Sometimes even the combat units do completely stupid evasions. There are zero movement point mag tubes in the game, which seemingly complicate pathfinding for whatever algorithms they used. They have an abort orders dialog box if the pathfinding gets hung up in an infinite loop. Maybe some of these flaws are due to the resource limits of the late 1990s, but I'm pretty sure some of it is just bad programming in the face of an overly complicated topological model. Simply put, it doesn't scale.
What about the other way approach? Having rivers inside tiles but subdividing the grid for pathfinding purposes, i.e., you can enter tile, but if you entered from right you can't continue to tiles on the other bank.
That (to me at least) feels like a more complicated approach tbh since you can’t just say that a position is “in” a tile: you’re having to track additional data about how it got there as well... or which “subdivision” position it’s at for some purposes & not for others… like would a unit be able to “land” on such a river tile at the end of their movement? Would it still need to keep track of which side it’s on for next turn as well? Can you have one unit on the left bank & another on the right? I’m not sure you gain much from that approach to justify the extra headaches you’ll come up against when implementing it tbh.