The Earth is round!!!!!! (maybe...)

Status
Not open for further replies.
Couldn't Firaxis just take a short cut and make it so when you head over the poles on the Mercator projection you show up half way across the board on the same edge. This is in effect what is happening when you go over the poles.

They could combine this with a "pregnant" map so the east to west distances would be shorter at the north and south edges as opposed to the equator all while avoiding actually capping the map providing us (the players) with a globe simulation.

*edit*

While avoiding having to use cumbersome, ugly and un-balancing pentagons

I was told to move this here, i don't know if its already been said
 
While that would work, I don't think it will gather much support. It does address the fact that travelling across the poles takes a shorter distance but it doesn't make the world look any more round (no immersion) and it is still fairly clumsy. You can't easily show that sort of thing on a minimap. Pathfinding algorithms become more complicated if you expect them to take advantage of the changed topology.

However it probably wouldn't be all that difficult to mod (just a guess though) so in that sense it's a fairly realistic suggestion.

What would happen if you, for example, settled a city right near the south pole. Would it's BFC stretch to that other point on the map? That would at least look a bit odd.
 
I don't think that culture would be trans-polar

I do think that it addresses game-play though even if immersion is put on hold, there are just to many issues with playing on a sphere as far as i can tell.
 
I think Wodans solution is actually one of the best ways to go if the game was to use spherical maps. By centering map on the current unit and making nearby hexes that he can move to the same size / similar in size, while far off hexes on the horizion are smaller in size would represent the map very realistically. The issue of rounding a unit that moves beyond the same / similar size tiles to the smaller size tiles would take into account his starting hex, and his movement points would be reduced in decimal length compared to his starting hex.

So Tank A starts on a hex, and has 5 movement points. Under the hood his movement points go from
move # - Movement points left (numbers off the top of my head, not scientific)
1 - 4
2 - 2.998
3 - 1.996
4 - .993
5 - 0

At the end of his movement he is assigned to a new global hex, and the next turn the process starts again for him.

So for the map as a whole it's just matter of determining the total circumference of the world and adjusting the relative movement points and rounding values for the game and creating global hex grid to overlay on that map.

To avoid the needed octagonal tiles there would have to be a fixed unit move maximum based on the circumference of the map. It would be pretty large I imagine though. Displaying the map on a zoomed out view would take some programming finesse to make it look right, such as inserting the octagons when zoomed really far out, but only using them for display purposes.
But what if you move the unit one tile at a time? That has to give the same result as moving several tiles at once.
 
Well, that is not exactly a hex grid.
It would have special rules for some tiles. To illustrate...


If you own the white unit, and the red and pink units are enemies, the white unit can attack the pink unit despite the fact the 2 red units should be blocking.
From the point of view of the white tile, the red tiles are not adjacent, and should therefore not block it. From the point of view of the red tiles, they are adjacent, and therefore should.

The other problem with the projection is that while the number of tiles 1 tile away is made to always be 6, the number of tiles two squares away is sometimes 10 instead of 12.
 
How so? Especially in context of this? Every tile in those images has exactly 6 neighbors.

That solution is not locally a hex-grid. In fact it is not even a grid of hexes. The four tiles around a special point are pentagons (at least from a gameplay persepective) meeting in a single vertex, where diagonal moves are allowed.

But I should have been more careful about my statement. I'll make the argument more carefully now.

Your "solution" revolves about make some game concepts like tiles fuzzy. This is possible to some extent but some things have to be absolute, because the rules become inconsistent if different viewpoints disagree about them. One such item is the relation between different units "can unit A attack unit B". I'll examine your system and see if it can be consistent about this relation.

Suppose we fill the map with units. (For ease of argument we assume a free for all, where all units belong to different players, and can only move a single tile. Note that with 18 players you can easily arrange the units in such a way that no neighbouring units belong to the same player.) We will construct a graph which represents the relation "unit A can attack unit B".

-For every unit we draw a vertex.
-If unit A can attack unit B, we draw a directed line from vertex A to vertex B.
-Consistency of the game rules requires that if A can attack B, then B can attack A. So we there will be for an arrow going from A to B there will be one and the opposite direction. We can thus forget about the direction of the lines and replace each pair of directed lines by a single undirected line.

The resulting graph has the following properties:
-From the viewpoint centered on each unit it is clear that each unit can attack exactly 6 other units, so the coordination number of each vertex is 6.
-On any viewpoint a part of the graph can be mapped on the local hex-grid, this means that any such patch of the graph is planar. Since overlapping patches of the graph have to agree this implies that the graph is planar.

