kitten-science / kitten-scientists

Home of Kitten Scientists v2
https://kitten-science.com/
MIT License
31 stars 14 forks source link

feat(core): Implement new bulk purchase strategy #591

Closed oliversalzburg closed 2 weeks ago

oliversalzburg commented 2 months ago

Many purchasing mechanisms in KS are driven by the "Bulk Purchase Helper". This component receives build requests, and is then expected to figure out how many items to build out of those requests. The helper works well enough, but has certain negative behaviors that most KS users will likely be aware of:

  1. Build requests are always in the same order, as they are derived from your settings, which have a fixed order. The result is that certain items are always built before other items. You will notice that certain buildings will only be built if another building becomes more expensive than itself.
  2. When KS orders a large amount of certain items, a single build request can consume so many resources that no other build request can be satisfied. This can be especially painful after resets or during time skips.

The new behavior tries to fix these issues.

  1. The helper loops over the requests several times to figure out a more ideal build solution.
  2. When the helper processes the requests, it will randomize the order of requests during each loop iteration.
  3. The helper will try to build 1 of each request during each iteration. If a build is possible, it will be ordered, and the remaining resources are recorded to evaluate the remaining build requests. If the build is not possible, the build request is dropped; any prior successful build requests are still ordered though.

[!WARNING] In the current working state, the helper produces build requests that can not be satisfied. The result is a log message like Build Broadcast Tower (x0). This is under investigation and needs to be fixed before this feature can be merged.

Fixes #155

oliversalzburg commented 2 weeks ago

Some things are still not working right with this approach. However, I believe it is an improvement over the way things worked previously. I want to merge this change and evaluate it further in the larger development path. I think it needs more fixes, but can then be a valid improvement over the past strategy. If this change fails to deliver positive results long term, we just simply revert it.