Support arbitrary board shapes and tiling?

[MayeulC]

Hi there, I saw this project recently, as well as a few comments from expert civ 3 players who stated that this instalment in the series was great, but that the hex shape was usually preferred by players (I note that I have played most civs a while back, especially 2 and 5, but not 3).

This got me thinking... Gameplay-wise, I don't think anything really requires square cells, though that may require some rebalancing.

I think that supporting arbitrary board shapes would be fairly doable, especially if done early in the development process, hence why I am bringing this up now. This seems aligned with the goal of making C7 as mod-friendly as possible.

The idea is very simple: replace grid coordinates with handles. Use geometry-specific functions to perform actions you would usually walk the grid for: iterating on cells, finding neighbors, computing distances. Internally treat the structure as a graph if needed.

Application examples that would be enabled by this:

• hex cells, or other arbitrary shapes (including non euclidian)
  • Non euclidian may come in handy for tiling a sphere with polygons
• wrapping around in arbitrary locations (poles, for instance)
• enable mods to do some more crazy stuff:
  • "warp point" on a map
  • sparse board, for a space strategy game, for instance.
  • uneven tiling, enabling city combat for instance, or larger ocean tiles.
  • join multiple boards: think the nether in Minecraft, an "orbital" board above the main one, or the space strategy game metioned above (I'm thinking of how Sins of a Solar Empire works, for instance).
  • boards that shrink or grow dynamically
  • having different boards for different players in the same game (yeah, not sure if that would work well).

In the above example, if a mod alters the geometry, it should provide its own implementation of board traversal. Unless graphs are used everywhere, which would be geometry-agnostic as they only care about connectivity (properties such as roads, coastal, etc being encoded in the edges).

Anyway, that's just an idea for now, you call the shots. It may not be worth the complexity, but I think that abstracting coordinates is a good thing anyway (and I don't think it is performance-critical).

What are your thoughts on this? Too much feature creep?