Cooking SuperModule

[jellysnake]

So, I'm working on fixing up the content issue in Cooking & SimpleFarming, and then moving on to integrate them with other modules where possible. Thought I'd type up my plan so others can see it and help/give suggestions. Phase one has been done and I'll have a pull request in about a day. Here is the code so far. I've also drawn up a dependency tree/graph that shows what will depend on what in when the project is finally finished.

It's also on a sketchboard here. The two arrows from the bottom are related to Potions&Alchemy which is for another post another day in the future.


The first phase was to re-do the way that the Vines and Bushes are done in SimpleFarming to make the system more realistic. I'll post the updated algorithm in a separate comment below. Trees are as of yet not added. These will come at a later date ideally using woodspeople's algorithm over at their site.

The next phase is to split the raw items into their separate modules. A few select fruit and veg will go into SimpleFarming. The rest will go into EdibleFlora. Also of note to this is the eventual module AdvancedFlora (name pending) which will eventually hold a bunch of other plants that use the systems from SimpleFarming without being edible.
Similarly a few of the edible animals will go into BasicAnimals with the majority into EdibleFauna. Note that not all of the items in BasicAnimals will be edible (by my standards at least). This is why BasicAnimals will not depend on Hunger. Instead prefab deltas will be used to add Hunger components to the animals defined in it.
Once this is completed the structure will look like this

As all the recipes in cooking are unchanged the module must depend on EdibleFlora and EdibleFauna to still work.
Additionally note that although the meat items will be located within EdibleFauna they are not guaranteed to be obtainable and to have animals at this point. The all the Flora is to have a corresponding vine or bush and hence can be grown but they may also not be included in a world generator and as such not be obtainable direct yet either.

The final phase is to split up the recipes into four tiers. BasicCooking, IntermediateCooking, AdvancedCooking and ModernCooking. Each tier will depend on the one before it.
The BasicCooking only uses items from SimpleFarming and EdibleFauna. Additionally these items will only use the raw ingredients directly. The next two levels, IntermediateCooking & AdvancedCooking will depend on EdibleFlora as well. They will both improve on the level before them, adding more complex items that use the previous level's items. Notably none of these three levels will modern utensils, although they can use complex ones like juicers. ModernCooking is the only module that will use the modern utensils. These will include things like blenders and blowtorches.

At this point the dependency tree will look like the initial picture. Almost all utensils, foods and recipes added over the time and from GCI will be integrated into a more packaged structure. One thing to note is that the image doesn't include things like a world generator or integrations like InGameHelp. These will be added to the sketchboard however.
I would be interested in potentially leveraging the end of year GCI to do most of the moving around of the items and integration with SimpleFarming etc as it suits the small task style effectively. The caveat of that is the time until GCI is occurring and the potentially grunt work nature of the tasks could cause the participants to have a impression.

Follow up tasks at the end of this project:

• Have the meats existing in EdibleFauna and BasicAnimals be attached to creatures and have both them, EdibleFlora, SimpleFarming & AdvancedFauna added to a world generator in a fashion that doesn't require them to be dependencies. This will likely require some kind of core registry to allow for variations of the same items to be used in module without needing those modules to explicitly mention all possible options.
• Begin to integrate the Flora&Fauna with a Potions/Alchemy Supermodule. This is most likely a separate sequel project that would require it's own post and discussion however
• Add in an option to SimpleFarming to allow for non-harvestable plants to still take advantage of the growth system. This would be relevant for the previous point on a Potions SuperModule
• Change Thirst and Hunger to depend on a Sustenance module. This can also be done as a parallel task to the project

Tagging @smsunarto as per request.

 

[jellysnake]

The algorithm for bushes has been unchanged, although the implementation has been re-written so that it can be integrated with vines. Each bush has a stored array of stages, where each stage displays a different block. The final stage is the harvestable stage. One harvested the bush either moves back to the previous stage or is destroyed. The latter option is to facilitate things like carrots and other root plants.

The vine algorithm now links each block of the vine to a node. When the vine is grown the linked list of nodes is traversed. Each node has three conditions checked and depending on that will either grow a bud, pass on down to the next node, or grow a new node on the end of the vine.
A new node can only be grown in a space that is both bordering the tail node & has two or fewer blocks in a 3x3 grid. This ensures that the vine maintains space on either side of it and makes it more realistic looking.
The bud the vine can grow is just a bush that is linked back to the node. Doing this allows for code reuse between the the vine system and the bush system.
An unexpected but nevertheless appreciated benefit of this linked nodes approach is that when a node on the vine is broken all those down from that point are also broken.

 

