search

MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.69k stars 1.34k forks source link

Clean up Modules related to Plants/Growing/Farming #3663

Open skaldarnar opened 5 years ago

skaldarnar commented 5 years ago

@jellysnake @cervator Can you please shed some light on the whole plant/flora/growing area? (GitHub issue is probably better for discussion…)

Why are PlantPack and GrowingFlora kind of deprecated? What’s the problem there? I think the names are a bit more general than SimpleFarming and EdibleFlora, but if their content/functionality is superseded by those then we remove them from the modules list, too…

The feature set of AnotherWorldPlants should ideally be covered by another module… also a candidate for consolidation and eventually removal.

Crops is already empty and contains a note that it has been moved to PlantPack. Should we delete the repository?

Cervator commented 5 years ago

So I think we talked about this a bit on chat a few days back, @jellysnake in particular might have more. Some summary bits:

I'd be curious about how any GSOC content projects (and maybe the health project) might help restructure all this further in sensible ways. The big reorgs/refactorings from somebody having a bit of free time tend to run into time constraints before they fully flesh out nice new structure for everything involved :-)

Cervator commented 5 years ago

Adding link to https://github.com/Terasology/JoshariasSurvival/issues/22 - there are some similar issues floating around related to "modernizing" or cleaning up this area in other ways.

syntaxi commented 5 years ago

Ok, so this is likely to be a bit of a wall of text: I've been using SimpleFarming with a couple of secondary goals. Notably one of these is testing out "content" structure where it applies for large systems and trying to modularise where possible. This means that the SimpleFarming "group" can seem to be structured oddly/differently to other modules but this is my attempt at detailing how it works out.

This is also something I've mostly just been thinking about and working on myself without really dumping it for consideration so feel free to question and poke holes in it.

At the root of it all is the "System Module". It is a core module that should only contain the logic for the system. This is the role of SimpleFarming. It's the 'base' module and the place for the the growth logic. It doesn't actually contain any of the content for plants or trees or similar.
It's documentation should be geared towards a developer intending to add features to the module, and it's wiki should be geared towards using the features in your own module. It's existence should be highlighted to developers to promote code reuse. No point implementing the exact same thing if there is no benefit in the "new" implementation.

Next layer up is the module that implements content using the base logic module, the "Content Module". This is EdibleFlora it adds a suitable selection of content and should be able to stand as a "activate this module + core and you can use it fine". Here it adds a couple of plant types and a method to obtain them through regular play. It can have as large a scope as the developer sees fit, but should prioritise only adding a base set of content.
It is basically wholly player facing, and indeed it's wiki should be used to describe and detail it's content for a player wanting to use the module. This is the type of module that I would image being shown on a Module Showcase site (at least a player focused one)

On the fringes of this we then have the "Addition/Expansion Modules". AdditonalVegetables and AdditionalFruits fall under here. These are essentially the same as the prior "Content Modules" but they can't stand on their own. They enhance an existing content module, but usually by making it deeper rather than broader. To explain this, the two listed here don't add any new systems, or scope to the Edible Flora module. They do however add in more plants. They deepen the existing content without expanding the scope.

If you do want to expand the scope then the "Integration Module" is the place to go. This doesn't actually have to be a separate module and using the magic of ~ Optional Dependencies ~ you can have it a part of the "System Module". Having it as a separate module or as a core part comes down to developer discretion but I'd recommend/suggest that if the integration is likely to be common/simple/fairly well linked (like say Genome and SimpleFarming) it's better to include it in the "System Module". If it's not, then a separate module works. The comparison here is the WIP/attempts at adding Genome to SimpleFarming.

So that covers those four modules, which are the ones I actively developed significantly and I've focused on. As for the other modules:

Crops Yeah that's straight up superseeded and deprecated.

GrowingFlora I consider this "obselete" because it tries to implement the same thing as SimpleFarming does. It just lacks the "interaction" that SimpleFarming does but that can be handled with a little tweak to the latters code to add in options for things like repeating the cycle once it reaches maturity and removing interactions.

PlantPack
Is one that I mentally think of as an "Assets Module". I've not detailed that above but essentially just contains new blocks, no functionality or very minimal at most. Basically the src directory should be as close to empty as possible. It terms of integrating it into the current selection of modules above. I think it's role would be as something that EdibleFlora (and AdditionalX) could depend on and attach functionality too, but that raises a few issues. For now I think keeping it seperate until those are solved is best

Josharias commented 5 years ago

Something like this, right? (where the lines are module dependencies, and the dotted are optional deps)

image

Another thing to consider is how interaction would work if an expansion module supports 2 different content modules. But I suppose this may be a case of just having to know how the different underpinning libraries interact with one another.

image

I can see there also being some benefit to having content modules be more prescriptive in how they allow extension of the systems for playability and balance. For example, if I build AdditionalBerries, I would want the grow times of my additional content to be in line with what is already defined in the content module. Not exactly sure how this would look like, but I do know that basing your expansion module on top of the library directly can promote extension of the content module that may not make sense for the gameplay.

image

skaldarnar commented 5 years ago

Thank you for the explanations and general information. Highly appreciated and provided great insights! Let me try to collect a bunch of actionable items: