Skip to content
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

Rework/Restructure the ManualLabor module to extract out the Crafting resources. #31

Open
ktksan opened this issue Jun 29, 2020 · 5 comments
Labels
Category: Gameplay Content Requests, Issues and Changes targeting gameplay mechanics and content Size: L Very big effort likely requiring a lot of research and work in many areas across the codebase Status: Needs Investigation Requires to be checked for feasibility, reproducability, etc. Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Type: Refactoring Request for or implementation of pure and automatic refactorings, e.g. renaming, to improve clarity

Comments

@ktksan
Copy link
Contributor

ktksan commented Jun 29, 2020

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.

@jdrueckert
Copy link
Member

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 🤔

@Cervator
Copy link
Member

Cervator commented Jun 30, 2020

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:

  • Once upon a time I believe small-jeeper introduced the first proto-crafting system to the game, using a 3x3x3 grid within a single blockspace where you'd literally place blocks/objects into the world to make a 3D recipe resulting in some new item. And all was well in the world, albeit primitive.
    https://youtu.be/-cdhxguyMpA
  • In 2014 MarcinSc started ThroughoutTheAges and Josharias did JoshariasSurvival, the two settings differing a bit in their approach to crafting (TTA was a bit more hard core, inspired by TerraFirmaCraft, tho prolly JS was too). Workstation began with TTA, I think JS started using it to a point, but had ManualLabor as the entry point for crafting to begin with, which probably explains some of the logic and asset choices in there
  • TTA meant to introduce tech in eras (thus the "through the ages" bit) so it would add the assets and recipes in a material-flavored module (WoodAndStone, CopperAndBronze - it never did get to IronAndSteel..), each depending on Workstation for the crafting basics
  • I think JS added more recipe-level frameworks and other advanced pieces in ManualLabor for other JS modules to extend, which led to concept-based modules like Machines, IRLCorp, etc when adding new things
  • Circa 2016 with TTA having gone inactive xtariq tried to renew it and unify more stuff with JS (being maintained somewhat by the community as our default setting), in a new gameplay series meant to possibly succeed both of them - which naturally led to the usual outcome as he burned out on the project before finishing, although after doing a lot of really cool things. There was a bit of a golden age in item development as GCI students were thrown at content dev in the various systems (with a rather ... diverse quality-range of outcomes)
  • In NeoTTA the WorkstationCrafting module took over (IIRC) in spirit from ManualLabor and other bits containing crafting logic, and WoodCrafting + StoneCrafting came out of WoodAndStone to not overly disturb it while converting. Although then it went to Smithing instead of CopperAndBronze, which I think makes sense as really metalworking isn't as specific to the exact metal as something like wood or stone would be. "NatureCrafting" was an intended goal as a module to hold the crafting you'd do in your hands without an actual workstation.
  • NeoTTA tried to pull in more topics like Cooking, Alchemy, and so on, with their own crafting screen but I don't think logic - could be wrong there though. I think by the time EquipmentSmithing showed up the direction was beginning to come off the rails on exactly how to organize what in which modules, should we be using bridging modules (EquipmentSmithing bridged Equipment + Smithing), etc - optional dependencies weren't formally in yet
  • Since all that chaos clearly wasn't working out it was time for a fifth generation of crafting with BasicCrafting, which tried to start, well, basic, without all the crazy modules from the past (the WorkstationCrafting-based modules were getting pretty buggy). It begin trying to simplify some things like Cooking, which resulted in a bunch of recipes being converted, but not all, so some worked with BC, some worked with NeoTTA (maybe?), or not at all. EdibleFlora/SimpleFarming got pulled in too but not sure how much crafting is actually in there. It ultimately stalled too.
  • This doesn't account for probably half again as many complex crafting system thought up in the forum over time, but not implemented. Plus probably another abandoned crafting system or two - I spotted references to a plain "Crafting" but can't even remember that, maybe it was the in-world one? 🤔

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.

@skaldarnar
Copy link
Contributor

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)

@skaldarnar
Copy link
Contributor

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).

@Cervator
Copy link
Member

Cervator commented Jul 4, 2020

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

@jdrueckert jdrueckert added Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Status: Needs Investigation Requires to be checked for feasibility, reproducability, etc. Category: Gameplay Content Requests, Issues and Changes targeting gameplay mechanics and content Type: Refactoring Request for or implementation of pure and automatic refactorings, e.g. renaming, to improve clarity Size: L Very big effort likely requiring a lot of research and work in many areas across the codebase labels May 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Gameplay Content Requests, Issues and Changes targeting gameplay mechanics and content Size: L Very big effort likely requiring a lot of research and work in many areas across the codebase Status: Needs Investigation Requires to be checked for feasibility, reproducability, etc. Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Type: Refactoring Request for or implementation of pure and automatic refactorings, e.g. renaming, to improve clarity
Projects
None yet
Development

No branches or pull requests

4 participants