Agamemnus
Warlord
I thought I could post this here since Firaxis doesn't seem to read their emails at all. (I sent one email on the 20th of this month and another one, about map generation, a few months ago.. it was mostly about a program I had written)
1) Suggestion
It just might be, although I do not know this for sure, that the slow loading and turn moving is associated with pathfinding.
Let me venture to guess that your current pathfinding routine involves checking for do-able paths a certain distance from a straight line between the two points? Well whatever it is, here's my suggestion:
It would be simple to find the shortest path if there were only 3 types of squares:
1) 1 movement point value squares.
2) 2 movement point value squares.
3) 0 movement point value squares (water, mountain, jungle, forest)
Then you could just search for the shortest path, extending in both sides in an arc if the path was not crosseable. (then if it is, get some more paths and use the shortest one)
It gets more complicated [er.. slower] when there are more units and/or ROADS and RAILROADS and SHIPS!!!
What I suggest is creating (once per world map knoweledge change) a different map that is based on easy movement, not a square map 'as is'..
This new map could be like a hill: ease of movement across regions can be defined as slopes on different sections of the hill. Rails could be defined as plains.
Unaccessible terrain could be defined as ridges or water.
Obviously you'd need different maps for:
1) ships
2) restricted movement vehicles such as chariots, catapults, etc.
The hill map could then be stretched or 'fudged' (like the earth is fudged on a square, 2-d, map) to make it a 2-dimensional map, and then the map could be used to find a path as described earlier.
It is also possible to create 3-d shortest path algorithms. (such as a line is, in the simplest form, y = mx + b) However, I think the stretch approach would take less time to compute.
2) Minor Bug
When a city is captured the tile from where the capturing unit came from becomes temporarily blank (visibly).
1) Suggestion
It just might be, although I do not know this for sure, that the slow loading and turn moving is associated with pathfinding.
Let me venture to guess that your current pathfinding routine involves checking for do-able paths a certain distance from a straight line between the two points? Well whatever it is, here's my suggestion:
It would be simple to find the shortest path if there were only 3 types of squares:
1) 1 movement point value squares.
2) 2 movement point value squares.
3) 0 movement point value squares (water, mountain, jungle, forest)
Then you could just search for the shortest path, extending in both sides in an arc if the path was not crosseable. (then if it is, get some more paths and use the shortest one)
It gets more complicated [er.. slower] when there are more units and/or ROADS and RAILROADS and SHIPS!!!
What I suggest is creating (once per world map knoweledge change) a different map that is based on easy movement, not a square map 'as is'..
This new map could be like a hill: ease of movement across regions can be defined as slopes on different sections of the hill. Rails could be defined as plains.
Unaccessible terrain could be defined as ridges or water. Obviously you'd need different maps for:
1) ships
2) restricted movement vehicles such as chariots, catapults, etc.
The hill map could then be stretched or 'fudged' (like the earth is fudged on a square, 2-d, map) to make it a 2-dimensional map, and then the map could be used to find a path as described earlier.
It is also possible to create 3-d shortest path algorithms. (such as a line is, in the simplest form, y = mx + b) However, I think the stretch approach would take less time to compute.
2) Minor Bug
When a city is captured the tile from where the capturing unit came from becomes temporarily blank (visibly).
Thoughts?
) has to be in redrawing the graphics. I'm sure that the path finding algorithm execution takes milliseconds. 