It is ease to prove mathematically that any planar graph with coordination number 6 has Euler characteristic zero or larger. (This is simple combinatorics, which I won't bore you with.) This means that the map cannot be a sphere.

Since you apply your system to a sphere this means that one or more of the assumptions made above is violated. That is the rules cannot be consistent. So if you want this system to work the concept of what unit can attack what unit also needs to be made fuzzy/viewpoint dependent. For me that is not acceptable in a game like civ. It is definitely a lot worse that having a view pentagons in the grid.
 
This is possible to some extent but some things have to be absolute, because the rules become inconsistent if different viewpoints disagree about them. One such item is the relation between different units "can unit A attack unit B".

Here's another way to look at it that may be more palatable to the mathematicians amongst us.

Assumption / rule: Don't permit the user to look at the entire globe at the same time.

Two units on the "dark side" of the planet may be adjacent or they may not be. It's simply indeterminate to the viewpoint of the player.

(Before you rip this apart, let me point out that this is how CIV works now.)
 
Here's another way to look at it that may be more palatable to the mathematicians amongst us.

Assumption / rule: Don't permit the user to look at the entire globe at the same time.

Two units on the "dark side" of the planet may be adjacent or they may not be. It's simply indeterminate to the viewpoint of the player.

(Before you rip this apart, let me point out that this is how CIV works now.)

Completely irrelevant.

The line:
-If unit A can attack unit B, we draw a directed line from vertex A to vertex B.

Can be replaced by:
-If unit A can attack unit B in the viewpoint centred on A, we draw a directed line from vertex A to vertex B.

Since if if two viewpoints that both see units A and B have to agree on whether they are adjacent you can still build the graph.


Note that "indeterminate" is not an option for this notion of adjacent. And sure as hell it cannot depend on the viewpoint.
 
I was going to write a long post about the problems with Wodan's solution (Trias is talking about at least one of them) but I don't think it would actually be of any value to anyone.

The only way at this point I can see myself being convinced Wodan's method would work is with one of two things:
-Seeing it happen (best way to prove a solution is possible is to actually demonstrate an example of that solution).
-Being provided with the details for how it would work. Consider me to the be developer or programmer who needs to implement this fuzzy hex grid and that you need to describe to me in full detail how it would work, including things like how coordinates are stored for the sphere and what player views are possible etc.

Short of either of those two and I just have to play guessing games as to how the solution would work with respect to certain technical details. If I make some of those assumptions which Wodan turns out to not agree with I leave myself open to going with the wrong assumptions and hence wasting time.

I don't want to shatter dreams here but I honestly do not think all the consequences of such a solution are being fully appreciated by those who like the sound of it.
 
There are plenty of ways to represent a sphere on a flat surface, i don't understand this obsession with the curve of the planet, i think as long as the mechanics worked out i would be happy.
 
actually scratch that, representing a sphere on a flat surface with squares is pretty easy, my solution would actually work in Civ 4 and be really easy to represent on a mini map
but as i just discovered trying to do the same thing with hexes results in the exact same problem you guys have all been having here, you end up with 6 hexes on each pole that only connect to 5 other hexes,
its impossible to have an even number of hexes on a given edge and have them be symmetrical which is integral to my solution, which requires an even number of tiles on all 6 edges of the board

This is really mind-bending stuff...
 
Since if if two viewpoints that both see units A and B have to agree on whether they are adjacent you can still build the graph.
Fine. Modify the assumption to include "the distance of visibility must be less than the distance over which rounding results in any differences in the graph."

Note that "indeterminate" is not an option for this notion of adjacent. And sure as hell it cannot depend on the viewpoint.
Wow. Present mathematicians with noncartesian geometry and they get all cranky. :lol:

The only way at this point I can see myself being convinced Wodan's method would work is with one of two things:
-Seeing it happen (best way to prove a solution is possible is to actually demonstrate an example of that solution).
Clearly, that's not going to happen here. We don't have a staff of 3D modelers and programmers. But thanks for being thorough in listing the options. ;)

-Being provided with the details for how it would work. Consider me to the be developer or programmer who needs to implement this fuzzy hex grid and that you need to describe to me in full detail how it would work, including things like how coordinates are stored for the sphere and what player views are possible etc.
I'll take a crack at it if you can get rid of the "etc". That is, if I'm going to put in the work to provide answers, you need to put in the work to provide all of the questions that need definition. Fair enough?
 
actually scratch that, representing a sphere on a flat surface with squares is pretty easy, my solution would actually work in Civ 4 and be really easy to represent on a mini map
but as i just discovered trying to do the same thing with hexes results in the exact same problem you guys have all been having here, you end up with 6 hexes on each pole that only connect to 5 other hexes,
its impossible to have an even number of hexes on a given edge and have them be symmetrical which is integral to my solution, which requires an even number of tiles on all 6 edges of the board

Sounds like you want to make a cube...

For the hex version with 6 pentagons on each pole, that's actually a cigar. You need to space them more evenly out to make a somewhat sphere-like shape.

