patchFreeciv - Patches: patch #4722, City production discount effect

 
 
Show feedback again

patch #4722: City production discount effect

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Mon 26 May 2014 02:15:12 PM UTC  
 
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 26 May 2014 10:59:35 PM UTC, comment #3:

> Is this just for the civ2civ3 Aqueducts, or are there other
> intended applications?

I'm thinking vaguely of commercial CivIV, where you can have all sorts of miscellaneous production bonuses; some nations build workers twice as fast, or access to stone speeds up two or three different buildings a bit. It's not really possible to do this in Freeciv at the moment.
What made me think about how to do this in Freeciv was an IRC conversation (with 'morphles', I think, who raised bug #22089); I can't remember what they wanted to do with it.

> Given the difficulties of explaining any implementation for
> both players and ruleset authors [...]

On the contrary, the explanation to ruleset authors is extremely simple: "if you want production of a specific thing to go quicker, just use Production_Bonus, and it will generally behave sensibly". Similarly for players, all we need say is "meet these requirements and you get a 10% production bonus for Horsemen" and all the edge cases should be unsurprising. My belaboured treatment is all about defining precisely what "behaves sensibly" means.

Also, don't be put off by the size of my description. I think the existing logic dealing with city production (with all the special handling of changing production just after completing something, etc) is probably about as complex as the new proposals, it's just no-one's written it down as anything other than code.

Jacob Nevins <jtn>
Project Administrator
Mon 26 May 2014 05:31:24 PM UTC, comment #2:

This is vastly complex, which is probably needed, given the intended application. Is this just for the civ2civ3 Aqueducts, or are there other intended applications? Given the difficulties of explaining any implementation for both players and ruleset authors, I'd hope it would be useful for more than just tidiness in a single ruleset (yes, I can think of some hypothetical examples, but most of the concrete ones seem more interesting strategically in terms of absolute restriction (e.g. can't build Horsemen without either Horses or a Traderoute to a city with Horses)).

Emmet Hikory <persia>
Project Member
Mon 26 May 2014 02:31:33 PM UTC, comment #1:

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

In fact, it's almost sufficient.
You can bodge the upkeep differences with the Upkeep_Free effect.
However, you can't fix the technology requirement without disjunctive building requirements, I think.

Jacob Nevins <jtn>
Project Administrator
Mon 26 May 2014 02:15:12 PM UTC, original submission:

(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.

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 proposal.

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 threshold.
    • 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 progress.

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 way.
    • It's probably OK for bribe cost to continue to be based on nominal shield cost.
  • 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 discounts

Probably these get displayed in a tooltip over the production progress bar.

This is quite a lot of work. Could do it in stages:

  1. Non-transferable discount without fractional accounting
  2. Add fractional accounting to non-transferable discount only
  3. 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.
Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #20809:  production_discounts.pdf added by jtn (20kB - application/pdf - Flowchart illustrating proposed logic (with Dia source))
file #20810:  production_discounts.dia added by jtn (5kB - application/x-dia-diagram - Flowchart illustrating proposed logic (with Dia source))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 26 May 2014 02:15:12 PM UTCjtnAttached File-=>Added production_discounts.pdf, #20809
      Attached File-=>Added production_discounts.dia, #20810
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup