Botany rewrite proposal

[drakewill-CRL]

I spent a lot of time recently digging through Botany code, taking notes on how it worked and what could be changed. The most important part of this is tearing "Rewrite all of Botany" into 5 or 6 smaller parts that can be done separately.

TLDR version: Plant Growth and Mutations become separate systems. Harvesting becomes a component or effect. Plants become their own entity instead of a variable on PlantHolder. Add hooks for later improvements for interactions.

[Partmedia]

Thanks for your thoughtful work and writeup on this rewrite proposal.

This is not a proposal to change Hydroponics (The department where people do the growing of plants), though most ideas for reworking Hydroponics require a more flexible Botany system.

I think it would be better to consider what you might imagine hydroponics will become before you embark on such a large rewrite. Imagine that you rewrite all of botany's code without any user-facing changes. Then we decide that hydroponics needs to change in some user-facing way. Won't that likely require possibly significant changes in the botany code?

You might argue that "botany ECS" will make it easier to adapt to future changes, but it's not a guarantee that the abstractions you chose in this rewrite will be flexible enough to support it.

Given that, and that any rewrite typically causes:

1. A lot of breakage in downstream forks
2. A lot of implementation bugs that need to be ironed out

I do want to make sure that any rewrite is at least anticipating the needs of the future.

[drakewill-CRL]

Here is my Hydroponics write-up . I did that second, because there will far more opinions on job content and changes than back-end code. In my hydroponics plan, the core changes to botany code would be putting a GrowthComponent on all plants that enables a second set of mutations to be applied, and being able to select and apply mutations or variables from grown produce to other plants. My hydro proposal could be done in the current system, though it would be easier to change and maintain after this proposal is in place.

I did look for any previous proposals and discussions, but there were very few concrete plans or actionable ideas. I didn't intend to write a perfect system that would do everything anyone could ever want the first try, but one where changing it in the future didn't seem so daunting. Splitting out plant growth steps and mutations into their own logic is a big part of that, because then discussions on removing redundant stats and changing how plants grow can be done and implemented without necessarily changing the mutation code and vice versa.

[TokenStyle]

Add your proposal to src/SUMMARY.md for example: Example1 , Example2