-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Botany rewrite proposal #284
base: master
Are you sure you want to change the base?
Botany rewrite proposal #284
Conversation
Thanks for your thoughtful work and writeup on this rewrite proposal.
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:
I do want to make sure that any rewrite is at least anticipating the needs of the future. |
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. |
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.