Shallow Water / Reefs / Stone Coast / Streams [IMPLEMENTED]

[ConjurerDragon]

Spoiler :

 

[Tugboatspotter]

Spoiler :

View attachment 600159

As I said earlier "They don't change much and so the effects should already be baked in to travel ie shorter travel times in one direction than the other."

We already know these currents were understood long ago.

 

[raystuttgart]

... the effects should already be baked in to travel ...

The part of the Gulf Stream that is "out of the map", yes.
And we will reflect it in the Travel System. (There is a whole concept thread for it.)

But what about the part of the Gulf Stream that is "still on the map"?
For that part I want to experiment and create the "Streams" feature.

And if I am correct it will not even be that hard to create something like that.
If community however considers it a pointless and boring feature I do not necessarily have to do it.

 

[ConjurerDragon]

The part of the Gulf Stream that is "out of the map", yes.
And we will reflect it in the Travel System. (There is a whole concept thread for it.)

But what about the part of the Gulf Stream that is "still on the map"?
For that part I want to experiment and create the "Streams" feature.

And if I am correct it will not even be that hard to create something like that.
If community however considers it a pointless and boring feature I do not necessarily have to do it.

From a point of realism and historical accuracy I say go for it.
We can´t stress enough just how dependant shipping in the age of sail was from the weather, currents in the ocean and almost regular trade winds to get where they wanted faster.

And that some places were "closer" (in terms of days to sail there) than other places that were actually closer (in terms of miles distant) because of the circumstances in sailing there.

Anyone at that time ignorant of these (like the first who would explore the area) would sail around for easily more than twice the time than someone actively using the systems.
https://en.wikipedia.org/wiki/Humboldt_Current#/media/File:Tropical_cyclones_1945_2006.png
https://en.wikipedia.org/wiki/Trade_winds
https://en.wikipedia.org/wiki/Humboldt_Current
a map by Benjamin Franklin of the gulf stream to get to Europe faster and the dangerous sandbanks at the US eastern sea board at that time:

 

[raystuttgart]

From a point of realism and historical accuracy I say go for it.

I do not create features just for immersion and historical accuracy.
I try to consider that in my feature design though.

I also create them for gameplay and balance.

1. I consider it to be interesting / fun to be able to consider theses "fast lanes" in my gameplay. (e.g. where I settle or how I sail.)
2. Settling in the Gulf of Mexico is on some maps a really bad strategical decision due to distance to Europe Plots and these streams could balance that out.

It may not be the coolest feature of all times.
But I do believe it has at least a little potential.

 

[raystuttgart]

Thanks, I will use that map when I try to adjust the existing maps.

 

[raystuttgart]

Now I just need to find a graphical modder to create "Streams" using Road graphics.
(Because really the best way to technically implement it is using Roads System under the hood.)

Without these graphics I will not start to create it ...
(Because I first want to be sure it is looking good.)

 

[ConjurerDragon]

Ftg ("For the Glory", an improved variant of Europa Universalis II) used markers like these for the streams it added:

Spoiler :

Closer look to the gulf stream:

Spoiler :

It practically was just a compass rose with an arrow in the direction of the stream. Practical that meant sailing in the direction of the arrow was faster, against the arrow slower. In FtG the ocean provinces were then named accordingly, e.g. here Gulf Stream. The other one added was the Antilles Stream which is part of the North Equatorial Current

Spoiler :

 

[raystuttgart]

@ConjurerDragon

I can not do "directions" e.g. East-West.
(For reasons of performance and techical issues in pathfinding algorithms.)

I can only do "faster" without caring about the direction.
(Just like Roads currently also do.)

It may not be perfect yet, but it is a start.
At some point we may find a solution to also have "directions" ...

So any "East-West-Stream" would also be an "West-East-Stream" in the game.
(I can only model in pairs. "North/South == South/North" and "East/West == West/East".)

Civ4Col and also WTP simply do not know "directions" in movement.
And every way I would implement it would ruin preformance because pathfinding algorithms would compute themselves to death ...

----

Summary:

I can offer an "easy" to implement, easy to understand by players and performant solution using "Road System" under the hood.
If community however expects a more complex and realistic system really knowing "directions" I can not do that without ruining performance ...

 

[orlanth]

That sounds like a worthwhile feature, and it's true it doesn't seem very feasible to mod movement advantage directionally.

FYI as a language note, in modern English usage the word "stream" when used for bodies of water usually refers to a very small brook (Bach) or small tributary of an inland river. The intended meaning of directional water flow in an ocean would more usually be called a "current", or sometimes "gyre" if describing a circular flow.

