Solution: The Globe in Civ V, a really spherical map with only hexagonal tiles!

[orthoceros]

... Google Earth is just graphical coding and it doesn't even use discrete cells. Any guess on the development time for that one?

We are not starting from scratch to rebuild Google Earth. (besides: The most cost-intensive thing about Google Earth is the actual collection of real map data eiter by satellite or by photographs from aero planes, and then merging this raw data such that a borderless map of the full Earth is formed; merely displaying this data on a virtual sphere costed Google much less time&money.)
...but the point is: we are not starting from scratch: We already have a Civilization, which is able to display the cylindircal map in 3D and even warp it onto a sphere when you zoom out (remember the giant poles on the zoomed-out Civ4 Earth?). So, all graphical elements (projecting tiles onto the sphere, proper graphical blending on the tile borders, ...) are already there! The only missing thing on the graphical side is the algorithm, which tells the graphical engine, where to place the tiles onto the sphere, if the map is actually spherical and not cylindrical. As you now have a virtual cylinder being projected onto a sphere, you then would have a virtual octahedron being projected on a sphere. This is not too hard.
So, you asked for my educated guess on the additional total development time for a really spherical map, given a working Civilization engine with working cylindrical projection on a sphere as in Civ 4: less than 1/20 of the development time, which was needed to go from square tiles to hexagons! And this is a very conservative guess. What coding languages do you know and what experience do you have in programming, btw.?

This can wait for civ, say, XII ...

This is your personal opinion. No need to say, I don't share it. Regarding the strategical depth (ranging from alternative shorter see/trade routes e.g. Europe/South Asia to the Cold War and its strategic missles, ...), and in order to read opinions of other forum members on this topic, I suggest you do a forum search; you will find numerous posts about it; and your opinion is obviously not that of the majority.

One point you seem to totally ignore is realism! Did you ever see a cylinder- or even toroid(donut)-shaped planet out there? No. Does the Civ series try to incorporate important things of reality and the human history? Yes. Do you remember, why the (much harder) development effort for the transition from square tiles to hexagonal tiles has been undertaken? Right: More accuracy for distances on the map, no more diagonal crossing of vertices and associated sqrt(2)-shortcuts; in short: more realism!

Do you earnestly think that such a huge step forward towards more realism should be simply postponed to eternity and practically omitted, especially now that we already have nearly everything needed for it? Do you want to give up this short before the goal? Are you really happy to play on cylinder or donut planets up to Civ 11, as you suggest in your post?? Did you know that the Civ series always also had an educational ambition, which is totally incompatible to the aforementioned unrealistic "concepts" of a planet? Sid Meier most certainly used these concepts back then, only because nothing better was possible with the then-time computers. Now the technology is more than ready for a spherical Earth map.
No; this step towards a real planet is due by the release date of Civ V! I already expected it in Civ IV, back then when I did'nt know anything about sphere tesselation and read the "third dimension" advertising. At the latest, it is due by the release date of the first Civ V Expansion Pack. No later!

 

[frekk]

We already have a Civilization, which is able to display the cylindircal map in 3D and even warp it onto a sphere when you zoom out (remember the giant poles on the zoomed-out Civ4 Earth?).

Yeah but that's a long way from a globe. All it is, is a 2d map projected onto a simple ring or band, and a couple of poles stuck on top. It's NOT projected onto a sphere. It's projected onto a band, which is much, much easier.

The main problem is the unavoidable artifacts. Or pentagons, under the other style of projection. Evenly distributed all over the map will be these strange flaws. 12, I think. Realism is important, but lots of people - especially consumers who aren't diehard civ fans - will balk at having glaring graphic flaws on their maps. Even with the grid off, it's going to look funny there, with terrain forms overlapping. A mountain partially obscured by ocean, and what have you.

 

[Atrebates]

