Caveman 2 Cosmos (ideas/discussions thread)

Found this:

DOM

  • Tree model parser (Object based) (Tree of nodes).
  • DOM loads the file into the memory and then parse- the file.
  • Has memory constraints since it loads the whole XML file before parsing.
  • DOM is read and write (can insert or delete nodes).
  • If the XML content is small, then prefer DOM parser.
  • Backward and forward search is possible for searching the tags and evaluation of the information inside the tags. So this gives the ease of navigation.
  • Slower at run time.
SAX
  • Event based parser (Sequence of events).
  • SAX parses the file as it reads it, i.e. parses node by node.
  • No memory constraints as it does not store the XML content in the memory.
  • SAX is read only i.e. can’t insert or delete the node.
  • Use SAX parser when memory content is large.
  • SAX reads the XML file from top to bottom and backward navigation is not possible.
  • Faster at run time.
I bolded out that which I consider most significant for our case and have to say that we should keep the SAX format.
The memory part probably ain't an issue as this only happens during game launch and then is cleared from ram after the xml parsing is complete.
However, it doesn't sound like the best implementation imo, considering the sizes of some of our xmls.
The speed issue is what I care about in this case, which may be significant considering the amount of xml we load into this game.
 
Last edited:
They are different approaches to parse the XML tree. Unfortunately, the XML Utility tells xerces to use the DOM model (xerces has the option to use SAX, though). It's well over my limit, to try to convert the utility to use SAX. The aspects are a lot different and I'll need to read the SAX specs thoroughly for this project for there is little code sample I can mimic. Although SAX consumes the documents in small chunks, I'm afraid it's the total amount that eventually matters.
  • SAX reads the XML file from top to bottom and backward navigation is not possible.
This disables us to traverse from children nodes back to their parents, and we'll have to store the parent nodes on the stack, which is over my technical limit and we'll eventually reach an implementation that's already done in DOM parser (and much better done).
 
Last edited:
They are different approaches to parse the XML tree. Unfortunately, the XML Utility tells xerces to use the DOM model (xerces has the option to use SAX, though). It's well over my limit, to try to convert the utility to use SAX. The aspects are a lot different and I'll need to read the SAX specs thoroughly for this project for there is little code sample I can mimic. Although SAX consumes the documents in small chunks, I'm afraid it's the total amount that eventually matters.
I see, I thought we were using SAX already.... Forget what I said then, I'm out of my depth on this matter anyway. ^^
 
It does, but after I got TB to add the unit that settles the city as an argument to the python function call event that happens every time a city is built, I switched out the xml implementation with a python implementation that looks like this:
for iPromo, iBuilding in gCultureList:
if -1 in (iPromo, iBuilding): continue
if CyUnit.isHasPromotion(iPromo):
CyCity.setNumRealBuilding(iBuilding, 1)​

In that modmod I have changed how cultures spread a lot, so if you for example is playing an African civ and conquer an European city where you then train a settler, the new city that settler found will gain the European culture instead of the African culture.
Several cultures can accompany a settler from the city it is trained in, but only cultures that exist locally in that city, spreading new local cultures to a city requires the new culture to be adopted by your civ nationally. When you get enough foreign local cultures a specific autobuild will appear that signifies that that new culture has been adopted.
It's all a bit complex though, there's a local culture building that can be built if the culture is active in your civ, a native culture building, an adopted culture building, and an active culture building, as well as a special version of the native culture building that follows the palace around based on what civ you started your game with. One of each of those buildings exist per native culture type in the game. ^^

