Possible Future Direction (personal view)

Post 4 up (which is actually just part 1 of what I had originally intended to be post 4, so hoping to complete it tomorrow)

Given that this post is up, I might be a bit out of date, but have triangular tiles ever been considered as a stopgap before moving away from tiles entirely? They can tesselate a globe perfectly.
 
Given that this post is up, I might be a bit out of date, but have triangular tiles ever been considered as a stopgap before moving away from tiles entirely? They can tesselate a globe perfectly.

Yes, but triangle tiles are really just degenerate Hex tiles, so we'd rather use that.


@Koshling:

Not much to comment on for the conceptual layering there, I don't really see anything else to do with it. However, I do like the idea of decoupling the tiling scheme from the rest of the rules, given the disagreements we have there. I'll be much more interested in seeing the software leveling.
 
@Koshling

Your blog entries make me feel dumb. I am so glad we have someone as smart as you on the team.

I so very much agree. I read that last one and understood maybe 10% of it. The rest was a complete mystery as to what was being explained to the point that I really had no comment. I know enough to know its discussing the architecture of the coding plan to the point that its beyond my understanding of basic coding architecture - period.
 
I'm just glad to see that the people in my "old programmers" coffee meetings are wrong and the new generation do understand how to generalise (abstract is the modern term) to the nth degree:).
 
You guys are all a bunch of nerds.

(As a non-programmer who knows very little about C++, C#, OGRE and the like, and whose modding skills barely stretch to writing scripted events for Europa Universalis, I just felt compelled to say this. :D)

Anyway, since I'm the uber map nerd myself, and since Koshling wrote that he wanted to give globes a shot (which I think is awesome!), here is some more stuff that might be of interest for the rendering.

Koshling, if you don't find it of any use, just let me know. All the better if we don't have to concern ourselves with it, I suppose! But just in case there is some use to it, here we go:

I've already pointed out that the underlying shape for the global hex grid we are aiming to use is an isocahedron, a 20-sided die:



Now, it is of course possible to "fold out" the 20 triangular sides of the die into a plane. There are numerous possible configurations for this, but the one that I think is most potentially useful for our purposes is this one:



For further illustration, here is an Earth map, projected onto a twenty-sided die and then folded out:



Theoretically, it would be possible to treat the map as flat when the view is zoomed in far enough so that it is all completely within one of the triangles. Actually, along the middle row of triangles, you could move from the left edge of the map all the way to the right edge while treating it as flat. This might have some advantages for the display when zoomed very far in. I don't know, I'm just bringing up the possibility.

When moving from one triangle in the upper or lower rows to another triangle in the same row, it is not possible to treat the map as flat, because there are spaces between these triangles in the flat fold-out. So, for the transition from one triangle to another in these two rows, the camera would have to use the spherical rendering. Once only tiles from the next triangle are in view, it could theoretically go back to planar rendering again.

Like I said, I don't know if any of this is practical or useful, but I thought I might bring it up as a possibility just in case it is.
 
@Laskaris

The game Evolution: The Game of Intelligent Life actually uses that type of map. Its a little weird but you get use to it after awhile.[/IMG]

Thanks for the info. I like life simulation games.

Mind you, I'm not proposing to actually use such a map. I'm proposing to use a globe and, if it is helpful, perhaps use the flat fold-out for rendering purposes when it is possible (i.e. when the view is zoomed in far enough).

(I think you understood that, I just wanted to make it clear for everyone else as well in case there is any confusion.)
 
I mentioned it because not many games have maps that use that type of map. There is also a realistic scenario in the game that use real Earth tectonics and mass extinction events at the correct time. It is by far my favorite way to play that game. Note this game was made back in 1997. But it was still very cool and a unique concept for a game.
 
Are there actually that many rules that really depend on a specific topology?
If you have adjacency and distance-depending relations then most rules can be written down in a way that only depends on these relations but not on the topology if that topology defines the relations.

One other important point: Any of the relationships together with the entities forms a graph and on any such graph we might want pathfinding (like finding a path to a unit in the unit upgrade tree or the path to a technology that provides a specific unit). So the pathfinding algorithms should not be restricted to the main map topology.
In the same way the UI (and maybe we should split input and output there) should be able to render more than one graph variant.
Best add a layer in between that defines views on the data and maps it to types of render objects. Then the UI can be checked if it provides display possibilities for the render objects defined as a must and not optional in the mapping layer.
 
Are there actually that many rules that really depend on a specific topology?
If you have adjacency and distance-depending relations then most rules can be written down in a way that only depends on these relations but not on the topology if that topology defines the relations.

One other important point: Any of the relationships together with the entities forms a graph and on any such graph we might want pathfinding (like finding a path to a unit in the unit upgrade tree or the path to a technology that provides a specific unit). So the pathfinding algorithms should not be restricted to the main map topology.
In the same way the UI (and maybe we should split input and output there) should be able to render more than one graph variant.
Best add a layer in between that defines views on the data and maps it to types of render objects. Then the UI can be checked if it provides display possibilities for the render objects defined as a must and not optional in the mapping layer.

There would need to be two different strategic and tactical AIs for Hexes and Squares (yikes). That is the first thing I can think of OTOH, but there would also need to be different interfaces and some other things I probably can't see at the moment.
 
There would need to be two different strategic and tactical AIs for Hexes and Squares (yikes). That is the first thing I can think of OTOH, but there would also need to be different interfaces and some other things I probably can't see at the moment.
Neither UI nor AI are part of the rule components.
 
There would need to be two different strategic and tactical AIs for Hexes and Squares (yikes). That is the first thing I can think of OTOH, but there would also need to be different interfaces and some other things I probably can't see at the moment.

I don't really see why AI (which just needs to know how things a connect as a graph), or the API (which can just use a generic coordinate system) are affected to be honest.
 
I don't really see why AI (which just needs to know how things a connect as a graph), or the API (which can just use a generic coordinate system) are affected to be honest.

Hm, wouldn't the AI unit movement/war strategies differ based on what the tiles are like?
 
Hm, wouldn't the AI unit movement/war strategies differ based on what the tiles are like?

I guess they theoretically could, but I don't really see a compelling reason. Nothing in the current ai uses any concepts apart from distance (in turns) or adjacency.
 
Ah, OK, I'm overestimating the AI tactical capabilities.

Or over estimating the tactical implications of topology. What specifically (just by way of an example) would you do differently with a square grid as opposed to a hex one (that isn't just an implicit consequence of adjacency relationships) ?
 
Or over estimating the tactical implications of topology. What specifically (just by way of an example) would you do differently with a square grid as opposed to a hex one (that isn't just an implicit consequence of adjacency relationships) ?

For instance, with square tiles it is always advantageous to explore diagonally, you will see more that way in almost all cases. Hex tiles, not so much. That is one thing which I can think of OTOH.
 
For instance, with square tiles it is always advantageous to explore diagonally, you will see more that way in almost all cases. Hex tiles, not so much. That is one thing which I can think of OTOH.

That drops put of the adjacency relation by telling the pathing algorithm to maximize number of tiles made visible. Nothing need know about the explicit concept of square or diagonal to achieve that.
 
That drops put of the adjacency relation by telling the pathing algorithm to maximize number of tiles made visible. Nothing need know about the explicit concept of square or diagonal to achieve that.

OK, makes sense. Will one be able to make the AI modular or not? Or is that part of the next blog post?
 
Top Bottom