Cubes and cigars won't make too good spheres, I think.
 
I'm actually describing more of an octagon that when you travel over the northern or southern edge of the board you show up half-way across on the same edge, it makes sense it just doesn't work very well with hexes

It actually would work just fine if one didn't car about latitudes and just wanted polar movement

Honestly i doubt they would chose hexes if they were planning on making a globe seems a particularly bad shape for the job
 
I'm actually describing more of an octagon that when you travel over the northern or southern edge of the board you show up half-way across on the same edge, it makes sense it just doesn't work very well with hexes

It actually would work just fine if one didn't car about latitudes and just wanted polar movement

Honestly i doubt they would chose hexes if they were planning on making a globe seems a particularly bad shape for the job

Well, I believe that the best shape for the job is a triangle, and you can see why that wouldn't work (not enough surrounding tiles).
 
I'll take a crack at it if you can get rid of the "etc". That is, if I'm going to put in the work to provide answers, you need to put in the work to provide all of the questions that need definition. Fair enough?

Q1.1 Firstly, what coordinates do you use for storing the positions of stuff in the game? You seem to have answered that everything is stored as lat/long coordinates. That's fine.

First thing to note: when stored, lat/long coordinates make everything look like it's on a rectangle (in terms of storage).

Q1.2 What precision are these coordinates stored with? For example, will you store them to 1 decimal place? Will the precision depend on the size of the globe? If so, how would you describe that dependency?

Q1.3 Can the precision of the coordinates stored depend on the latitude?
e.g. Suppose you went with lat/long coordinates with 1 dec. place of precision. Is it ok that the coordinate resolution is finer near the poles than it is near the equator? Even if the answer to this is yes it doesn't mean there'll necessarily be any problems later.






Unit Movement:
Q2.1
If we are aiming to overlay a hex grid for the sake of moving a unit, how would that grid be positioned?
e.g. Is it centered such that the unit's position (a point - lat/long coordinate) is in the direct centre of a hexagon?

Q2.2 What camera angles are allowed? We talk about angle and pitch. Angle can be anything from 0 to 360 and basically refers to the compass direction the camera points. Pitch is 90 degrees for a birds eye view, 0 degrees for a horizontal view (e.g. a person on the earth looking at the horizon).

Some reasonble answers I can think of:
-pitch always fixed at one of two angles (maybe 90 and 45 degrees) while angle is always fixed to be 0 degrees (i.e. north to the top of screen)
-any angle allowed (0 to 360) but pitch fixed at just a single angle like 60 degrees.
-any angle and pitch are allowed

Q2.3
What hex orientations are allowed?
e.g. Suppose you can rotate the camera to any angle. Is the orientation of the hex grid overlay dependent on the camera angle or dependent on something to do with the sphere? (An example of something that would depend on the sphere is that the north direction is always a possible move)




Q2.4 Suppose a unit can move a distance of 2. Can the unit move to any lat/long coordinate within the radius-2 circle centred on that unit? Or can the unit only move to any one of the 18 hexagons around it (and if so can it only move to the centre of each of those hexagons) ?
This leads to question 3.


Distortion of the sphere
Q3.0 For the hex grid overlay, is the aim to represent the surface on a perfectly flat plane on the screen? Will any curvature be visible at the normal camera angle? Will any curvature be visible at any camera angle?

Q3.1 To overlay a hex grid (or a square grid) onto a sphere, some distortion is necessary. You can choose to distort either the hex grid or you can choose to distort the surface (i.e. make it look flat). Which is it you wish to do? Depending how you answer, head to either Q3.11 or Q3.12

Q3.11
Assuming you wish to distort the hex grid and not distort the appearance of the shape of the sphere, how do you plan to make the hexagons look? It should be noted that if this is the desired approach, you can't make hexagons get smaller the further you go from the active unit. If anything you actually need to make the hexagons get larger (in terms of the area they cover on the sphere).

Even if you can't describe this exactly, perhaps you can draw a very small scale picture on this circle. The minimum I need to see in the picture is a path from hexagons at the centre of the view (the middle of the circle) to the hexagons at the horizon (the edge of the circle). I am VERY curious about how you wish to do this. The pic does not have to be pretty. Try to give an idea of the size of the hexagons near the centre and the size of the hexagons near the horizon.

Here is a pic to get you started...
Spoiler :


Q3.12
Assuming you don't want to go with distorting the hexagon shapes and instead distort the sphere, how do you wish to do the distortion?
An example of one way to distort the sphere so that you can overlay a flat hex grid is to assume that the lat and long coordinates are simply cartesian coordinates and the gameboard is just a big rectangle with east west connecting together. Obviously this is a "cylindrical" distortion of the planet. If you go this route, and display a hex grid near the poles compared to a hex grid near the equator, you run into the problem that hex movements near the poles cover relatively less distance (on the real sphere) than hex movements near the equator. Is this avoidable or not?