@Anq: I'm still not convinced that it's a good idea to use the DOM format for any tags that use the expression system...
Is it possible to mix the current format and the DOM format so that some tags use DOM while others, like those with the expression system, keep the current format?
Some of them can be quite complex like this one:
Spoiler example from C2C :
Code:
                <PropertyPropagator>
                    <PropertyPropagatorType>PROPERTYPROPAGATOR_DIFFUSE</PropertyPropagatorType>
                    <PropertyType>PROPERTY_WATER_POLLUTION</PropertyType>
                    <GameObjectType>GAMEOBJECT_PLOT</GameObjectType>
                    <TargetObjectType>GAMEOBJECT_PLOT</TargetObjectType>
                    <TargetRelationType>RELATION_NEAR</TargetRelationType>
                    <iTargetDistance>1</iTargetDistance>
                    <iPercent>4</iPercent>
                    <TargetCondition>
                        <Or>
                            <Is>TAG_WATER</Is>
                            <Is>TAG_FRESH_WATER</Is>
                            <Is>TAG_CITY</Is>
                        </Or>
                    </TargetCondition>
                    <Active>
                        <Not>
                            <Or>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_OCEAN</ID>
                                </Has>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_OCEAN_TROPICAL</ID>
                                </Has>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_OCEAN_POLAR</ID>
                                </Has>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_TRENCH</ID>
                                </Has>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_TRENCH_POLAR</ID>
                                </Has>
                                <Has>
                                    <GOMType>GOM_TERRAIN</GOMType>
                                    <ID>TERRAIN_TRENCH_TROPICAL</ID>
                                </Has>
                            </Or>
                        </Not>
                    </Active>
                </PropertyPropagator>
Condensing that stuff too much will be horrific to work with, both to read and to write.
Does this mean that the problem with the AI not having the information about the unit that creates a city has been fixed?
 
Does this mean that the problem with the AI not having the information about the unit that creates a city has been fixed?
No, but I don't see why the AI needs to be aware of an automatic system that not even the human player have a shred of control over.
The human player can however plan out better how to spread specific cultures than the AI can by training the settler in the appropriate city, while the AI will not consider what cultures the city has before deciding where to train a settler.
But the same is true for so much else in this game, e.g. the AI doesn't build only military wonders in one city to make a super unit producing city. It's rather quite random what wonders an AI put in a specific city and no planning on which wonders may have strong synergy effects together if in the same city.
 
Last edited:
We had to remove a mod based on the unit that built a city because it did not work for the AI. The unit building the city was not available to Python if it was the AI's action. Only when the Player built a city was the unit info available to Python.
 
We had to remove a mod based on the unit that built a city because it did not work for the AI. The unit building the city was not available to Python if it was the AI's action. Only when the Player built a city was the unit info available to Python.
You probably used a different python event call then, like the "cityAquired" event, I know some of those events only fires for the human player.
The "cityBuilt" python event fires when the AI build cities, I checked that in-game.
I use the same method to award the tribal guardian to the first city in PPIO too, with a promotion on the settler that builds it. That is because I made it so that if the capital is demolished the tribal guardian is removed and represented as a promotion on the settler unit that appear when you demolish a city. This made sense as the Tribal Guardian cannot move, but if you want to move your first and only city in the start of the game it would be strange to leave the tribal guardian standing around where the city once was. All the AI does get a Tribal Guardian in their capital with PPIO.
 
Last edited:
No "we", I got the mod from a reputable source, used the "cityBuilt" event. The problem (Platyping pointed out the problem) was that the method of getting the unit that built the city (something like "get selected unit") returned a null if it was the AI but the unit if it was the player. This meant that it looked like it was working when testing, if you forgot to check what was happening in the AI cities.
 
No "we", I got the mod from a reputable source, used the "cityBuilt" event. The problem (Platyping pointed out the problem) was that the method of getting the unit that built the city (something like "get selected unit") returned a null if it was the AI but the unit if it was the player. This meant that it looked like it was working when testing, if you forgot to check what was happening in the AI cities.
That's because the AI doesn't actually select units.
The problem you pointed out there was pretty much the whole reason why I wanted TB to add the unit as argument to the python call event, so that settler promotions could be used to define the new city in some way.

There was another way to do this before the unit was added as an argument.
One could loop through all the units on the plot until a settler was found and use its promotions for the city, but this was a crude method, not very elegant, because if there were more than one settler on the plot this code would simply pick the first it found regardless of which settler actually founded the soon to be new city.
 
Last edited:
About "Buildings make themselves cheaper" as written here.
It should be the other way around. Such mechanics was implemented in Alpha Centauri game: prototype. First unit created was prototype and had a cost like +10% to normal unit cost.
Same is in real life. Prototypes are always more expensive. Later building algorithms are improved and units (or buildings) become cheaper. But only to a certain point. You still have to spend certain amount of materials and labor to make something. Even if it has been made before many times.

So suggestion is to make first unit or building a prototype, requiring +10...+15% more :hammers:. All later same units/buildings will require normal amount of :hammers:.
 