Yeah but that's a long way from a globe. All it is, is a 2d map projected onto a simple ring or band, and a couple of poles stuck on top. It's NOT projected onto a sphere. It's projected onto a band, which is much, much easier.

The main problem is the unavoidable artifacts.

Um, yes... There's a lot of discussion about this earlier in the thread.

I think the point about what to do with the overlapping graphics at the vertices is a good one mind you.

 

[orthoceros]

Let me explain at bit... First, one has to differentiate between the projection and the type of base geometry:

The projection onto the sphere itself is always a point transformation: For example, given a sphere and a cylinder with equal centers: Then draw a line from the common center through the point on the cylinder band, which should be projected. The point, where this line intersects the sphere's surface will become the point after the projection. Its as simple as that. In the case of the cylinder, its length relative to the sphere's diameter determines how near the projected tiles will come to the two poles. The very same step is also performed, if you want to project an octahedron or icosahedron onto the sphere. Since both are topologically compatible to the sphere, the initial size ratio does not matter here.
Granted: There is an additional point transformation, which I used in case of the octahedron projection to give all tiles roughly the same area after the projection, but it is not hard to compute / can be done in the same step as the regular spherical projection. Also, for the cylinder band there is no local transformation, which could equalize the tile area, because of the topological incompatiblity. The only thing you can do in this case, is to keep away from the two poles (by setting the initial cylinder length << the target sphere's diameter before the projection and introducting giant impassable icy poles; more details follow).


The base geometry determines the types of artifacts you will have after the projection:

• base geometry = icosahedron:
  • topologically compatible with the sphere
  • main artifacts: at 12 locations around the globe (at 120° angle to each other) there will be pentagons instead of hexagons
  • thus, most tiles have six neighbours, but 12 have only five neighbouring tiles
  • nearly no discrepancy between real distance and tile distance for any circle on the sphere's surface
  • the gameplay at these locations is strongly affected: One tile less to defend against, different movement controls/directions needed for units on these tiles and a negative effect on the tiles within the city radius (5+10 instead of 6+12 workable tiles).
  • players are not familiar with these artefacts
  • no overlapping tiles
• base geometry = cylinder band:
  • topologically incompatible to the sphere
  • main artefacts:
    • The top, center and bottom circles of the cylinder band have equal number of tiles, but not equal real-distance onto the sphere after projection. Therefore the tile area for the top and bottom rows is less than the area of equator tiles.
    • To prevent this going to extremes (e.g. 200 tiles around the equator and 200 tiles around a small circle around the North Pole), one purposely introduces giant impassable icy poles as in Civ IV (as large as North America or larger, which is very unrealistic).
  • as explained, there is an extreme discrepancy between real distance and tile distance for the latitudes
  • a lot of hexagons (all hexagons on the top and bottom circle of the cylinder band) only have four neighbouring tiles instead of six
  • the gameplay is severly affected at the artifact locations: Two tiles less to defend against, if a unit stands on a border tile. If not for special reasons, nobody would like to build a city there, because it would only have 4+7 of the usually available 6+12 workable tiles.)
  • players are familiar with these artefacts
  • no overlapping tiles
• base geometry = octahedron:
  • topologically compatible with the sphere
  • main artifacts: at 6 locations around the globe (at the North and South Pole and at 4 equidistant locations around the equator) there will be four overlapping hexagons as depicted in the images earlier in this thread
  • nearly no discrepancy between real distance and tile distance for any circle on the sphere's surface
  • all tiles have six neighboring tiles
  • the gameplay at these locations is least affected of all three solutions discussed: Cities would only have 6+10 instead of 6+12 workable tiles.
  • players are not familiar with these artefacts, but could adapt easily because of the weak effects on the gameplay and because the movement controls are the same for all tiles.
  • some overlapping tiles

As you can see, the artifacts of the cylinder band base geomentry are even the worst. It is just an effect of familiarization that this does not feel weird while playing.

==================

From a development perspective there are also two distinct steps:

