Summary: City production discount effect
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Mon 26 May 2014 15:15:12 BST
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 



(I think this idea came out of a conversation on IRC.)

Proposal: an effect which allows a city's shield production to contribute more
or less (usually more) towards the current project, depending on
circumstances. For instance, double production rate of Horsemen if city has
access to Horse resource.

; Without this no production is possible!
type    = "Production_Bonus"
value   = 100

type    = "Production_Bonus"
; additional 100% => 200% total
value   = 100
reqs    =
    { "type", "name", "range"
      ; only affects production of Horsemen
      "UnitType", "Horsemen", "Local"
      ; resource anywhere on city map
      "Resource", "Horse", "City"

This would be one step towards merging the different types of Aqueducts in
civ2civ3 into a single building.

This is preferable to trying to affect an item's intrinsic shield cost,
because of the many other things that's used for (bribe cost, sell/disband
yield, upgrade cost, ...) and difficulties if the requirements for the
discount come and go during (or after!) production.

However, the accounting is still quite fiddly to avoid exploits, hence the
length of this proposal. The attached sort-of-flowchart illustrates my

I think this should be checked and applied each turn right before adding the
modified shield increment to the city's production box. It's different from an
output bonus in that it doesn't affect shield output displayed in the city
dialog, and can be targeted at specific production with requirements like
"UnitType", "Horsemen", "Local".
* But how to handle change of production? I do want that if the requirements
only apply half the time during construction, you get half the discount; but I
don't want you to be able to apply a discount to a normally-undiscounted item
by building the cheap one and changing at the last minute; nor do I want that
you can get a "backlog" of discount if you only got the discount requirement
near the end of production, by changing from something else.
** Maybe if the city keeps a running total of "real" underlying shields that
went in, as well as progress towards current target, and if you change
production then you transfer value based on the value of the "real" shields
with no discount.
*** Probably don't need new UI to see "real" shields in city, since you can
explore it by changing production; if you don't like the exchange rate you can
change back without penalty.
*** Does mean that you can't change between two items with the 'same' discount
(say, if discount applies to all air units) and keep it, but tracking which
discounts are the 'same' is hard, especially given history of
possibly-different discounts. If this is a problem I think we solve it by
having a separate Production_Bonus_Transferable effect, which is applied
earlier and really does change the 'underlying' shields; more suitable for
broad classes of units, but subject to these loopholes (the ugly name and a
big health warning should clue ruleset authors into this).
* How to handle surplus production built up while unable to finish item (e.g.
Settlers with insufficient city size)? Don't want any current discount to
carry over to next item when it's built. I think it's probably sufficient to
stop applying the discount when progress has reached 100%, with some sort of
pro-rata arrangement for shields produced in the turn where we cross the
** What if next item on worklist would be eligible for a discount while
building up a surplus? I think it's OK to check the discount and apply it to
the surplus only when we actually start work on the new item. However, for
non-transferable discount, if the previous item is changed while building up a
surplus, perhaps the surplus should get no discount when the next item is
started: this prevents the exploit of working on unbuildable Settlers with
Horsemen on worklist while waiting for access to horse resource, building up a
big surplus, then changing from Settlers to something else and getting the
surplus discounted for the Horsemen as if you'd had access to the resource for
the whole time you were building up the surplus. Still exploitable if you can
choose when to unblock Settlers another way (e.g. by changing food surplus)
but I think we'll have to live with that (alternative is to peek ahead on
worklist, I think).

Buy cost should probably be based on proportion of progress towards current
goal multiplied by nominal shield cost, rather than underlying shield

I don't think this bonus should contribute to pollution. It represents
increased efficiency of production.

Some other issues to be resolved:
* Don't want to create an incentive to build things at a discount just to
disband/sell them at full price.
** Can't rely on requirements for discount still applying at sell time, so
can't reduce sell price that way.
** One solution would be to remember how many shields were 'really' used for a
unit/building. But that creates an opportunity for micromanagement (track the
'cheap' Horsemen and make sure to disband them last), UI to see build cost,
extra data to track for buildings, etc, so I don't like it.
** Another is for ruleset authors to change disband/sell yield for
discountable items, using patch #4721.
*** If discount is really based on 'unchanging' requirement such as nation,
author can simply change sale price in accordance with discount.
*** If discount is mutable (e.g. based on access to resource when built),
probably best to either completely remove resale value (set to 0%), or reduce
it globally for unit in accordance with lowest possible real shield cost. This
is a bit of a blunt instrument -- if you discount for access to a wonder, all
Horsemen everywhere lose their resale value -- but if you care about that, you
can still create separate units, I suppose, so I'm inclined to do it this
** It's probably OK for bribe cost to continue to be based on nominal shield
* Is there a sensible way to give non-integer bonuses avoiding rounding
errors? If I want to give a modest 10% discount on Horsemen, the naive
approach will give no bonus for production under 10/turn.
** We could keep progress-towards-current-goal multiplied up by say 100 (not
in a uint16!), giving the right average rate.
*** With only fractional non-transferable discounts, could lose a fractional
production point at project completion.
*** If transferable discounts also implemented and fractional, then could
avoid that loss, as 'underlying shields' and all transfers will have to be
kept in the 0.01 shield domain. (This is desirable; ruleset authors are more
likely to want transferable discounts to be modest.)

UI implications: city dialog should have the information it needs to display:
* Current instantaneous discount rate, and reasons for it.
* Estimate of completion time, assuming current discount continues (based on
ratio of progress to nominal shield cost, and current raw shield output and
current discount).
* Average discount rate for progress so far (based on 'underlying' shields)
* Maybe all of these separately for transferable and non-transferable
Probably these get displayed in a tooltip over the production progress bar.

This is quite a lot of work. Could do it in stages:
0 Non-transferable discount without fractional accounting
0 Add fractional accounting to non-transferable discount only
0 Add transferable discount (and associated fractional accounting)

I'm primarily thinking of bonuses here, but can this usefully be used to apply
penalties as well?
** With buy cost proposal above, buying early may become preferable. Could let
ruleset authors solve with buy cost adjustment of bug #22089.
** The non-transferable nature of 'discounts' lets you launder them by
changing to another item and back. Probably you should always use transferable
'discounts' for penalties.


File Attachments:

Date: Mon 26 May 2014 15:15:12 BST  Name: production_discounts.pdf  Size: 20kB
  By: jtn
Flowchart illustrating proposed logic (with Dia source)
Date: Mon 26 May 2014 15:15:12 BST  Name: production_discounts.dia  Size: 5kB 
 By: jtn
Flowchart illustrating proposed logic (with Dia source)


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to