About "Buildings make themselves cheaper" as written here.
It should be the other way around. Such mechanics was implemented in Alpha Centauri game: prototype. First unit created was prototype and had a cost like +10% to normal unit cost.
Same is in real life. Prototypes are always more expensive. Later building algorithms are improved and units (or buildings) become cheaper. But only to a certain point. You still have to spend certain amount of materials and labor to make something. Even if it has been made before many times.

So suggestion is to make first unit or building a prototype, requiring +10...+15% more :hammers:. All later same units/buildings will require normal amount of :hammers:.
Most of that strikes me as semantics and otherwise the same as what was done. However, the last statement clarifies the difference and I think, in general, I do agree. The cheapening can only take place so much before it hits a plateau of optimum expense. Not sure how it's implemented now but that consideration should be kept in mind, as you suggest. It also makes some sense to say it's just the first one or two that are MORE expensive rather than making further ones beyond that LESS expensive, though that may be DH's reaction to his sense of the baseline expense being what he feels is generally high.
 
About "Buildings make themselves cheaper" as written here.
It should be the other way around. Such mechanics was implemented in Alpha Centauri game: prototype. First unit created was prototype and had a cost like +10% to normal unit cost.
Same is in real life. Prototypes are always more expensive. Later building algorithms are improved and units (or buildings) become cheaper. But only to a certain point. You still have to spend certain amount of materials and labor to make something. Even if it has been made before many times.

So suggestion is to make first unit or building a prototype, requiring +10...+15% more :hammers:. All later same units/buildings will require normal amount of :hammers:.

This is what I wanted to do but it is not possible with simple XML coding that will be visible to the AI.
Most of that strikes me as semantics and otherwise the same as what was done. However, the last statement clarifies the difference and I think, in general, I do agree. The cheapening can only take place so much before it hits a plateau of optimum expense. Not sure how it's implemented now but that consideration should be kept in mind, as you suggest. It also makes some sense to say it's just the first one or two that are MORE expensive rather than making further ones beyond that LESS expensive, though that may be DH's reaction to his sense of the baseline expense being what he feels is generally high.
I have no problem with the current costs of buildings. I wanted to see if doing this was meaningful and possible. I should not have put it in the XML. Certianly not in the World View module and I will remove it.

To gereralize it we would need a new tag set. Possible just a bPrototypeCostsMore and then just use the same adjustment values for all buildings or a group PrototypeCosts with elements PrototypeCostPercent. The number of entries would allow for any number of prototypes. It would contain the % increase in cost for that building and when the list runs out there is no increase.
EG for a building that requires 3 prototypes before the cost becomes the same as in the iCost field
<PrototypeCosts>
<PrototypeCostPercent>15</PrototypeCostPercent>
<PrototypeCostPercent>10</PrototypeCostPercent>
<PrototypeCostPercent>0</PrototypeCostPercent>​
</PrototypeCosts>​
 
I have no problem with the current costs of buildings. I wanted to see if doing this was meaningful and possible. I should not have put it in the XML. Certianly not in the World View module and I will remove it.

To gereralize it we would need a new tag set. Possible just a bPrototypeCostsMore and then just use the same adjustment values for all buildings or a group PrototypeCosts with elements PrototypeCostPercent. The number of entries would allow for any number of prototypes. It would contain the % increase in cost for that building and when the list runs out there is no increase.
EG for a building that requires 3 prototypes before the cost becomes the same as in the iCost field
<PrototypeCosts>
<PrototypeCostPercent>15</PrototypeCostPercent>
<PrototypeCostPercent>10</PrototypeCostPercent>
<PrototypeCostPercent>0</PrototypeCostPercent></PrototypeCosts>
Well that's the other issue, that you're working with what you have available to you and you can't be faulted if it's only slightly flawed as a result. Is there any way to limit how effective the cost reduction is? I'm not sure how you went about it. I don't actually disagree with the concept but I can't say I'd be able to address a new tag any time soon.
 
