That means, requirements are put in the selector part, and effects/enablers are put in the rule part. The difference between CRS and CSS is that in CSS the rules are alternative (one with the most relevant selector, or the latest one with equal top relevance, is applied), amd we need some additive effects. We can circumvent it without much syntax change by defining named effect properties, so that effects with same name and type are alternative and effects with same type but different names are additive:
Code: Select all
* {City_Vision_Radius_Sq: 5;}
player[tech |= "Electricity"]{City_Vision_Radius_Sq#cityvis_elec: 5;}
Code: Select all
* {City_Vision_Radius_Sq: 5;}
player[tech |= "Electricity"]{City_Vision_Radius_Sq: 10;}
To construct selectors, we need some Game Object Model (GOM) that represents the game as things of different types nested into each other in some order and having attributes; such objects can have uniform class and name system replacing current various flags, classes and roles. While current req contexts are "flat", GOM may have a logical structure that allows to unify definitions of effects, action enablers and more:
Code: Select all
World
+ Player
|
+ Tile
|
+ Extra
|
+ Output_Type
|
+ City
| |
+--+ Unit
| |
| + Unit_Type
| |
| + Unit (cargo)
| |
| + Action
| |
| + (action target)
|
+ Specialist
|
+ Building