Q4.1 Suppose you wanted to move a unit to the other side of the planet (diametrically opposite). Should it be possible to show a path for a unit to take on that route?

Q4.12 If that route can be shown, does it stick to a hex grid?

Q4.13 If that route cannot be shown (e.g. if you don't allow moving the camera around the earth while you have a unit selected and hence can't see the destination tile) do you accept that for moving a large number of units to the other side of the planet you will have to do 2 or more separate moves?

Q4.131 If the answer to 4.13 is yes, do you accept that the GOTO feature that every civ version has had will either have to be gotten rid of or limited in its range? What range would you limit it to? Perhaps you would instead allow the GOTO feature to take you to any point on the globe but have to say the number of moves to get there is "indeterminate".



Q5.1
Is unit movement the only thing subjected to hex grid restrictions? Is there anything else at all that needs to depend on some sort of hex grid? City positions, tiles that cities work, position of resources and other terrain types.

Q5.2 How do you decide if one unit can attack another unit? Do the two units have to fall in adjacent hexagons with whatever hex overlay is shown? Do the units simply have to be a distance of 1 or less apart?

Q5.3 What is the closest acceptable distance for two units to be from each other? (answer needs to be in terms of the underlying coordinates e.g. lat/long)

Q4.1
Has any consideration been given to the stability and processing time of dealing with calculating distances on a spherical surface? Spherical geometry is not trivial and is orders of magnitude slower than the trivial integer operations used for most calculations in Civ4.

Weirdness
Q6.1
When units move, what is to stop them ending up a tiny distance away from another unit? Or is this acceptable? If you intend to answer this with something about "rounding", please be explicit about what gets rounded and how. As an example, if I was playing a board game on a square grid and units could only be at vertices on the grid, yet a unit could move anywhere within radius 10, I might say that it can move to any vertex that has an x and y coordinate such that x rounds (to nearest integer) to -10 or 10 or some integer in between, and similarly for the y coordinate. This is an example where the rounding is completely explicit because I say "(to nearest integer)" and exactly which points the unit can move to (any x,y coordinates with -10<x<10, -10<y<10)

I will need to ask more questions but which questions to ask will depend on the answers to these questions.
 
Sounds like you want to make a cube...

For the hex version with 6 pentagons on each pole, that's actually a cigar. You need to space them more evenly out to make a somewhat sphere-like shape.

Cubes and cigars won't make too good spheres, I think.

Cubes can actual make pretty good spheres. They tile pretty well with varying shape diamonds. (With the smaller angle varying between 60 degree at the corners of the cube and 90 degrees at center of the faces.)

Fine. Modify the assumption to include "the distance of visibility must be less than the distance over which rounding results in any differences in the graph."
The argument works fine as long as each viewpoint covers at least two concentric rings of hexes. This is required to establish that the resulting graph is (locally) planar. If your viewpoints cover less area than that, that alone is a reason why this doesn't work. (You could not even get the catchment area of a single city on a single screen.)

Wow. Present mathematicians with noncartesian geometry and they get all cranky. :lol:
I'm actually quite comfortable with any kind of nonstandard geometry. It is how I make a living :). This the argument I presented centers on the topological aspects of the problem.

What makes me cranky, is when others simply ignore any arguments made.
 
Um you can do that with a simple program just have a center line (in most world maps this would be the prim-meridian) and have the unit in question appear on mirror square (so 40W becomes 40E) you could even have a time delay to simulated the travel time that increase the farther you are from the center. Or you could use extra tiles to more actuarially simulate the poles |\!/| (the ! represents the prim-meridian).

But I still think a globe would be SOOOOOOOOOOOOO awesome it would be cool if they had it look like it was on a desk or some this and had this office tie into the advisors with the office changing with the civ (like the US would have the oval office). and after learning Electricity or something all the Reports would look like a telegraph and you would have light bulbs.... it would defently get me in the world leader mood
 
Um you can do that with a simple program just have a center line (in most world maps this would be the prim-meridian) and have the unit in question appear on mirror square (so 40W becomes 40E) you could even have a time delay to simulated the travel time that increase the farther you are from the center. Or you could use extra tiles to more actuarially simulate the poles |\!/| (the ! represents the prim-meridian).

But I still think a globe would be SOOOOOOOOOOOOO awesome it would be cool if they had it look like it was on a desk or some this and had this office tie into the advisors with the office changing with the civ (like the US would have the oval office). and after learning Electricity or something all the Reports would look like a telegraph and you would have light bulbs.... it would defently get me in the world leader mood

One of the things I liked about civ 3 was the changing pictures and music of civs over the different eras, I was hoping they would put both of those aspects into civ 4, but they only put in the music.
 
Status
Not open for further replies.
Top Bottom