EG for a building that requires 3 prototypes before the cost becomes the same as in the iCost field
<PrototypeCosts>
<PrototypeCostPercent>15</PrototypeCostPercent>
<PrototypeCostPercent>10</PrototypeCostPercent>
<PrototypeCostPercent>0</PrototypeCostPercent>​
</PrototypeCosts>​
I don't think a tag like this is worth the extra RAM usage per building, buildings already have a bit too many properties as it is, another tag for it would have to bring something quite valuable to the gameplay experience to be worth it.
I think the abstraction of building costs we currently have is an adequate simulation of cities productivity effort.
The new suggested tag may not even make it all that much a more precise simulation.
Building schools/hospitals/railway/factories is not really a production line, where the next one is a simple continuation of the last one.
Each construction job is unique, we still make prototype for every building we build through models and blueprints, the first school built in a country may very well be much cheaper than the last school built in that nation even though it may not really be less effective as a school than the last one will be.
The first school may have been a simple re-purposing of an old building (like a city hall) which came at a low building cost while the last one may be an overambitious project built in difficult terrain with difficult building materials, without actually resulting in a better school than the first one did.

I consider the small scale prototypes, or proof of concept, of buildings to already have been built in a nation during the turns you were inventing the tech that allows those buildings, so that when you as a player can actually build these buildings in your cities they have already existed in your nation on an experimental low scale for a limited time before you can actually build them for real in cities.

If this tag had been implemented for units then it may also make sense to make sure that the first couple of units built have less strength than those trained later as they may have inferior equipment that break down and is harder to maintain, and because their training was worse than those trained later when the military found out how to properly train someone to use the newest equipment in a combat situation.

This concept makes more sense for volumetric resources, that there should be some inertia in how many turns it takes before you get the full amount of resources from an improved map resource or from a building that provides manufactured bonuses after they started functioning.

This is just my (long) opinion stated for the record, I won't protest on the matter if someone decides to actually implement the suggested tag.
 
Maybe just drop the concept of building becoming gradually cheaper altogether? We can pretend that higher :hammers: cost of first buildings is leveled out by lower cost of subsequent buildings. So every same type building has the same cost.
 
@Thunderbrd or @Toffer90 When city grows it assigns specialist at some point of growth.

Is it possible to make city assign specialist to least used job where applicable?
Citizen would be fall back if all other places were filled.
Civ4BeyondSword 2019-06-06 13-15-04-28.png

In this case I have civics that let unlimited amount of artists and priests.
Here at next pop city should assign artist.
 
@Thunderbrd or @Toffer90 When city grows it assigns specialist at some point of growth.

Is it possible to make city assign specialist to least used job where applicable?
Citizen would be fall back if all other places were filled.
View attachment 526110
In this case I have civics that let unlimited amount of artists and priests.
Here at next pop city should assign artist.
Not really because then you're messing with the AI's assignment of civics, which the player cities use unless you override it. That process is a matter of finding the most valuable assignment, among all the options and tags and some other predictive reasoning, for the next specialist. If we change it for the player, it would change it for the AI. The formula needs updating now and then and I've been trying to figure out how to update it for the XP they bring but so far have struggled to create valid syntax for that. Probably was a little too inexperienced when I was trying it last and should look into it again but I'm having trouble asking the city what it currently has queued.
 
I was told to post it here. Some ideas I had whilst playing C2C for the first time.

The new Civic

There's language civic in the mod, I think writing civic could be added too.

No Writing - Starting Civic - +1 unhappiness, -20% culture, -20% science, +20% espionage, +25% maintenance cost from distance to the palace, damages relations with civilizations using any other writing civic by 3 points

Cave Paintings - requires Petroglyphs tech, no anarchy time if changed from earlier civics - -10% culture, -10% science, +15% espionage, +20% maintenance cost from distance to the palace, damages relations with civilizations using any other writing civic by 2 points except Petroglyphs

Petroglyphs - requires Petroglyphs tech AND Carving tech, no anarchy time if changed from earlier civics - -5% culture, -10% science, +10% espionage, +20% maintenance cost from distance to the palace, damages relations with civilizations using any other writing civic by 2 points except Cave Paintings

Pictograms - requires Pictographs tech, no anarchy time if changed from earlier civics - +10% espionage, +15% maintenance cost from distanceto the palace, damages relations with civilizations using any other writing civic by 1 point

Ideograms - requires Ideograms tech, no anarchy time if changed from earlier civics - +10% culture, +10% science, +15% espionage, +10% maintenance cost from distance to the palace, damages relations with civilizations using any other writing civic by 1 point

