There is a fairly simple extension to the notion of commodities (aka Output_Type) that would IMO solve most of the issues you have with Civ III and a host of others as well with current fc rulesets.
It would be dead easy to count things e.g.
Code: Select all
[effect_count_banks]
type = "Output_Add_Tile"
value = 1
reqs =
{ "type", "name", "range"
"Building", "Bank", "City"
"OutputType", "Bank_Counter", "Local"
"CityTile", "Center", "Local"
}
Such commodities would be defined in game.ruleset with some additional fields:
Code: Select all
[Commodity_bank_counter]
Commodity = "Bank_counter"
Persistent = FALSE ; i.e. ephemeral - not accumulating turn by turn
Box_size = 5
Roll_up = <range> ; in this case "Player" (the parser could actually figure this out)
Under = <event_under> ; not needed in this case
Full = <event_full> ; in this case "Banks_5"
amongst others.
With this approach one could get rid of a slew of special purpose commodities/counters that are current and proliferating.
Current candidates would be
- Field military "unhappiness" upkeep
Both types of pollution. A real advantage here is that one could soften the relation between source (Shields or pop) and pollution - e.g. one might want forests to have low pollution,while coal mines are a little more - these easily done with tile effects.
Definition of what makes citizens H/C/U/A
Definition of what makes a city H/C/U (both of these are especially relevant to solving CMA problems)
City Growth/famine
Tech discovery/loss
Forced building selloff
Forced disbanding of unsupported units
New feature of "Goods"
New feature of "Culture"
Ultimately, one would want to soften the existing commodities (F/P/T - G/L/S) but that raises some issues concerning binding to current hard coded features (e.g. tax office).
The "events" - under/full etc. would also need to be defined, but these could then be directly referenced in a reqs predicate:
Code: Select all
;buildings.ruleset
[building_wall_street]
name = _("Wall Street")
genus = "SmallWonder"
reqs =
{ "type", "name", "range"
"Condition", "Banks_5" "Player"
}
In my view your point about AI (and therefore also AGH) is critical. I would be interested in your opinion as to whether this scheme would be more difficult than your filters. Aside from that I think this general approach would simplify the ruleset name space (removing many effect types), and at the same time provide a great deal more flexibility.