1. change the base geometry in the game engine: use a set of two coordinates compatible for the new base geometry and generalize the distance(tile1,tile2) and the pathfinding algorithms as discussed above
2. update the graphics engine: projection (point transformation) of the base geomentry as explained above; special rendering approach in case of overlapping tiles (see below).

About

...having glaring graphic flaws on their maps. Even with the grid off, it's going to look funny there, with terrain forms overlapping. A mountain partially obscured by ocean, and what have you.

With the grid off, there is no need for any visible artifacts: I see two ways to prevent them:

• the quick (and a bit dirty) way: Just use the graphical blending already built-in. (Look e.g. at the farms in the CiV screenshots, where they blend into the terrain, if you leave the tile with the improvement.) Since the tile overlap is only a fraction of the tile area, this terrain-terrain blending would work without too noticeable optical artifacts.
• the perfect way: You can easily replace each group of four overlapping hexagons by a group of four non-overlapping pentagons (just draw four lines from the center of the pole, one in the middle of each overlap region). This is not useful from a gameplay perspective, but you could use this for clipping and overlap-free rendering of the terrain, if it is needed.

 

[frekk]

It is just an effect of familiarization that this does not feel weird while playing.

"Just"? If most players don't perceive the artifacts of a cylinder wrap as odd at all, it's hardly some minor thing. Perception is everything, so this is not a minor problem. It is a major problem for spherical projection.

The artifacts also have an important difference. The polar caps are located at the edges of the map. The artifacts introduced in a sphere projection are evenly scattered all over the map, and will often be smack dab in the middle of the action. This is a huge qualitative difference, making the spherical artifacts much more present in the game.

 

[orthoceros]

I assume you have read and understood my previous explanations and agree with them by not reissuing your older complaints. This is a step forward. So, lets continue to your next argument:

It is just an effect of familiarization that this does not feel weird while playing.

"Just"? If most players don't perceive the artifacts of a cylinder wrap as odd at all, it's hardly some minor thing. Perception is everything, so this is not a minor problem. It is a major problem for spherical projection.

Four points you should consider:

• The familiarization with square tiles was/is complete in the Civ community. Nevertheless, the step to hexagonal tiles has been undertaken, and for good reasons. Players will adapt fast.
• I remember, when I first zoomed out to globe view in Civ IV, I was shocked by the unrealistic look of these giant polar regions. I was also disappointed that I could not cross the poles, because I expected this after all the advertisement of "Civilization going 3D" back then. I ignore these artefacts while playing, of course, but so could I ignore the overlap of some tiles, since the overlap does not change the game mechanics, which is the important point in my opinion.
• Civ will certainly not dispose of cylindrical and toroidal maps; there is no need to, since they already work; and why should you remove a working feature. For some scenarios it is even more realistic, if you play on a 2D map with borders.
• The spherical map would be another option, which realistically allows for playing on planets. Since a planet's surface is of borderless nature, you cannot expect to group all artifacts at some map border, because there is none. I don't think it is necessary, but as shown previously, you could even place the six artifacts all in ice regions (North and South Pole of the planet) or in oceans (the four locations around the equator).
  If you don't like this, you can always opt for a cylindrical base geometry, but let other players make their choice. Please don't diffame a feature, which many players want (and even more will actively use, once it is available, I forecast...).

 

[sammual]

Orthoceros,
What 3D program are you using for your Globe?

How are you projecting the hex grid onto it?

Thanks,
Sammual

 

[orthoceros]