The name of the Gulf Stream current does include the word stream but it looks like that is the only one to do so (I'm not sure why that is!)
https://en.wikipedia.org/wiki/Ocean_current

 

[raystuttgart]

Hi guys,

here you see first screenshots of the "Streams Prototype".
(It is still "Work in Progress" - I have done little more than configuring the graphics and thinking about a technical concept.)

Credits for graphics:
Ancient Europe Mod of @pie_at

@f1rpo , @Nightinggale , @devolution

I am planning to bring "directed movement (bonusses)" in this game.
Any good ideas how this could be implemented in a performant way?
(Will not give up on this before even having tried.)

 

[f1rpo]

I am planning to bring "directed movement (bonusses)" in this game.
Any good ideas how this could be implemented in a performant way?

It should suffice to modify CvPlot.cpp::movementCost. I don't think that's a major bottleneck, so I don't see a real problem with performance; perhaps I'm missing something. The function that checks whether movement between two tiles is allowed at all is called far more frequently; at least that's been my experience with the KmodPathFinder class that devolution has ported to WtP – the pathfinder in the EXE may well behave differently. For reference, the calls in question happen in this loop: KmodPathFinder:: ProcessNode – pathValid_join (only checks for isthmuses; all the other movement checks depend only on the destination tile and are handled by ... pathValid_source, somewhat counterintuitively) and pathCost (which calls CvPlot::movementCost).

 

[raystuttgart]

@f1rpo
Thanks.

Was just afraid that it would mess up performance a bit.
But I think I could implement in a quite performant way.

The Stream feature is now ready to go.
This is so damn fun to play with this !

Straight Movement - without Stream:

Straight Movement - with Stream:

Mix of Straight / Diagonal Movement - following Stream:

 

[Nightinggale]

Any good ideas how this could be implemented in a performant way?

You can measure the performance impact if you like. At the start of what you want to measure, tell that you want to profile, like this:

int CvPlot.cpp::movementCost()
{
    MOD_PROFILE("CvPlot.cpp::movementCost");

I added MOD_PROFILE and it takes a time stamp when the execution passes this line. It takes one again automatically when it goes out of scope (in this case hit return). If you select Profile (from debug/release etc) it will generate a txt file in the root dir of the mod telling how many times the function was called, how much CPU time it used in total and on average for each call. If the DLL isn't compiled as Profile, this line will be ignored.

The numbers are relative as in you can compare against a different run on the same computer. However a different computer with a different CPU will produce different numbers.

Do note that switching to Profile will turn on all optimization and it can easily take 5-7 times longer than compiling a Release DLL. That's normal and it makes sense to test on the same level of optimization as we use for the releases.

 

[f1rpo]

Looks pretty cool in the screenshot. The original developers (Col and Vanilla Civ 4) really missed opportunities when it comes to water features. Well, I guess they were counting on modders.

In theory, the pathfinder could perhaps take advantage of path costs being symmetrical when it comes to reusing intermediate results from earlier A* searches. Well, the KmodPathFinder doesn't do that, and I can't think of other ways how asymmetrical path costs could indirectly affect performance. So it's hopefully enough to consider the local effect on performance. Maybe best not to worry about that until the "pathfinder" branch has been merged – that might decrease the number of calls to movementCost substantially.

If the code needs to be optimized, then my idea would be to take advantage of the DirectionTypes enum being in clockwise order:

Spoiler :

enum DirectionTypes
{
   NO_DIRECTION = -1,
   DIRECTION_NORTH,
   DIRECTION_NORTHEAST,
   DIRECTION_EAST,
   DIRECTION_SOUTHEAST,
   DIRECTION_SOUTH,
   DIRECTION_SOUTHWEST,
   DIRECTION_WEST,
   DIRECTION_NORTHWEST,
   NUM_DIRECTION_TYPES,
   // ...
};

If one wraps around at the end, then the difference between directions that are similar enough for a speed-up is 0 or 1. So one could, instead of (or as an alternative to) the 8 boolean tags, use a single tag like this

<ApproxMoveDir>DIRECTION_NORTH</ApproxMoveDir>​

("Approx" is supposed to mean that the direction only needs to be matched approximately) and then check

if (abs(from.getDirection() - to.getDirection()) % (NUM_DIRECTION_TYPES - 1) <= 1)​

in the movementCost function.

 

[raystuttgart]

Well ok guys, seems WTP is the first Civ4Col mod that has "Movement Costs" depending on directions.