Open ktksan opened 4 years ago
currently each type of crafting process is present in a specific location and all the items that use that process are present within the module that uses this process
I believe this is also the case for WoodCrafting
, StoneCrafting
, and EquipmentSmithing
- probably even more. We should opt for a general "inventory taking" of all our different crafting methods and try to align and possibly merge those that are already pretty similar.
dreaming starts
Ideally, we could then also follow the approach we now already have in place with Furnishings
/Explosives
and CoreAdvancedAssets
- so ending up with (for each crafting approach) a library module and an asset module.
dreaming continues Further we could think about making which materials are craftable configurable in the module, e.g. allow only wood crafting and fabric crafting, but not stone or metal or something the like :thinking:
For a bit of historical background, as there is a lot on crafting, here are some bits and pieces I remember in varying degrees of accuracy:
Lesson learned: Crafting is hard. And yeah, it sounds like it is about time to reassess once more, thus the spiel above, hopefully it will help educate and highlight what a challenge this can be so we don't just get a 6th generation of the same thing ;-)
It would be nice with a sort of "Core Refactoring" but for crafting, I suspect that might be even more work, however, and that's knowing what a herculean effort some very appreciated contributors went through on that project :-)
History shows us that an active area with multiple works of passion from different contributors can lead to a bit of a wasp's nest of difficulties - like a reluctance to tear down what others have built with care and differing intents. There are plenty of amazing ideas and cool bits of implementation, but somehow covering everything is hard.
Maybe like the nice module graph from the Core Refactoring we can do something similar, with a fundamental introduction to crafting (one approach like recipe-based chosen as a default, with a possibility for alternate crafting system trees?), then followed by concept-based systems for better modularization (Smithing, Cooking, etc), where indeed we could have some nice splits between logic and content.
One typical question that has come up in the past: where do the recipes go? What about the attributes of a material and a resulting product? In the content module (where you could define extra Components in prefabs that get gracefully ignoring by the engine if not enabled), or in the concept module (either entirely, or via deltas and such, which comes with drawbacks), or in a bridging module like EquipmentSmithing (messy) or something entirely else like using soft mappings between materials and effects (anything "wood" can be burned, iron is harder than bronze, an apple has qualities x
, y
, and z
which can be modified through various cooking techniques)
None of the approaches are really ideal. Just a variation of pros and cons. I'm mildly drawn to separately defining materials in a semantic fashion (for instance various types of hardness for a given material) that can then be used directly by even fundamentally different systems (say recipe based vs pattern-based crafting), but that's likely a whole additional magnitude of effort to pull off.
Thanks for the elaboration here @Cervator 💚 As pointed out more than once before, and to a large degree successfully done with the Core-refactoring I'd like to work out a common understanding and find a way to focus on one common base. Visualizing the module graph and sketching out how different styles and extensions can be incorporated with a given solution will hopefully increase acceptance of this "common thing".
Eventually, we'll end up with the idea of drop-in replacements again (do we have an issue for that already?). A game mode requires some form of crafting, but the user may decide how that actually looks like.
(I've added a link to a video showcasing the in-world crafting in your post above, thought it would make most sense to have that right where you describe the approach)
With optional dependencies in place now we are in a better spot to define recipes along with items, even though only one (or none) of the crafting modules is enabled. Delta overrides allow to add recipes to existing items, either in gameplay modules directly, or in some augmentation/bridging modules for reuse.
I'd argue that as long as we are in control of most (if not all) of these modules we should aim for high cohesion to keep all information affecting an item in the same place (which may also reduce coupling between modules at the same time).
Oh man! You found that video! I haven't seen that in years. #nostalgia
I don't think we have anything for drop-in-replacements modules (like variant inventories) written up yet
The description of the ManualLabor module says : "Adds tools to make manual tasks like digging and chopping easier." However the module has a lot of items and their respective crafting recipes which do not belong there for example Cloth, WoodenBucket/Cup, strings, etc.
The reason these items and recipes are present in ManualLabor is probably because their respective Crafting tools/ methods are present within ManualLabor. In other words, currently each type of crafting process is present in a specific location and all the items that use that process are present within the module that uses this process which means a lot of items end up being in places which they should ideally not belong to the module for example the presence of cloth and WoodenCup in ManualLabor. Ideally this should not be the case the module needs to be Reworked/restructured/renamed.
The crafting methods and recipes need to be extracted from ManualLabor and be combined with other modules like equipment smithing (rename to equipment crafting), stone / wood crafting in order for there to be a proper structure to the location of items and their crafting recipes. This would enable the items and their recipes to be located in places one would expect them to.
An example of the restructuring could be (just an example please look for a better way :) Crafting part of the items could be completely separated out which would contain the crafting modes and recipes however the items themselves could be shifted to modules where they ideally should be. Which would mean the player would not be able to craft the items unless they enable a crafting module but would be able to obtain the items from a different source should the gameplay mode choose to give them to the player in-game.