Possible Future Direction (personal view)

[rightfuture]

Here's my basic take on creating the Future of C2C and CIV.
If I was to make a game myself; a combination of this game, the one I mentioned in the above post, and rev-evolve-improving C2C would be the direction I would head in. The Ultima Ratio Regum project I mentioned above is certainly the next best thing to C2C I've found so far.
The ultimate game for me would be a combination of:
1. Civilization's level of detail and depth (excluding Civ 5's simplification and hex direction limitations) expanding on the depth and best of C2C (and other CIV mods)
2. SimCity/Earth('s scope) and living world simulation,
3. Ultima (IV-V and Online)'s nonlinear type strategic and representational gameplay (non-fantasy) and more historical deviation and dynamic storytelling with some of the generic generation elements of Skyrim series and living world improvements from mods (from any world type game).
4. Master of Orion (1,2, some ideas from 3)'s detail, strategy, and galactic expansion, (not to mention the best parts of similiar space and earth strategy and video games like Age of Empires, Galactic Civilization 1&2 and expansions, Space Empires I-V, and similiar games like Ascendancy (old pc and new port to ipad), and all sorts of variations on games like MULE, and other 4x "explore, expand, exploit, and exterminate" games even as basic as the Oregon Trail and the Seven Cities of Gold (great exploration) and other games which only explore one of these 4 elements. There all lots of simulation. strategy, and exploration games that do just one thing uniquely or well. Any one could bring in new game concepts or ideas for elements. Heck lists from any of these games historical, strategy, roleplaying, or not could be combined into a master list of ideas for technologies, units, terrains, You just need to find forums, discussions, ideas, etc.
http://en.wikipedia.org/wiki/4X
http://en.wikipedia.org/wiki/Chronology_of_4X_video_games
5. and elements from
-roguelike games, like dwarf fortress/nethack/slash'em/ angband variations (which combine simple elements into complex emergent gameplay,
-games like MUDs, MOO's,(There are MUCKS,MUSHES and many other variations with useful features) and MMO/MMORPG's which creatively add multiplayer into larger scale world gameplay and other interactive feature incorporated into similiar type games. lookup the Skyrim mod which adds multiplayer or tower defense gameplay for example. Roleplaying could be an added selectable feature. Buying houses, interacting with others in the same world. Turning off and on multiplayer in existing games. New idea: Being able to explore saved versions where you or multiplayers can jump in a saved game and take-over other countries or bow out and let the AI take-over. Basically allow ai or players to take-over different countries from saved games freely..or allow people to come in.
http://en.wikipedia.org/wiki/List_of_MMORPGs
http://www.mudconnect.com/
http://en.wikipedia.org/wiki/MUD
http://en.wikipedia.org/wiki/MOO
http://moolist.yeehaw.net/
http://nimud.divineright.org/webmudlister/list.php
-features and ideas from resource trading games like Settlers of Catan, political games, Trading and transportation games like Railroad Tycoon, and lot's of strategy board games, like Axis and Allies, Risk, etc. not to mention strategic elements, and charts from the more realistic of paper historical roleplaying games like Traveller (space rpg being rebooted on kickstarter) d&d (pathfinder) and gurps. You can't say that there aren't lot of ideas from those games and their forums. There are lot's of ideas for tech trees and units there, especially for alternate histories, use google please guys! (I've only said this dozens of times here). Most of it is pretty generic, easy to find, applicable, and usable. Many lists, units, techtree's, and unique features from these games are easy to find and inspirational. Navigable rivers isn't the only game idea you can find in ten minutes of searching.
http://en.wikipedia.org/wiki/Timeline_of_role-playing_games
http://en.wikipedia.org/wiki/Chronology_of_computer_role-playing_games
http://en.wikipedia.org/wiki/List_of_board_games
- and a cut to the chase for great ideas that can be easily turned into a list which can be explored for expanding on C2C and the best of CIV!
game design forums
http://www.thegamedesignforum.com/
http://www.gamedev.net/forum/17-game-design/
http://www.bgdf.com/
http://forum.rpg.net/forumdisplay.php?11-Game-Design-amp-Development
http://www.kongregate.com/forums/91-game-design
http://devmaster.net/forums/forum/30-game-design/
http://forums.indiegamer.com/forumdisplay.php?19-Game-Design
http://boardgamegeek.com/forum/26/boardgamegeek/board-game-design
http://gamedesign.bramsonort.edu/
http://forum.thegamecreators.com/?m=forum_read&i=19
http://www.therpgsite.com/forumdisplay.php?f=33
http://thegamedesignforum.com/forums/forumshome.html
http://rpgmaker.net/forums/design/
maybe we could find inspiration and compatriots here pretty easily (not to mention let people know about C2C and where we all want to go for the Next Civ!
You can just as easily spend some time looking for what people think are the best features of the the best games out there. (and mention them here)
There are some existing lists of what people would add in the the next civ game. You could also look up past list to see what could have been included!

Ultimately I would call it ULT-SIM-CIV-4X! (if such an open source game name could be used and cc anti-trademarked)
I would invite the successful makers of other mods and games to join in, and I would invite the great ones from ROM, AND and modders in other games and forums to participate.
Basically create a Dream Team and invite gamemakers from forums, mods, and actual commercial games to donate their advice and time in the name of the ultimate game!
Anything is possible when you work together to forge an improving and evolving alliance of like-minds!
You just have to get out of you own and each other's way to work on how to make it possible.
As long as you are aimed at making progress and open to it getting better, existence and imagination, not the sky, the galaxy, or the dimensions are the limit. Model the funniest, and most realisitic living world to explore and play in and have it evolve around that!
It can be open and flexible, yet moderated, realistic, and possible. Best of both worlds.

CIV IV, ROM, AND, and C2C are just the best foundation to ground it in yet. I hope you/everybody can transition well and bridge the best of both worlds.
Having a personal or group future, and shared community project which builds with and not just off each other keeps both growing.

This allows you to explore new ideas and your own personal vision while bridging the community project to keep cross-pollination of development/ideas while growing both. Besides you have 2 projects to shift between and grow while exploring the other possibilities, and this way the community stays together while exploring new ideas. This way you have something to do when either stalls, or you have ideas on how to make the other one better. Either way I hope we all see the value of continuing to work together and challenge each other, even if we disagree, so that we can continue to make progress; collectively and individually, for the present and future, for the sake of seeing the best ideas become real, and coming up with the best C2C, the best game, and the
best NEXTCIV possible!

 

[AIAndy]

Since my suggestions are spread over this thread, I'll make a summary post about my ideas for the core system of AXXXXE. It is considerably more function rich than Koshling's original suggestion to avoid having to reinvent the wheel as often as it happened in the Civ4/C2C DLL. That functionality is not really use-specific so the result is more a generic topological/object-oriented/functional/relational database system than something only a 4X game could use.

The entities are split into classes and instances. Classes are defined in the rule dataset and can inherit from each other. Instances inherit from exactly one class and can have properties that change during runtime. At instantiation they are usually very cheap as only an entry to the INSTANCE relationship is added.
Properties have a type (which is inherited and cannot be changed in the inheriting class or instance) and can be either a variable or functional. Functional means that it does not define the value directly but how the value can be derived from other properties.
All properties can have modifiers attached to them. There are predefined attachment points (which might be part of the type). For each of those points modifiers behave in a commutative way.
When a property value of an instance is requested the instance is checked for the value. If it is not defined yet in the instance, the parent classes in the inheritance tree are checked. The variable or functional is evaluated and afterwards the modifiers on the instance for this property are applied. The resulting value can be cached in the instance (with appropriate change events registered automatically).

Relations can be explicit (tables), derived (queries) or special. Special mainly includes derived topological relations which are too expensive to store explicitely or solve as queries. All of them are required to be able to trigger relation change events and also implement relational algebra for use in queries using SQL (or some other query language). An efficient implementation of that likely includes some decomposition and compilation into a sequence of basic steps. Some explicit caching of derived or special relations might be useful.
Relations can have parameters, e.g. parametrized queries (but you have to specify the parameter to register a change event).
I think that most rules are not really dependent on the actual topology if they can use derived topological relations like NEAR(distance) or ADJACENT or similar which work for both hexes and squares and other plot types (it would be based on explicit entity-plot and plot connectivity relations).

Relation-bound entities: Entities can be bound to a relation of any type. That means for every tuple/entry/row of the relation, an entity is instantiated and the lifetime of that instance is bound to the existance of that tuple in the relation (so the instance is killed when the relation changes and does not contain the tuple any more). The relation-bound entity can specify its addition to explicit relations using parametrized queries with the tuple it is bound to as parameters.

Relation-bound modifiers work similar but add modifiers to specified properties or entities given by a parametrized query.

Persistence will save instances and explicit relations. If the class an instance is derived from is no more present in the rule set, then there could be rules in the rule set if the instance is to be replaced with a different one or just removed.

 

[ls612]

Since my suggestions are spread over this thread, I'll make a summary post about my ideas for the core system of AXXXXE. It is considerably more function rich than Koshling's original suggestion to avoid having to reinvent the wheel as often as it happened in the Civ4/C2C DLL. That functionality is not really use-specific so the result is more a generic topological/object-oriented/functional/relational database system than something only a 4X game could use.

The thing is, we are intending to make a 4X game, not a relational database front-end. So while I like some of the ideas here I think we need to keep our eye on the ball as to what our goal is.

The entities are split into classes and instances. Classes are defined in the rule dataset and can inherit from each other. Instances inherit from exactly one class and can have properties that change during runtime. At instantiation they are usually very cheap as only an entry to the INSTANCE relationship is added.
Properties have a type (which is inherited and cannot be changed in the inheriting class or instance) and can be either a variable or functional. Functional means that it does not define the value directly but how the value can be derived from other properties.
All properties can have modifiers attached to them. There are predefined attachment points (which might be part of the type). For each of those points modifiers behave in a commutative way.

I think that all entities should have properties that change during runtime. We can use abstract entities to define multiple sub-entities (example, Unit could be an abstract entity which can be used in defining Air, Land, Naval, Space, and what have you units, each as separate entity types for relational purposes). This also makes the Topological relations easier (Tile is an abstract entity, and can be used to define hex tiles, square tiles, or whatever we want really in the topological engine). And every property except for ID (and maybe a couple internal properties for the graphics engine) should be modifiable in theory during runtime. And every property should be functional, ie bools can be modified using boolean logic and ints using functions defined in the Entity manager.

Relations can be explicit (tables), derived (queries) or special. Special mainly includes derivRed topological relations which are too expensive to store explicitely or solve as queries. All of them are required to be able to trigger relation change events and also implement relational algebra for use in queries using SQL (or some other query language). An efficient implementation of that likely includes some decomposition and compilation into a sequence of basic steps. Some explicit caching of derived or special relations might be useful.
Relations can have parameters, e.g. parametrized queries (but you have to specify the parameter to register a change event).
I think that most rules are not really dependent on the actual topology if they can use derived topological relations like NEAR(distance) or ADJACENT or similar which work for both hexes and squares and other plot types (it would be based on explicit entity-plot and plot connectivity relations).

I actually agree with Koshling on this point, all relations should only take Entities as parameters. So, for your example, NearTo(Entity A, Entity B) would have what 'near' is defined in the function itself, not as a parameter. Does that lose some flexibility, sure. But, it makes relational management easier to code, and as far as I know you are the only one among us with significant relational database experience.

Relation-bound entities: Entities can be bound to a relation of any type. That means for every tuple/entry/row of the relation, an entity is instantiated and the lifetime of that instance is bound to the existance of that tuple in the relation (so the instance is killed when the relation changes and does not contain the tuple any more). The relation-bound entity can specify its addition to explicit relations using parametrized queries with the tuple it is bound to as parameters.

This could run into problems. For instance, an entity can not logically have two parent entities given the current entity setup. So relations need to have restrictions on them, both for logical consistency, and for gameplay reasons (maps can not be children of units, etc).

The top level entities under Game would be Maps and Players, and under those would be Tiles (from Map), Cities (from player, but related to tiles), and Units (from Player). I would vote for those being defined internally, even though it cuts down flexibility, for the reason I stated above, which is that we are wanting to make a 4X game, not a general relational database program with fancy graphics.

At any rate, those are my 2cp on this, I hope that Koshling has more time next year and we can start this project sometime soon.

 

[Alex Costa]

I actually would like to contribute to this potential project. I believe Koshling has a good gem here. In my opinion I would also like to incorporate ideas from other games. Maybe Galciv's civs. Anyway I assume C2C will be used as the base right?

 

[ls612]

I actually would like to contribute to this potential project. I believe Koshling has a good gem here. In my opinion I would also like to incorporate ideas from other games. Maybe Galciv's civs. Anyway I assume C2C will be used as the base right?

Only insofar as that it will be a 4X game set in historical and future times. We actually can't legally recycle any of C2C's assets under the terms of the original Civ 4 EULA.

 

[Alex Costa]

Only insofar as that it will be a 4X game set in historical and future times. We actually can't legally recycle any of C2C's assets under the terms of the original Civ 4 EULA.

Nice. Though doesn't mean we can't use the ideas on the mod. BTW if you can take a look at my ideas for improved cultures which I am working on right now. Might be an interesting concept to include.

 

[ls612]

Nice. Though doesn't mean we can't use the ideas on the mod. BTW if you can take a look at my ideas for improved cultures which I am working on right now. Might be an interesting concept to include.

Yeah, ideas are pretty much open at this point. I'm thinking that once we have the engine core working that we'll release a proof of concept alpha with 2d graphics and basic gameplay to pique people's interest (specifically to find Graphics people to help with making graphical assets).

But I welcome the opportunity to redesign all of the gameplay from the bottom up.

 

[Alex Costa]

Yeah, ideas are pretty much open at this point. I'm thinking that once we have the engine core working that we'll release a proof of concept alpha with 2d graphics and basic gameplay to pique people's interest (specifically to find Graphics people to help with making graphical assets).

But I welcome the opportunity to redesign all of the gameplay from the bottom up.

That might take a while but in the meantime we can always test stuff that might be added to that game in C2C and discuss it.

 

[AIAndy]

The thing is, we are intending to make a 4X game, not a relational database front-end. So while I like some of the ideas here I think we need to keep our eye on the ball as to what our goal is.

While we are trying to make a game, if an abstraction layer and the code below it have uses outside of games then that is a positive trait and it does not mean that it is less useful for a 4X game.

I think that all entities should have properties that change during runtime. We can use abstract entities to define multiple sub-entities (example, Unit could be an abstract entity which can be used in defining Air, Land, Naval, Space, and what have you units, each as separate entity types for relational purposes). This also makes the Topological relations easier (Tile is an abstract entity, and can be used to define hex tiles, square tiles, or whatever we want really in the topological engine). And every property except for ID (and maybe a couple internal properties for the graphics engine) should be modifiable in theory during runtime. And every property should be functional, ie bools can be modified using boolean logic and ints using functions defined in the Entity manager.

I think there is a slight misunderstanding here. Functional properties are properties like this:
CurrentHP = RelativeHP * MaxHP
So CurrentHP is not changed by itself (although I guess you could have modifiers on it), but you change RelativeHP (a variable with values between 0 and 1).

EDIT: Forgot to say something about why I differed between classes and instances (although I am fine if instances can inherit from multiple classes). One big thing in C2C development was that you could change the ruleset and still keep savegame compatibility. That is something I would like to keep in AXXXXE. So it needs to be defined what should be serialized into the savegame and what the ruleset defines (and therefore should not be part of the saved state). That is what the split into classes and instances is supposed to do. Classes are defined in the ruleset and not changed during runtime so any changes to the ruleset will directly apply to them even if you load a savegame. Instances on the other hand are stored in the savegame and once a property is changed on an instance (really changed, not using modifiers), the default value inherited from the class has no effect if the ruleset changes.

I actually agree with Koshling on this point, all relations should only take Entities as parameters. So, for your example, NearTo(Entity A, Entity B) would have what 'near' is defined in the function itself, not as a parameter. Does that lose some flexibility, sure. But, it makes relational management easier to code, and as far as I know you are the only one among us with significant relational database experience.

That is not what I meant. What is the NearTo in your case and why should there only be one? If there is a special NearTo baked into the topology system, the topology system loses part of its abstraction for no gain. There are a lot of possible NearTo relations. Within a distance of X on the other hand is a binary relation similar to NearTo but you specify what you actually want for X and then you can bind it to some alias like NearTo from outside the topology system. What Koshling did not want was a relation like Entity x Entity x Distance but NearTo = Near(5) is a Entity x Entity relation.

This could run into problems. For instance, an entity can not logically have two parent entities given the current entity setup. So relations need to have restrictions on them, both for logical consistency, and for gameplay reasons (maps can not be children of units, etc).

As far as I can tell, this comment has nothing to do with what I wrote in the quote. So probably some misunderstanding.
A relation-bound entity would be something like a special promotion that is added to all units of player X because player X has trait Y and the promotions would be lost again when you lose the trait (so its lifetime is bound to the lifetime of the player has trait relation entry (X,Y)).

The top level entities under Game would be Maps and Players, and under those would be Tiles (from Map), Cities (from player, but related to tiles), and Units (from Player). I would vote for those being defined internally, even though it cuts down flexibility, for the reason I stated above, which is that we are wanting to make a 4X game, not a general relational database program with fancy graphics.

So you want to add pointless restrictions just to avoid that it is usable for other things?

 

[ls612]

As far as I can tell, this comment has nothing to do with what I wrote in the quote. So probably some misunderstanding.
A relation-bound entity would be something like a special promotion that is added to all units of player X because player X has trait Y and the promotions would be lost again when you lose the trait (so its lifetime is bound to the lifetime of the player has trait relation entry (X,Y)).

OK, that makes much more sense, I thought you were saying that any entity should be allowed to have any relation to any other entity, which would not be good IMO.

I think there is a slight misunderstanding here. Functional properties are properties like this:
CurrentHP = RelativeHP * MaxHP
So CurrentHP is not changed by itself (although I guess you could have modifiers on it), but you change RelativeHP (a variable with values between 0 and 1).

Why would we do something like this when we could just say Current HP = X and Max HP = Y, and have those both be changeable by other entities? Adding another variable for that sounds slightly pointless and a waste of memory.

So you want to add pointless restrictions just to avoid that it is usable for other things?

No, I want to make it so that we don't need to reinvent the wheel for many things. I'd assume that this would be open-source, so defining stuff in the engine just means that it would require a patch to change, as opposed to a mod. But I see value in having groundwork laid for rulesets so that each different set doesn't need to redefine Players (or find and copy-paste an existing definition for players). I'm not saying we define the methods and properties of players in the engine, just that we assume their existence there.

 

[AIAndy]

Why would we do something like this when we could just say Current HP = X and Max HP = Y, and have those both be changeable by other entities? Adding another variable for that sounds slightly pointless and a waste of memory.

It is a functional expression, not a variable. No need to have it stored in the instance at all as inheritance lookup will find it in some parent class.
The reason to have the possibility? Abstraction that allows some special classes to overwrite how something is calculated without the need to have all code that uses it know that. It also moves some possibilities for pure calculations into the XML similar to expression tags now.
Maybe a different example will help: Lets assume there are some units that have an air defense property. Most just have a fixed number so the property is set to that number. But there might also be some all purpose high tech unit that has an energy pool that can be directed to different purposes. Now the air defense property depends on the energy settings of the unit. With functionals the property for that unit is just replaced with a functional that calculates the air defense from the energy settings. Without functionals all code that deals with air defense would need to know about the existence of such a unit.

No, I want to make it so that we don't need to reinvent the wheel for many things. I'd assume that this would be open-source, so defining stuff in the engine just means that it would require a patch to change, as opposed to a mod. But I see value in having groundwork laid for rulesets so that each different set doesn't need to redefine Players (or find and copy-paste an existing definition for players). I'm not saying we define the methods and properties of players in the engine, just that we assume their existence there.

And assuming their existence would gain us what?
Modular rulesets will allow to have some fundamental definitions easily included into each ruleset without making some parts of them special and moving them to where they don't belong.

 

[AIAndy]

As suggestion I have made a simple possible component diagram for the lower layers. Connections to the upper layers and probably some other things are still missing.

 

[Laskaris]

I've been thinking about this, and I'm starting to think that rendering the tiles as globes natively would be more effort than it would be worth. Making flat maps makes the math behind this much easier and gives far more flexibility in both workable map sizes and different topological systems. Is it slightly less realistic, sure a little. But it makes things much more of a hassle and involves wierd shaped tiles in almost all cases, and besides, how much stuff do you think will be happening at the poles during the game? (before modern nuclear subs, but that can be handled by map wrapping.)

A globe does not just allow action to happen around the poles (which would indeed be a relatively minor advantage). It allows for a much more consistent / realistic modelling of area sizes, distances and directions all across the map than a flat map would. This means more realism in city building or occupying tiles (because all tiles actually represent the same area size), more realism in unit movement and speed (because distances from one tile to the next are the same all across the map), and so forth.

Yes, the math is a bit more complicated than with a flat map, but not overly so - I think it's quite doable. Moreover, I think some of the recent comments in this thread have made the discussion about the map more complicated than it really needs to be. "Dual-overlay approaches", "inverted hexagons"... That's all pretty confusing, at least to me.

I think there is a good reason why scientists who model the Earth's climate use exactly the "twenty-sided die covered with x hexes and 12 pentagons" approach which primem0ver and I described earlier: because it is the easiest way to tile a globe. So, if we are going to give globes a try (which I very much hope we will do), my suggestion would be to just use that approach, keep it simple, and things will probably work fine.

 

[Laskaris]

It's probably a bit early in the development to suggest this. But as the project makes progress and takes on shape, it would be great to eventually have a separate forum for it, so that distinct issues can be discussed in distinct threads instead of lumping them all together in one and the same thread.

In the meantime, I hope you all had happy holidays, and I wish you a good transition into the new year!

 

[ls612]

It's probably a bit early in the development to suggest this. But as the project makes progress and takes on shape, it would be great to eventually have a separate forum for it, so that distinct issues can be discussed in distinct threads instead of lumping them all together in one and the same thread.

In the meantime, I hope you all had happy holidays, and I wish you a good transition into the new year!

I asked The_J about this a while ago, and the response was that once we had some measurable progress to show that he could probably get the admins to give us a forum then.

 

[Alex Costa]

I asked The_J about this a while ago, and the response was that once we had some measurable progress to show that he could probably get the admins to give us a forum then.

Well then I guess work has to be done than. But I suspect you all wanna wait until the new year right?

 

[ls612]

Well then I guess work has to be done than. But I suspect you all wanna wait until the new year right?

Certainly until Koshling gets back and starts on this.

 

[GiuseppeIII]

This really looks amazing. Even though for only a few people making a game engine would take for ever so I would suggest getting some more people to help creat this game...

 

[primem0ver]

If I am understanding the entirety of this discussion correctly, I feel the need to point something out that we may be overlooking as we discuss these matters. As we talk about these issues we need to keep in mind that we are discussing two separate but related projects. Let us not talk past one another because we are confusing one for the other (or speaking of them both as one entity). I myself in a sense have shared in this error (see my side note). Here are the two projects we are actually discussing:

1. The first project is the AXXXXE engine that Koshling proposed which would be theoretically usable by anyone who wants to develop a 4X game.
2. The second project is the game we all seem to have in mind (loosely based on C2C). This project is a specific set of entities etc that make use of the AXXXXE engine (an instance/implementation of the engine).

I think it is important that we keep this distinction in mind for future posts (and discussions if/when this becomes a forum).

SIDE NOTE (EXAMPLE): some of the map issues are an example of not taking this separation into consideration. The specific type of map used is not an issue for the engine itself (ordinarily). It is an issue of the implementation (the instance or the game we have in mind). The only map issue that we have discussed so far that IS an issue for the engine is the existence of a third spatial dimension (specifically Z). If we want to make this engine available to 3D 4X space games then we need to incorporate the 3rd spatial dimensions into its design. Only if we decide "NO" to the that last question does our current discussion over "spherical" versus "non-spherical" become relevant to the engine itself.

 

[AIAndy]

If I am understanding the entirety of this discussion correctly, I feel the need to point something out that we may be overlooking as we discuss these matters. As we talk about these issues we need to keep in mind that we are discussing two separate but related projects. Let us not talk past one another because we are confusing one for the other (or speaking of them both as one entity). I myself in a sense have shared in this error (see my side note). Here are the two projects we are actually discussing:

1. The first project is the AXXXXE engine that Koshling proposed which would be theoretically usable by anyone who wants to develop a 4X game.
2. The second project is the game we all seem to have in mind (loosely based on C2C). This project is a specific set of entities etc that make use of the AXXXXE engine (an instance/implementation of the engine).

I think it is important that we keep this distinction in mind for future posts (and discussions if/when this becomes a forum).

SIDE NOTE (EXAMPLE): some of the map issues are an example of not taking this separation into consideration. The specific type of map used is not an issue for the engine itself (ordinarily). It is an issue of the implementation (the instance or the game we have in mind). The only map issue that we have discussed so far that IS an issue for the engine is the existence of a third spatial dimension (specifically Z). If we want to make this engine available to 3D 4X space games then we need to incorporate the 3rd spatial dimensions into its design. Only if we decide "NO" to the that last question does our current discussion over "spherical" versus "non-spherical" become relevant to the engine itself.

If we implement my suggestion then most parts of the code won't care about coordinates at all but instead the topological relations provided by the topology system will be used.
That system takes topology definitions and creates the plot entities and their connections. An explicit relation is used to specify on which plot the units are and then you can use the derived topological relations on the plot entities for game rules.