Page MenuHomeWildfire Games

New concept for fields
Needs ReviewPublic

Authored by mimo on Mar 16 2017, 7:35 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Trac Tickets
#5415
Summary

Current field implementation have several drawbacks:

  • it should be disfavored in start game (berries and hunt are to be preferred) while still possible as some maps miss enough other resources.
  • it should be more sensitive to raids (a raid which does not destroy a field but severely damage it should have an effect on its gather rate, while currently it's enough to garrison its gatherers and wait for the end of the storm)

To solve that, i had proposed some changes some time ago (see some discussion of this concept in https://wildfiregames.com/forum/index.php?/topic/20406-changes-in-farms/ ) which i've revived here in a working patch. The main ideas are:

  • the gather rate depends on the health of the field (which symbolize their fertility)
  • the fields are now built very quickly (15s build time), but their initial health is only a small fraction of the max health (30% in the patch), and thus the initial gather rate is small (30% of its full value)
  • the field health increases slowly when it is gathered, and decreases when no gatherers (so in case of raid, if we garrison all our farmers, the productivity of the fields will decrease, possibly up to the destruction of the field).
  • the initial increase of health when worked on is relatively slow and the initial decrease of health when unattended relatively large, so that fields are less an interesting source of food at start game, until we have researched the irrigation (available only at town phase) which improves the increase of health when gathered and reduces the decrease when unattended.
Test Plan

Test the changes in game

Diff Detail

Repository
rP 0 A.D. Public Repository
Branch
/ps/trunk
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 812
Build 1279: Vulcan BuildJenkins
Build 1278: arc lint + arc unit

Event Timeline

mimo created this revision.Mar 16 2017, 7:35 PM
Owners added a subscriber: Restricted Owners Package.Mar 16 2017, 7:35 PM
elexis added a subscriber: elexis.Mar 16 2017, 7:43 PM

Would seriouly not add merge conflicts to D215 yet again.
Idea is good, needs gameplay testing and balance finetuning.

binaries/data/mods/public/simulation/components/Health.js
154

I'd invert the check. Also I dont like checks for classes in code logic, why not check for the existance of ResourceSupply and a property thereof? So that modders can use it for things other than fields?

Seems like a good concept. :)

Vulcan added a subscriber: Vulcan.Mar 16 2017, 8:18 PM

Build is green

Updating workspaces.
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (302 tests)..............................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (302 tests)..............................................................................................................................................................................................................................................................................................................OK!

http://jw:8080/job/phabricator/533/ for more details.

mimo added a comment.Mar 16 2017, 8:25 PM
In D227#8448, @elexis wrote:

Would seriouly not add merge conflicts to D215 yet again.

That's something which is currently missing, and which will anyway have to be added at some point to D215 or a following patch.

Idea is good, needs gameplay testing and balance finetuning.

binaries/data/mods/public/simulation/components/Health.js
154

yes, adding a new property (but in Health to signal that the regenRates should be used differently ) would be better. I'll change it.

Good idea, this idea has a lot of potencial.

mimo added a comment.EditedMar 16 2017, 10:53 PM
In D227#8448, @elexis wrote:

Would seriouly not add merge conflicts to D215 yet again.

That very nice that D215 is now commited (thanks for that). But concerning this patch, i've currently no idea how i can do what i need for this patch in this new framework, i.e. take as Max health of the foundation the Initial health of its base entity if it exists, otherwise use the Max of the base entity as is currently done. I'll have to dig into the code to understand it, but if anybody has an idea how to do it, feel free to comment here

Sounds like adding a merge to foundation.xml

mimo added a comment.Mar 16 2017, 11:20 PM
In D227#8493, @elexis wrote:

Sounds like adding a merge to foundation.xml

That's what i expected, but not sure it would work as we need to move the "Initial" from base to "Max" of foundation, and only it is exists.

Just keep max health and change the sim?

Imarok added a subscriber: Imarok.Mar 16 2017, 11:45 PM

it should be disfavored in start game (berries and hunt are to be preferred) while still possible as some maps miss enough other resources.

I think thats already the case, though the proposal sounds good anyway.

mimo added a comment.Mar 16 2017, 11:58 PM
In D227#8496, @elexis wrote:

Just keep max health and change the sim?

Yep, i think i'll have to do it in the sim. It was more elegant to have it in the template, and better visually as otherwise the construction will stop when it reaches 30%, which may leave some players perplexe.

Just brainstorming, changing the Foundation code to use the initial health instead of the max health?

and if its inevitable, you can still add a new C+++ function doing that

Even more elegant than extending hardcoded c++ template interpretation would be implementing a copy_from= attribute

mimo updated this revision to Diff 862.Mar 19 2017, 10:40 PM

updated version with answers to elexis comments and a temporary hack following D215 which broke the previous patch (to allow tests of the feature).

Build is green

Updating workspaces.
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (305 tests).................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (305 tests).................................................................................................................................................................................................................................................................................................................OK!

http://jw:8080/job/phabricator/552/ for more details.

elexis added a comment.EditedMar 23 2017, 5:13 PM

(If I understand #2951#comment:28 correctly, the transformation shouldn't be done in C++ nor a special filter)

FeXoR added a subscriber: FeXoR.EditedMay 1 2017, 12:35 PM

"...currently it's enough to garrison its gatherers and wait for the end of the storm." is already damaging the economy of the attacked player.

IMO keep it simple. Either make building efficiency depend on "health" for all buildings or none. Not mix it (like it is sadly done already for e.g. maximum numbers of buildings of a specific type...).

Otherwise I agree with this changes (and yes, that means fields are different to other buildings in some aspects ^^).

Itms updated the Trac tickets for this revision.Mar 17 2019, 5:14 PM