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

[Trias]

Let me try to challenge the assumption again. The presumption is that
1) the entirety of the globe must be presented in a single grid, at the same time, for view by the player, and
2) that the grid cannot change as the player scrolls around.

#1 is not true, clearly. It never happens.
#2 is clearly possible. If I look at New York City, what units are "adjacent" if we extrapolate the grid over to Brisbane may not be the units that are truly adjacent if I scroll all the way around and center my view on Brisbane.

Although it is perfectly fine for the geometry of the grid to change as you scroll, its topology may not, since topology change means exactly that the game rules are ambiguous/inconsistent.

Your whole solution revolves about the assumption that you can push the problem points out of view for any viewpoint. The problem basically arise when two different viewpoints try to scroll to a common problem point, since it will be impossible for them to agree on what they will find there.

 

[Wodan]

Is there somewhere, Wodan, where you've said exactly which assumptions you make and exactly which solution you propose?

I've summed it up several times, such as post #190. In brief:
-- locations are by pixel location (X,Y) not 1:1 tile
-- When units move, rounding is performed (<1%) to conform to the hex grid
-- When units display, rounding is performed to conform to the hex grid

That's it.

Normally I can follow any mathematical argument that has atypical assumptions but I've not been able to follow this one.

That's because it does not rely upon exact mathematics, thus it is not a mathematical argument. The base assumptions of the "mathemathical arguments" put out there by people who say a true hex/sphere game is impossible rely upon assumptions that:
-- all units must conform to the hex grid at all times (a 1:1 correspondence must be held true at all times)
-- units must always be exactly 1 tile distance apart, with no fractions of tile distance.

Neither of which have to be true.

I cannot agree that all consistency problems are avoided.

Well, let's look at the consistency problems you think can't be avoided, and avoid them.

It seems to me from what I've read, that it might be possible for a player to end his turn with, say, 10 tiles distance between two of his units. After another player has his turn and perhaps causes some unit position rounding, the distance between those 2 units could change.

Rounding is < 1% so there's no way it would cause a change you describe. Unless those units were, say 90 or more tiles apart... that's the only time it could happen. One assumption we do have is that no unit has a movement capability of > 20. So this isn't even close to an issue. We have a factor of 5x coverage.

The world that has every tile filled with units is not all that contrived.

I didn't mean that a "filled" world was contrived. Sure, that can happen. What is contrived is saying

-On a sphere the circumference of a circle (or hexagon) does not grow linearly with its radius. (It is 2pi*R Sin[r/R] with r the radius of the circle and R the radius of the sphere)
-Since on the locally imposed hex tiling the number of units in each ring does grows linearly with the size of the ring, the density of units on each ring (as measured on the actual sphere) grows with the size.
-This means that (since map was already filled with units) from some other view point multiple units MUST be in the same tile.

The above imposes a set of mathematical rules on the game which do not have to be the case. That makes it a self-fulfilling example and contrived is an appropriate word.

This whole idea of there only needing to be one viewpoint is even more confusing...

Why? It happens every time you play and has happened in every version of Civ to date. You only see what's on the screen.

Let's look at another anology. Get rid of hexes and think of squares (as we have now). Imagine if we implemented a "vanishing point" visual engine, where if you scolled, instead of truly scrolling the screen, it stayed in place but rotated the viewing angle so as if you are looking toward the horizon. The lines of the square grid would change in size as they go into distance. Like this:


Okay, now, imagine that with a hex grid.

In essence, that is what my proposal does.

 

[Wodan]

Your whole solution revolves about the assumption that you can push the problem points out of view for any viewpoint. The problem basically arise when two different viewpoints try to scroll to a common problem point, since it will be impossible for them to agree on what they will find there.

I agree, it relies on that assumption.

As I said before: it doesn't matter what happens on the "dark side" of the planet, because we never go there. If we do, it's not the dark side any longer, its daytime.

 

[PieceOfMind]

Ok, let me go over your assumptions in a bit of detail. Please correct me for any wrongs...

I've summed it up several times, such as post #190. In brief:
-- locations are by pixel location (X,Y) not 1:1 tile

Sounds reasonable but I'm still curious how you would choose the 2 coordinates. I'm going to assume you choose the fairly standard latitude and longitude as coordinates so we have X going from X = -180 to +180 (note -180 = +180) and Y= -90 to +90.

This would be interesting because rounding of these coordinates to some standard amount (like 2 decimal places) would imply units at different positions on the sphere be rounded more or less than others in terms of real distance.