Native Script - requires Writing tech, no anarchy time if changed from earlier civics - +20% culture, +20% science, +20% espionage, +5% maintenance cost for number of the cities, damages relations with ALL other civilizations by 1 point, improves relations with civilizations using Language Education civic by 1 point

Logographic - requires Scriptures tech, no anarchy time if changed from earlier civics, short anarchy if changed from Syllabic, Alphabetic, Abugidic, Abjadic, Featural, and later civics - +15% culture, +20% science, +25% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Abjadic - requires Linguistics tech, no anarchy time if changed from earlier civics, short anarchy if changed from Syllabic, Alphabetic, Abugidic, Logographic, Featural, and later civics - +20% culture, +25% science, +15% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Alphabetic - requires Alphabet tech, no anarchy time if changed from earlier civics, short anarchy if changed from Syllabic, Logographic, Abugidic, Abjadic, Featural, and later civics - +25% culture, +20% science, +15% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Abugidic - requires Code of Laws tech, no anarchy time if changed from earlier civics, short anarchy if changed from Syllabic, Alphabetic, Logographic, Abjadic, Featural, and later civics - +15% culture, +25% science, +20% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Syllabic - requires Paper tech, no anarchy time if changed from earlier civics, short anarchy if changed from Logographic, Alphabetic, Abugidic, Abjadic, Featural, and later civics - +20% culture, +15% science, +25% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Featural - requires Education tech, no anarchy time if changed from earlier civics, short anarchy if changed from Syllabic, Alphabetic, Abugidic, Abjadic, Logographic, and later civics - +25% culture, +15% science, +20% espionage, damages relations with civilizations using any other writing civic by 1 point, improves relations with civilizations using Language Education civic by 1 point

Now it gets hard, but let's see...

Binary - requires <SomeFutureTech> - "Your Civilization uses pure information as writing system" - no anarchy time if changed from earlier civics - +40% culture, +40% science

Post Writing - requires <SomeFutureTech2> - "Your Civilization no longer has a need of writing system" - no anarchy time if changed from earlier civics - +50% culture, +50% science

Since there's a chunk of civics with similar bonuses (Logographic, Abjadic, Alphabetic, Abugidic, Syllabic, Featural), existing civilizations should have a preference for one of them.
Aboriginal - Alphabetic
Arabian - Abjadic
Assyrian - Logographic, Abjad, Syllabic
Australian - Alphabetic
Aztec - Pictograms, Ideograms, later Alphabetic
Babylonian - Logographic, will switch to Syllabic
Brazilian - Alphabetic
Byzantine - Alphabetic
Carthaginian - Abjadic
Celtic - Alphabetic
Chinese - Logographic
Denmark - Alphabetic
Dutch - Alphabetic
Egyptian - Logographic, Syllabic, Abjadic, Alphabetic ¯\_(ツ)_/¯
English - Alphabetic
Ethiopian - Abjadic, then switches to Abugidic if possible
French - Alphabetic
German - Alphabetic
Greek - Alphabetic
Hittite - Logographic or Syllabic
Holy Roman - Alphabetic
Incan - Native Script, Alphabetic
Indian - Abugidic
Iroquois - Alphabetic, Syllabic
Israeli - Abjadic
Japanese - Logograpic, then switches to Syllabic if possible
Jivaro - Alphabetic
Khmer - Abugidic
Korean - Logographic, then switches to Featural if possible
Malian - Abjadic, might switch to Alphabetic
Maori - Alphabetic
Mayan - Prefers Syllabic, might use Logographic, if pressured might switch to Alphabetic
Mongolian - Logographic, Syllabic, Abugidic, Alphabetic ¯\_(ツ)_/¯
Native American - Alphabetic
Ottoman - might switch freely between Alphabetic and Abjadic. Prefers Alphabetic, but should switch to Abjadic if religion is Islam
Persian - Logographic, Syllabic, Abjadic, Alphabetic ¯\_(ツ)_/¯
Polynesian - Native Script, Alphabetic
Portugal - Alphabetic
Roman - Alphabetic
Russian - Alphabetic
Siamese - Abugidic
Spanish - Alphabetic
Sumerian - Logographic, Syllabic
Tupi - Alphabetic
United States - Alphabetic
Viking - Alphabetic
Zulu - Alphabetic