I recommend Cinema 4D (http://www.maxon.net/products.html). If you are a student, there is also a relatively cheap license available (of course, you may not distribute or use your results commercially...).
About the projection: Have you read my explanations above? There are two steps involved: First define an octahedron base geometry (with a polygon mesh consisting only of hexagons, starting with one triangle-shaped plane of hexagons and then connecting copies of it). Then use a spherify deformer, which projects your octahedron onto the surface of a sphere. Now you are already there, but the tiles are not yet of roughly equal area. I played around a bit with formula-based deformers and finally found a combination of three perpendicularly arranged cylindrical deformers to compensate; the remaining tile area variations are not too large, but noticeable (see images on the first page of this thread). These are the main steps; for more details, see my earlier posts.

 

[sammual]

Orthoceros,
Could you unwrap your octahedron hex grid like THIS and post it here for me?
Could you also post a screenshot where the camera is equidistant from the three closest artifacts without shading? (Like your "circles triangle intersection view" without the circle and triangle shading)
I believe that if you only displayed the hex grid from where the camera is pointing, out to the last hex row before it is adjacent to an artifact you would not notice any artifacts as long as when you rotated the globe you did not move the mesh, just rotated the texture in 1 hex increments.

Sammual

 

[orthoceros]

Hello Sammual. That is an interesting link. I will try to produce the suggested renderings, but it will have to wait until next weekend...
I am not sure, if I understand your second point correctly: If I try to imagine your "1-hex-rotation-increments" it would cause the Earth to rotate (underneath the constant grid overlay) in 90° steps, because else I would get a problem with ambigous unit positions, especially near the poles around which I am rotating (e.g. the North Pole). Could you elaborate this point?

 

[sammual]

Any tile based map system needs to have a co-ords system setup so we know what tiles are adjecent, where on screen they should be displayed, and what movement is allowed.

You can setup the co-ords system using a flat hex grid and then project this onto your Octahedron based Sphere. If you lock the camera to point at only the center of one of the flat faces of the Octahedron and only display the Hex Grid out to where it touches the edge of that face you can ignore the artifacts at the 'points' of the Octahedron as they will be LOD and texture blended away.

-- See attaxhed Image --

To keep the Mesh artifacts out of view we will not move the Octahedron based Sphere or camera but instead the texture(s) on the Mesh. Movement would be in 1 hex steps (In any of the 6 directions), unit and other posistions would not be effected as they are using the 2D Hex grid co-ords system and all we have done is changed what hex is being displayed in the center of our view (And all other hexes are located from that one).

I will not have the chance to do a 2D Hex grid co-ords system --> the Octahedron 'Butterfly' hex grid (Like the attached image) that will be projected onto the Octahedron based Sphere for a few weeks but I hope you can see where I am going with this.

Sammual

 

[orthoceros]

First of all, here ist the largest field of view, where you cannot see overlapping fields directly:

I understand your approach: Show a constant grid overlay and replace the usual rotation method by shifting the terrain and units (and whatever else) of every tile in one of the six local directions available. This is a good idea and locally this seems to be possible everywhere, since every tile has six neighbours.
Globally I see some problems nonetheless: You will never find a numbering (1..6) of neighbouring tiles for every tile such that if you "rotate in neighbour direction 1" every tile will move parallely. Else you would have invented a contradiction to the Hairy ball theorem, wouldn't you?. (Define the vector field with all the local tile content movement arrows.) I think if you would rotate the Earth by your method e.g. two times round (720°) along "neighbour direction 1", you would end up with a distorted map, because the continents are not shifted parallely on the sphere's surface everywhere and errors would accumulate over the rotation.
I hope I err on this, because if your idea works, then this would indeed be a very good way to prevent players from facing artifacts directly! Even the price of "maximum zoom out" could be circumvented: just hide the grid, if you zoom out more than in the above picture (as in Civ 4's global view mode).

About the octahedron net view image: Unfortunately I did not save all construction steps of the polygon mesh. I would have to start over to create the net view; or I had to cut the final polygon mesh and project it onto a plane... I cannot promise that I will do this on Easter.

 

[sammual]

I understand your approach: Show a constant grid overlay and replace the usual rotation method by shifting the terrain and units (and whatever else) of every tile in one of the six local directions available. This is a good idea and locally this seems to be possible everywhere, since every tile has six neighbours.

Globally I see some problems nonetheless: You will never find a numbering (1..6) of neighbouring tiles for every tile such that if you "rotate in neighbour direction 1" every tile will move parallely. Else you would have invented a contradiction to the Hairy ball theorem, wouldn't you?.

If we were mapping a true sphere with no distortion I believe you would be correct.

I got interested in this in 2007 when I came across The Hex mapped Sphere. I was in the process of writing the world generation for my Hex Tile MoM clone and loved the idea of being able to play the game on a true globe (Not the unwrapped cylinder I was using). It turns out that the distortion from a plain to a sphere makes 3D artwork unusable, You also run out of room for 2D artwork in the Hexes further away from the hex the camera is directly pointed at. To make things look good I had to zoom in far enough that it was no longer apparent that I was playing on a sphere. At this point I moved back to a plain and over the next 3 years I have moved back to a cylinder as did not find my sphere approximation to add anything worth the headache of needing to store the neighbors of each hex in an array.

Sammual

 

[snipperrabbit!!]

How many hexes are seeded on your map, Orthoceros, please ?

 

[Thormodr]

Great work Orthoceros. I have been waiting for a realistic map for Civ or really any game for a long time. This looks quite promising.

I agree that this could be a big selling point for Firaxis if they can pull this off.

 

[orthoceros]

@Sammual: I started over and constructed a low res mini version of my ansatz, which shows the principles of construction and allowed me to render the butterfly net for you. The faces of the four overlapping hexagons at each of the six poles are colored so that it should be easy to identify matching tiles.

• First the octahedron view:
  
  
• It follows the butterfly net of it (I purposely did not melt the corresponding polygons, because this would have partially hidden what happens with the overlapping hexagons.)
  
  
  I still don't think your idea of "rotating in 1-hex-steps" is possible, but I would be gladly incorrect (this time ).
• For reference, here is the spherified version of the mini version (projected onto a sphere and then deformed such that all tiles get roughly equal area):
  
  

About your artwork projection problems back then: Why did the following approach not work for you (for non-overlapping hexagons in 3D space)?:

• Given 2D art work (e.g. a terrain texture), which works for 2D hexagonal maps. (For example the triangle-based terrain types shown in the white paper from your link.) To reuse it for the spherical hexagonal map, first tell Direct3D/OpenGL where all 2D hexagons of the sphere's surface are placed in 3D space and then let it simply render the same texture on them: If the texture overlap is not large enough to compensate for the tile area differences (or if there would be clipping artifacts), rescale the texture to match the target hexagon's borders. That there will be less pixels available for tiles further away from the camera should not be a problem at all now: You will only see the parts of the properly-rotated 2D terrain texture you can actually see from camera perspective; this is intended for a 3D scenery, isn't it?
  The same steps can also be used for 3D terrain art work: You just have to replace the Z axis used for the flat map by the normal vector of the hexagon on the sphere's surface.
• Given a 3D artwork for a unit or a building: First calculate the center of the target hexagon in 3D space and reposition the model acordingly. Then rotate it such that the model's z-axis again matches the normal vector of the tile. Maybe rotate again such that the "front" of your model points in the direction of the camera (for units, not for builings, of course).

Or were your problems related to the fact that the tesselation shown at the link you posted included some pentagons instead of hexagons? (This could certainly cause mismatches that look like clipping errors at the tile borders...)
Btw: MoM==Master of Magic? I remember that one! It was one of my favorites when I was young.

===
@snipperrabbit!!: The map from the beginning of the thread has 12096 hexagons. The mini version above has 60 hexagons.
If n is the number of desired tiles along a 90°-arc from one pole to the next, then possible tile numbers are sum(i, i=1..n)*8+n*4.
All n>=1 should be possible, but for n=1 and n=2 the map would probably look ugly (the mini version above is for n=3). For a Civ game, n should be greater than at least 50, I would say.

====
@Thormodr: Thank you.

 

[civ_king]

impressive

 

[snipperrabbit!!]

Thank you very much for your answer, Orthoceros !
I'm glad you provided the formula as well. I pondered it and I think the range from n=26 to n=125 is the right target. The former allow for a dual type map where 2 civs can build about 15 cities each not counting city-states. I agree it will not look like earth but still a quick game never hurt. The later provides room for 34 civs (cf. civ4bts) ruling roughly the same number of cities as above.

Also, the overlapping percentage range from 0.824% to 0.038%.
At this point, I think it's better to make them unpassable (ie. take them out of a pathfinding algorithm) even if it seems unelegant. I mean who cares if i pass just left from the pole or the atlantic equatorial orthoceros point.

For the coordinates, is it easy to have multiple arrays which can traslate into each other ? ... I mean I give flat coordinates for each hexagon who is part of an equilateral triangle and the hexagon at the edge of triangle 1 (1;27;39) = (2;27;1) the same hexagon appearing to be at the edge of triangle 2 as well ; and finally, also equaling relevant spherical coordinates like [46°N 17°E] considering there the hexagon center.

 

[orthoceros]

@snipperrabbit!!:
I think your window [25..125] for n makes sense. I would not exclude the overlapping tiles from path finding though, because the resulting tile paths for real paths, which cross a pole, would be at least one tile longer than necessary, which can make a noticeable strategic difference even on a large map, if you are playing near a pole.
Regarding the coordinate systems, your proposal (#triangle=1..8, 1..n, 1..n) is certainly doable, but I would prefer a coordinate system, which has only two coordinates, because the surface of the 3-sphere is two-dimensional. One possible solution might be the following adaption of the usual (theta,phi) spherical coordinates:

• tileTheta := -n..-1,0,1..n, where zero means the equator.
• tilePhi := 1..(n-|tileTheta|+1)*4 for all rings except the equator and tilePhi := 1..n*4 for the equator.

For the mini version above this would result in the following 2D coordinates map:

tilePhi:
##----------##----------##----------##---------- | tileTheta:
01----------02----------03----------04---------- | +3
01--02------03--04------05--06------07--08------ | +2
01--02--03--04--05--06--07--08--09--10--11--12-- | +1
##01--02--03##04--05--06##07--08--09##10--11--12 | 0
01--02--03--04--05--06--07--08--09--10--11--12-- | -1
01--02------03--04------05--06------07--08------ | -2
01----------02----------03----------04---------- | -3
##----------##----------##----------##---------- |
All fields with "--" in-between are connected horizontally. All fields with "##" in-between are connected horizontally and vertically. All rows are rings, i.e. left-right-connected. The first and last row only indicate that you can go from any of the four polar fields in the respective row to any other, but no column is top-down connected.
All fields being placed directly above/below one another are implicitly connected. There are also implicit diagonal connections to the neighbouring fields one row above or below, but only where the diagonal line projected onto the current row does not "jump over" a field (cf. the rendered images above to see why). With these rules, you can always identify the six neighbours for every field in this 2D representation.
​

Now we would need a formula for tileDistance((tileTheta1, tilePhi1), (tileTheta2, tilePhi2)) to continue towards a pathfinding algo...

@civ_king: Thanks.

 

[Kyarao]

Now we would need a formula for tileDistance((tileTheta1, tilePhi1), (tileTheta2, tilePhi2)) to continue towards a pathfinding algo...

Arc length calculations spring to mind immediately. 2 calculations would be required: The first would find the arc length between the theta ordinates of the tiles, the second would find the length between the phi ordinates of the tiles.

The angle between the two tiles ordinates can be found with trigonometry. If I remember my maths right, the angle between theta ordinates would be:

angle = abs(sin^-1((theta1-theta2)/radius))

then the distance between theta ordinates would be:

length = angle*radius

I hope I got my maths right! if it is, doing that calculation twice could be used to determine the length between two tiles.