How does one choose to store these coordinates on the computer?

-- When units move, rounding is performed (<1%) to conform to the hex grid

This is pretty ambiguous to me. For starters, how do you choose how to orient the hex grid? Do you set it up so that east-west is always a possible hex-move? (EDIT... Actually, this would only be possible at the equator. So the question of how you would orient the hex grid in general is even more difficult than I first thought. If east and west were both always possible moves, then essentially you'd be back to the start again, working with a cylindrical Earth!)

For me to follow the argument, I need to know what quantity is being rounded and how it is being rounded.

Also, it seems to me that in this step you imply that any unit (not just the unit being moved) could have to be rounded to the hex grid that's based on the moving-unit's starting position. Suppose an enemy unit Z is within the movement range of a large number of your units. Is it not possible to cause that unit Z's position to be rounded every time you move one of your units? If so, that unit Z's position could be rounded many times in the same direction. Essentially you can move that unit slowly.

-- When units display, rounding is performed to conform to the hex grid

That's it.

I'm still unsure how this would work. I'm not sure how you're setting up the hex grid about a particular point. It's not a trivial task.

************

By the way, what you are describing is still a mathematical argument. Premises and propositions don't always have to be strong or exact things for them to be mathematical.
However, to implement any system like this on a computer there do have to be exact rules. For that reason, there should be a precise way of dealing with any particular situation that's thrown at you. For if there isn't, then how would a computer possibly decide what to do?

 

[Vortilex]

I'd love a round map, considering how in my (failed) mod attempt in CIII I was working on a round map, but I didn't like the options offered.

 

[Trias]

That's because it does not rely upon exact mathematics, thus it is not a mathematical argument. The base assumptions of the "mathemathical arguments" put out there by people who say a true hex/sphere game is impossible rely upon assumptions that:
-- all units must conform to the hex grid at all times (a 1:1 correspondence must be held true at all times)
-- units must always be exactly 1 tile distance apart, with no fractions of tile distance.

I make neither of those assumptions.

Lets go back to the world filled with units.

-All viewpoints have to agree on which unit can attack which unit. Agree?
-Since locally a hexgrid can be applied around each unit, each unit can attack six other units. Agree?

These two statements are incompatible. That is your system leads to inconsistencies. You can be indenial all you want, but it just won't work.

 

[StittsvilleJame]

Round is overrated. I'm happy with a cylinder.

 

[Wodan]

Lets go back to the world filled with units.

-All viewpoints have to agree on which unit can attack which unit. Agree?
-Since locally a hexgrid can be applied around each unit, each unit can attack six other units. Agree?

These two statements are incompatible.

How so? Especially in context of this? Every tile in those images has exactly 6 neighbors.

 

[PieceOfMind]

How so? Especially in context of this? Every tile in those images has exactly 6 neighbors.

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.

The solution proposed by orthoceros in that thread is elegant and IMO has advantages over the pentagon-dependent solutions that have mostly been focused on so far, but it is still not a hex grid.

I think this is based on an assumption that any X grid, where X is a shape, cannot have bits overlapping. It's true this is an unstated assumption but it's a pretty reasonable one to use in any practical discussion. Certainly if one uses the term "hexgrid" I think it (the assumption) is implied if there are no additional qualifiers stating otherwise.

 

[eireksten]

How so? Especially in context of this? Every tile in those images has exactly 6 neighbors.

It's still not a hex grid, though Tiles don't have the same number of k-neighbors (tiles within a distance k from eachother) for k>=2.

 

[Wodan]

It would have special rules for some tiles.

Which I replaced using the ongoing rounding.

Even in those illustrations, the "special" tile still has exactly 6 neighbors.

I think this is based on an assumption that any X grid, where X is a shape, cannot have bits overlapping. It's true this is an unstated assumption but it's a pretty reasonable one to use in any practical discussion. Certainly if one uses the term "hexgrid" I think it (the assumption) is implied if there are no additional qualifiers stating otherwise.

But if we allow overlap (or rounding), it is an elegant solution that could potentially resolve all ancillary issues.

 

[PieceOfMind]

Which I replaced using the ongoing rounding.

Even in those illustrations, the "special" tile still has exactly 6 neighbors.

I was mainly pointing out that what Trias said earlier is correct or at least if it isn't then othoceros' solution is not a counter-example as you implied.

Lets go back to the world filled with units.

-All viewpoints have to agree on which unit can attack which unit. Agree?
-Since locally a hexgrid can be applied around each unit, each unit can attack six other units. Agree?

These two statements are incompatible.

But if we allow overlap (or rounding), it is an elegant solution that could potentially resolve all ancillary issues.

If you are going to go with orthoceros' solution then there's no need for rounding in the first place, if you're prepared to live with the odd hexes at the 6 points he mentioned.

I'm still very unclear on how your proposal works as I described a couple posts earlier. Did you actually write anywhere how the rounding works? From what I can remember, all you've said is things like the rounding is to the hex grid and it's less than 1%. It means nothing to me until you tell me what you're rounding and how you round it.

 

[Wodan]

I was mainly pointing out that what Trias said earlier is correct or at least if it isn't then othoceros' solution is not a counter-example as you implied.

Without even responding to the above, I took a second look at your note, and I don't think the following is correct.

the 2 red units should be blocking.

That is only true if we are coming from the original solution which has pentagons at the cardinal points, which we expressly do not want.

If you are going to go with orthoceros' solution then there's no need for rounding in the first place

The rounding permits each viewer to have "normal"-looking hexes at his perspective, instead of biased, irregular hexes.

I'm still very unclear on how your proposal works as I described a couple posts earlier. Did you actually write anywhere how the rounding works? From what I can remember, all you've said is things like the rounding is to the hex grid and it's less than 1%. It means nothing to me until you tell me what you're rounding and how you round it.

Obviously, there are differences between a "normal" shaped hex grid, and irregular/oblong shapes. In order to accommodate those differences, some slight adjustments are necessary in game as pieces move around.

What other explanation do you need?

 

[PieceOfMind]

Obviously, there are differences between a "normal" shaped hex grid, and irregular/oblong shapes. In order to accommodate those differences, some slight adjustments are necessary in game as pieces move around.

What other explanation do you need?

Essentially I want to know what slight adjustments you are talking about. If you mean for example that the coordinates (whatever they are) of units other than the one you're centered on can be changed so as to line up with the hexgrid then you end up with lots of small movements of units every time you move a single unit one hex.

There's still the question of how you choose to orient the hexgrid that you're talking about as well. As far as I've seen you haven't even attempted to address that question. Is the choice made by the game or the player?

Another thing... As far as I know you can't just send points off to infinity when you're working on a sphere unless you go with something very nonstandard like allowing vanishingly smaller hexagons.

 

[Wodan]

Essentially I want to know what slight adjustments you are talking about. If you mean for example that the coordinates (whatever they are) of units other than the one you're centered on can be changed so as to line up with the hexgrid then you end up with lots of small movements of units every time you move a single unit one hex.

No, you don't reorient every single unit, only the moving unit.

There's still the question of how you choose to orient the hexgrid that you're talking about as well. As far as I've seen you haven't even attempted to address that question. Is the choice made by the game or the player?

I've said it many times. It's the viewpoint of the player.

Another thing... As far as I know you can't just send points off to infinity when you're working on a sphere unless you go with something very nonstandard like allowing vanishingly smaller hexagons.

What's the problem?

 

[IdiotsOpposite]

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.

The solution proposed by orthoceros in that thread is elegant and IMO has advantages over the pentagon-dependent solutions that have mostly been focused on so far, but it is still not a hex grid.

I think this is based on an assumption that any X grid, where X is a shape, cannot have bits overlapping. It's true this is an unstated assumption but it's a pretty reasonable one to use in any practical discussion. Certainly if one uses the term "hexgrid" I think it (the assumption) is implied if there are no additional qualifiers stating otherwise.

Actually, allowing each hex its "full" boundary does allow the white unit to attack the pink unit. Legally.

It only makes sense, because if the white unit couldn't attack the pink unit, then the white unit could only attack 5 tiles, and you'd have a pentagon.

 

[CHEESE!]

This feels like a weird Nobel Prize entry thread.

 

[BlackSpy]

Wodan,

So glad you made these points. I've thought it a perfectly reasonable approach to doing a spherical hex based map but would never have had the patience to set it out some well.

 

[Wodan]

Thanks, I guess.

Honestly, to some extent I'm playing Devil's advocate. On the other hand, I think people tend to think in rigid mathematical terms and forget that a flexible, more "liberal" implementation is fully possible. Real life doesn't have rigid boundaries. Roads have shoulders, oceans/land have beaches, hillls don't begin abruptly - they gradually build up, etc.

 

[Bezurn]

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.