Cascade Rule Sheets (CRS)

[Ignatus]

Just a fantasy about where ruleset format may go for better readibility and flexibility than current requirement system. What about CSS-like definitions?

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;}

that is equivalent to

Code: Select all

* {City_Vision_Radius_Sq: 5;}
player[tech |= "Electricity"]{City_Vision_Radius_Sq: 10;}

We could also have some XML-like structure listing named effects so that nested effect descriptors are multiplicative.

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

Also, we may use pseudo-elements like :owner or :supported.