[Cervator]

All sounds good to me, with one potential quibble - might just be not fully understanding something yet

I think the distinction between what's edible flora/fauna or not is too arbitrary to serve as a module border. The moment somebody adds an inedible gravel golem (or a more comparable "advanced animal") a timer starts for when somebody will add a bigger golem that does enjoy the sweet rocky innards of the previously inedible gravel golem.

I don't think whether something is edible or not should be up to the thing - it should be up to whatever wants to actually eat it. We had a similar challenge in @arpan98's Anatomy project: do we try to define the possible effects within a creature's anatomy definition or slip it in later via deltas?

My usual go-to solution is building a generic foundation of characteristics using simple string "tags" - so with anatomy we got stuff like "bone", "blood", "muscle" etc and those were applied to arbitrarily named body parts. At that point the next line of functional modules (bone breaking, blood effects, muscle ailments) can just indicate their interest by latching on to anything with a given tag.

I think we could do something similar with edibles - and in fact may want to use Anatomy directly. Rather than add additional eating/cooking related attributes directly on a deer's droppable loot just say it contains a few things like:

• Bone
• Meat
• Fur
• Blood
• Organs if you want to get really macabre, etc

Which is pretty much the same thing you define with the current Anatomy system. In the spirit of @Josharias' module SubstanceMatters we then find a way in which to flavor those drops as coming from a deer. Maybe deer meat is too gamy for monkey heads to enjoy, but it drives wolves nuts. Maybe the bone is too brittle for making tools, yet makes great soup. Conversely a different animal may have cotton-candy textured super meat and bones with strength like steel.

On the cooking side of things you tie on to those two dimensions of characteristics, or maybe even more than two if we go nuts - that might be a way to distinguish between SimpleAnimals and AdvancedAnimals: one more dimension. Say we just think about two at first. A given cooking recipe requires the ingredient type to be simply "meat" and flavoring/texture/whatever to be in some particular range that the meat from deer qualify for. Now you have [adjective] [recipe function] [origin creature] aka "Savory Spit Roasted Deer Flanks" or something like that. You could use the exact same recipe on meat from another compatible animal and get "Savory Spit Roasted Wolf Flanks"

The question is whether we should have a truly "simple" animal/cooking setup that is radically different and doesn't serve as a foundation for an "advanced" next step. The Anatomy system definitely isn't basic, but on the other hand it could be something setting our base game apart if we go all in on it and make it super easy to use. Want to add a new animal? Here is an anatomy template, throw in a bunch of these known tags as you deem appropriate and go explore in the game with a bunch of modules enabled to see what your new animal can now be used for!

One final side item before I go too nuts on tangents: emphasis on that "deer's droppable loot" - just because you define something as droppable doesn't mean you're making something into a loot pinata that spills a whole pile of things out on death, half of which you don't even have a clue what are for. One issue I had with some mods in MC is that they added fancy new loot to just about anything and you'd have no clue why a skeletal archer just dropped a glowing mystery crystal of Wololo. Instead I would say we aim to add drop possibilities but only trigger them within context.

By that I mean when a deer falls over, ready-to-cook deer flanks normally don't just magically spill out. The deer just falls over. But say the player has a module enabled that allows you to process meat ... now you might want to highlight a part of the deer's corpse where you could harvest something if you had an appropriate tool, like a simple bladed instrument. You could even give thought-bubble style clues as to how to get at said meat or other drops. At that point you still wouldn't want bones to come spilling out either, but if again there is an appropriate module enabled then it is time to take action. Taken to the extreme if somebody makes a gameplay template in which every creature including deer is secretly mind-controlled by a central nefarious force by implanted glowing crystals of Wololo ... now you finally have a way to only drop those if the player would have or be able to get a clue why they are there. If not, maybe the deer and other animals just glow a bit.

In that final case you would apply that via delta prefab - but maybe a way could be found to bulk apply it to anything that counts as a creature, or anything with a skeletal system if that's where the glowing crystal would be embedded. Getting back to sanity we're talking more about meat, and maybe a distinction between simple and advanced is whether or not things just spill out ready to use. Same basic system (deer are made of meat), just different expressions (simple: generic "meat" falls out; advanced: corpse can be harvested for deer meat)

 

[Cervator]

Added a GitHub project board for this and a card in Trello for organizing updates ...

(Experimental stuffs...)