New Wonder and Group Wonders

I have a few ideas for new buildings.

New Wonder - Malbork Castle (Castle of the Teutonic Order in Malbork) - biggest castle in the world, almost twice as big as the second biggest Mehrangarh Fort (arguably not a castle) and well over twice as big as third biggest Prague Castle. Surely it means it's worthy being a wonder? Would require State Religion in the city and Castle obviously, would add small defence bonus, some culture and tourism bonus and some bigger religion based bonus. I think giving Knights built in the city a special promotion allowing them to act like Missionaries and spread religion sounds about right. Could also allow them to act like Inquisitors. Would go obsolete with no State Religion except for culture/tourism bonus.

And new Group Wonders - Early Steel Alloys. They would all go obsolete with Gunpowder. Keep in mind effects are presented to roughly explain the idea, and as such are not exactly balanced.

ESA Bone Steel - requires Bones and Iron - Cost to build = BoneSteelCost (placeholder, will be used for comparison with others), +1 XP to melee units, +1 XP to hunter units
ESA Celtic Steel - requires Charcoal or Coal, Iron, and Aesthetics tech - Cost to build = BoneSteelCost, +1 gold, +1 culture
ESA Seric Steel - requires Bamboo, Charcoal or Coal, and Iron - Cost to build = 2*BoneSteelCost, +2 XP to melee units, +2 gold
ESA Noric Steel - requires Peak, Charcoal or Coal, and Iron - Cost to build = 1.5*BoneSteelCost, +1 XP to melee units, +1 hammer, +5% military unit production
ESA Damascus Steel - requires Desert, Charcoal or Coal, and Iron - Cost to build = 2.5*BoneSteelCost, +2 XP to melee units, +1 gold, +1 culture (culture bonus does not go obsolete)
ESA Bulat Steel - requires Charcoal or Coal, Iron and Horses (eventually other mountable animals) - Cost to build = 1.5*BoneSteelCost, +1 XP to melee units, +1 XP to mounted units (mounted bonus does not go obsolete), +5% military unit production
ESA Margiana Steel - requires Silk, Charcoal or Coal, and Iron - Cost to build = BoneSteelCost, +1 culture, +10% defensive bonus
ESA Ferghana Steel - requires Silk, Charcoal or Coal, and Iron - Cost to build = 1.5*BoneSteelCost, +1 XP to melee units, +1 gold, +1 culture
ESA Cizhou Steel - requires Prime Timber, Charcoal or Coal, and Iron - Cost to build = 1.5*BoneSteelCost, +1 gold, +1 hammer
ESA Bintie Steel - requires Coal, and Iron - Cost to build = BoneSteelCost, +1 XP to melee units, +1 gold
ESA Termit Iron - requires Terracotta Wares, and Iron - Cost to build = BoneSteelCost, +1 culture
ESA Tamahagane Steel - requires Charcoal, Iron, and Feudalism tech - Cost to build = 1.5*BoneSteelCost, +1 XP to melee units, +1 culture (culture bonus does not go obsolete)
ESA Iberian Steel - requires Prime Timber, Charcoal or Coal, and Iron - Cost to build = BoneSteelCost, +1 XP melee units, +1 XP mounted units

These are only rough ideas.
 
Last edited:
The civic concept is cool in that it represents some things we don't currently represent except by tech advancement. I think it may have to be a lot more subdued and the more advanced forms would need to take a LONG anarchy period to switch to. We can't even get the US to go metric - imagine switching away from an alphabet.

A super futuristic version for this could be Akashic Symbolism. The Akashic library is an Asian concept that suggests that there is a divine 'place' where all knowledge and records of every experienced moment are stored in symbolic form, suggesting that there is a Universal 'divine' symbol language that may be yet to be discovered - rather than invented since it came to be at the dawn of being. If we learned the meanings of this symbol system, that could be quite a civic in this category.

This also brings to mind the way the aliens wrote in that movie about making contact that came out in the last few years where they wrote in a symbolic language of circles... we could try to capture that idea into this as well.


I like the wonders and the group wonders could play well into equipment.

I've said much of this on Discord with you but I'm curious to see what the opinions of others are on these subjects. You may need to take them out of a link and post them in full here to get more commentary.
 
Top Bottom