NOTE: This feature is currently written at the concept level. I will be going through here with equations, json examples, and the like at some point.

Is your feature request related to a problem? Please describe.

Farming presently is a very easy and fast way to get a huge amount of food. It is also very simplistic, not allowing all kinds of believable and fun things like indoor greenhouses, or trying to raise coffee plants from seed because you don't want to live the REST OF YOUR LIFE WITHOUT COFFEE GODDAMMIT.

Thus, farming needs more simulation than just 'plant plant, plant grows'. However, this is a system that can potentially be so complex as to require an entire game of its own: I think we'd do well to consider it from the perspective of balancing verissimilitude and survival simulation with simplicity right from the start, to avoid the occasional overcreep of features and detail that we get.

Describe the solution you'd like

This is going to be a long and detailed implementation guideline for a feature that should be spread across multiple PRs. I have provided a table of contents for people that want to jump to particular parts. (With any luck I can get the links working later).

Concept description
- Environmental stats: water, light, and temperature
- Tend
- Health
- Exteriors and soil
- Tools for planting and tending
Specific implementation details
- Plant elements in JSON
- Tracking the environment
- - Water
- - Temperature

Prior to implementation:

Before implementing farming, we need or want the following infrastructural additions:

We should be able to store daily rainfall at the OMT level in a metadata item
Similarly we should track minimum, maximum, and average temperature outdoors in an OMT as metadata, and in individual tiles that have plants on them indoors
Finally, we'll need to do the same with light levels, separate for all of outdoors or individual indoor tiles that have plants on them.
We may want to consider putting plants on a separate mapgen layer of their own instead of mixed with furniture and terrain before implementing this, but that is not strictly a requirement. This implementation could instead create that layer for farm plants, and we could move wild plants there later.

Concept description

I would argue that for game purposes, we can give plants five core attributes to adjust. Each of these will have its own secondary details.

water
light
temperature
tend - this is the crux of this proposal.
health

At present, this first implementation assumes all plants are annuals that die over the winter. That will naturally occur when they get into weather conditions that kill them, we don't need to program it in. This proposal will cover some of the basic implementations of perennials and things but won't get too complex. A follow up proposal should cover natural spread of plants, so that your garden can get overrun with blackberries, you poor bastard.

Key balance note: The balance intent of this is that if you plant crops outdoors, most plants should be hardy enough to get water from the rain and produce at least some yield with a minimum of tending. However if you tend your plants and water them, you'll get better yields. If you want to grow more delicate crops, they will need more attention, and maybe something like a greenhouse.

Environmental stats: water, light, and temperature

Each crop will get a JSON range of preference for these, eg. "water": [ 0, 100 ] would represent a plant that doesn't care if it's at 0% or 100% water, so it never needs watering at all and doesn't suffer from overwatering. See health for how these would translate to the plant's yield and wellbeing.

Tend

tend is a summary of all the things you might have to do to take care of a plant besides the top three. Weeding, treating bugs or insects, correct spacing or beneficial partner planting, fertilizing, etc. are all features of tend. By abstracting these to a single attribute we can make most of farming/gardening about the avatar's skill with it, and not the player. For example we won't punish players for putting their cucumbers too close together and then getting powdery mildew. Instead, if you don't have the right skills/proficiencies when you plant, you'll get a cucumber whose tend score falls more quickly and therefore requires more constant attention to stay healthy.

There is an important secondary attribute, tend_decay. tend_decay is mostly defined by the plant itself through a new json trait, hardiness, so a less hardy plant with a high tend_decay needs more attention and maintenance, while a plant with low tend_decay is hardy. When you sow seeds, you also make a skill check that can adjust tend_decay, so a skilled farmer still doesn't need to tend their less hardy crops as often, while a rookie might have troubles getting their radishes to grow. (Addendum due to comments below: be aware that 'tending more often' does not mean 'daily' or 'multiple times per day'. The goal is to have farming remain mostly hands-off unless you want to optimize your crop outputs or are growing very tricky plants.)

The speed at which a character increases a plant's tend score should be a function of relevant skills and proficiencies as well as tools. The better a gardener you are and the more equipped, the more easily you can maintain your plants.

Health

A crop's health falls under a number of conditions:

a character tending the crop makes a bad skill check
water, temperature, or light were out of preferred range that day: this would be checked at the end of a 24 hour period and look at total values for the day
tend is low

As a crop's health falls, first its growth slows, then stops, then it dies. Crops with low health at time of harvest produce less. This will be managed with a long term tracking stat, thrive, which moves up and down more slowly than health does and represents how lush and happy your plants are independent of their growth stage (which will also be impacted by health).

A note on overwatering: It should not be possible to overwater your plants manually, for sanity reasons. Overwatering should only be a feature of rainfall. This falls into a design note in tend, that we should assume the avatar can know what they're doing, even if the player doesn't. Thus at the end of the day when we check water status for outdoor plants, we should first see if the plant got enough or too much water from rainfall, and skip checking player-added water at that point unless the plant needs more water. The purpose of overwatering is only to see if the plant is in a biome that doesn't suit it, to stop you from growing cactus easily outdoors.

Exteriors and soil

To simplify matters, when plants are put outside, we should assume all plants in the same OMT experience the same amount of light, the same range of temperatures, and the same amount of rainfall. We can track this on the OMT level throughout the day and apply them to plants in the tile at the end of the day. By doing this, we can take out the role of seasons in planting and instead have plants grow based on seasonal weather conditions.

Soil type, at least for starters, should be split into two types only: ground, or raised beds. Raised beds should have a slightly lower tend_decay score (less weeding eg) but lose water more quickly and perhaps be more susceptible to temperature changes as well. Later, it should be easy enough to extend this system to include different effects from planting in sand, gravel, clay, parched earth, etc.

Tools for planting and tending

There are three key tool categories here, expendable, recoverable, and reusable. Expendables include fertilizers, insecticides, herbicides, etc; recoverable are things that are used while the plant is growing but you get back when it dies (trellises, tomato cages, planters), while reusable are obviously shovels and the like.

When planting a plant, having the right tools can make it go faster (shovels and trowels eg) or can give the plant a better tend_decay score (tomato cage, fertilizer eg). Potentially we might also include things that help the plant with other values like water (retaining soil) or temperature (straw mulch).

When tending a plant, tools can make it go faster (scissors to prune, eg) or can improve outcomes (spray bottle to mist the leaves). Rather than simulating disease, we should have a random chance every time you tend a plant that it could ask for a specific class of tending tool, probably grouped something like: prune, insecticide, fungicide, fertilizer (the options might be defined on the plant so that not every plant would get every problem and not all problems would be of equal severity for all plants). I'm open to other suggestions. If you do not have something in this class, you get a penalty to your tend roll for that day ranging from small to huge, and either have to spend a lot more time with the plant, or let it take a major hit to its health. We wouldn't track anything beyond that... you wouldn't get spider mites on your pepper plants and have to spray them daily for a week, you'd just either deal with them that day or not. We may consider adding at least a little granularity to fertilizer types and having multiple fertilizer needs for plants of different sorts, encouraging a person to have a well stocked garden shed and in turn find themselves with fun and interesting garden chemicals for other uses.

Note here and in other areas, we are modeling a single tile as a 1 sq m farm plot, not a single plant, so if we ask for something like beanpoles or tomato cages, we will need more than one. Requiring several may help players remember that this is not a single plant, which will help a bit when people inevitably ask why it takes ten liters of water to water a single tile.

Specific implementation details

So now that that's done, let's get into the gritty deets. This section is under construction.

Plant elements in JSON

After some discussion with Kevin, I think it is important that we make the contributor-facing JSON not too gritty. I suggest we add the following data to growable plants:

drought_tolerance: none, low, medium, high, unlimited.
overwater_tolerance: none, low, medium, high, unlimited.
frost_tolerance: "yes", "no", or "mandatory". "yes" means the plant can survive frost and just loses health if too cold. "no" means it immediately dies if the temperature drops below 0 celsius. "mandatory" means it has to drop below 0 celsius at least once to bear fruit, and otherwise behaves as if the answer is "yes".
cold_injury_temp: in degrees C, the temperature the plant starts to suffer ill effects from cold. For plants without frost_tolerance, if this value is 0 or lower it is meaningless: we could either throw a json error or just ignore it.
winter_dormant_temp: At this temperature the plant stops losing health, and stops growing and producing fruit, until it warms back up for spring. If the temperature reaches cold_injury_temp it can still lose health but nothing else will bother it. This value should throw an error if it is lower than cold_injury_temp, since the plant would die while dormant.
heat_injury_temp: in degrees C, how hot does it have to be before the plant suffers? This should be quite high in general, most plants can tolerate heat as long as they're watered. We might even allow this to be left out in which case the plant won't suffer heat damage, we'll just represent it with watering, but there are some delicate plant that need to watch out for this.
light: "full sun", "partial sun", "full shade", "dark".
hardiness: This determines the base rate for how much tending the plant requires: high hardiness means it needs less tending. This may need to explode into susceptibilities for a few common ailments, we shall see how that pans out in numbers. It also determines how much health damage the plant suffers from bad conditions.
difficulty: This determines how much your gardening skill will affect hardiness of the plant at planting and when tending. If a plant has a high difficulty, it will require more skill to tend properly, and it will suffer more damage from ill effects.

We will also need to adjust the existing information on growth times to include how long it takes to get a second harvest from plants that can continue to yield plants, as well as how long ripe plants can remain unharvested before rotting in the field.

At some point I will add edits to suggest what these values translate to in numbers. For now I hope that gives a clear picture of what we're looking for.

Tracking the environment

water, temperature, and light should be global: that is, they should not vary depending on the plant or the character's skill.

Water

Water ranges from 0 to 100, representing saturation of the tile, where 100 is completely soaked muddy earth. We could also include a value -1 for planting immersed in water, allowing rice paddies and things. Raised beds lose moisture quicker, and potentially things like mulch or retaining soil could reduce this rate. This can be influenced by temperature to allow hot weather to dry plants faster.

Note that most crops that can grow outdoors in new england should have a desired_water upper limit of 90-100. Under 100 means that they don't like heavy rain for days on end, but can survive a few days of heavy rain.

Every 24 hours we should perform an assessment on watering status. Note that we do not update the water status at the time the plant is watered! (However we should remove any warning messages about your plants needing water once you've watered them.) The algorithm should look like this:

Drop the water level of the plant: water_level_current = water_level_previous - ( [ 75 if in raised bed || 50 if in soil ] * [ today_temperature^2 / 500, min 0 ] ), would be a decent basic formula. Under this formula, plants in the ground at 20 degrees C (cool room temperature) will lose around 40% of their water, while at 30 degrees C (quite hot out) will lose their water in a single day - this does not include regaining water from rain! This does not figure in mulch, retaining soil, etc - those should be worked out later, not on a first implementation. note: For outdoor plants only, although the final value for water should range from 0 to 100, at this point we should track if the number goes below 0 for use in step 3. That won't be necessary for indoor plants since we don't track rainfall for them.
Is the plant indoors or outdoors? If indoors, go to 3. Otherwise go to 2.
For outdoors plants, check how much rainfall there has been in the OMT over the past 24 hours and add that amount to its current water status. Increase water_level_current by todays_rainfall, so a rainfall of 100mm (a very rainy spring day) would put it from parched to 100%. Remember that the maximum is 100. In step 1, we kept potential water deficit through the day due to the weather being hot, and so that deficit must first be paid off by the rain before we top up the water level (this is to account for more of that rain evapourating on very hot days). Note: Tracking rainfall on the OMT level should be its own separate issue but ultimately we should get values in mm/day ranging from 0 to around 200.
Check the current water status compared to the plant's overwater_tolerance. If water is at or above the maximum tolerated level, do no more checks. Leave the plant happy until tomorrow. This ensures that overwatering is only the result of rain, not player activity.
If the current water status is below the plant's overwater_tolerance, and it was watered that day, bring its water status up to the max. OPTIONAL:
- Save the amount of added water needed as daily_watering. The next time the plant is watered, the number of units of water it expends should be equal to either 6 liters (the default) or daily_watering/2. This isn't a deficit value, it doesn't build up over time or anything, it's just there to see how much water the plant needs roughly and appropriately use water resources from there. These numbers are high because one tile of crops is a square meter of ground with multiple plants in it: if we later want to model individual plants in pots, we could reduce both the yield and the water requirements, but I am just writing for raised beds or farm plots here.
- I am personally OK with forgoing this and just having a plot take 6L of water per day if they need watering at all, regardless of season, rainfall, and temperature.
If water is above drought_tolerance or below overwater_tolerance, impact plant health. I will add another section for daily health calculations when I get there.

Implementation QoL notes Watering a single tile will require many liters of water. For this reason, the watering action will need to understand automatically going back to a water source and getting more water. Watering should be available as a zone action as soon as possible. In the future we should obviously look into automatic irrigation systems both primitive and technological.

Temperature

For temperature, we track four subfactors: frost_tolerance, which is pretty much a boolean, cold_injury_temp, winter_dormant_temp, and heat_injury_temp.

Throughout the day, we should track two variables through the OMT for outdoor plants, or per tile for indoor plants:

frost: Did the tile reach freezing temperatures at all today?
temp_avg: The average temperature of the tile/OMT through the 24h span I do not know enough about our temperature system but I suspect there will be some ways to simplify how these are calculated. I am going to leave that for a separate issue for now and take it for granted that we can calculate those values. Each 24h we do the following checks:
1. Check if frost is true. If it did, check if the plant has a value of "no" for frost_tolerance, and kill it if it does. If not, check if it has a value of "mandatory", and if it does, add a flag to the plant allowing it to bear fruit when ready, and also telling it to skip this step in the future.
2. Check if the plant has a winter_dormant_temp, if true go to 3, if false go to 4.
3. Check temp_avg > winter_dormant_temp. If true, go to 4. If false, make the plant dormant and switch to the dormant section.
4. Check temp_avg > cold_injury_temp. If true, go to 5. If false, damage the plant due to cold - see upcoming health section for damage.
5. Check temp_avg > heat_injury_temp. If false, no further calculations needed. The plant stays nice and healthy. If true, damage the plant due to cold - see upcoming health section for damage.

At some point we might consider frost blankets and mulch as ways of reducing the cold temperatures the plant experiences. That can wait for a later implementation.

Dormancy

A quick note on dormancy. This concept will need expansion at a later date but should not be part of first implementation beyond basics.

Once a plant is dormant, we should stop checking daily temperature and start checking it on a weekly basis, checking only if the temp is above either the dormant_temp or the cold_injury_temp. If below cold_injury it takes damage as usual in health (this means it will suffer less quickly because we're only checking weekly, don't multiply by 7 or anything). If above dormant_temp, we should wake the plant up and resume normal calculations. A newly awoken plant should start at minimum growth, as if freshly planted.

Later on, we can look into more nuanced changes.

Light

I will need to get some more information on how light is measured in-game to write this one up.

Tending plants

A plant has a base hardiness level determined in its json, as well as difficulty.

Health and Thrive

As discussed in many places above, health is a derived value that rises and falls based on how far out of bounds the other trackers are for a plant. It connects to two subsequent attributes. The first is thrive. This is an ongoing slow tracker of how often the plant has been unhealthy or healthy, and the higher it is, the better the plant's yields will be. The second is growth, which is simply a timer determining when the plant reaches maturity.

Describe alternatives you've considered

We've looked at more granular systems with weeds and plant diseases, but I am not at all convinced they add anything to just keeping this abstract. The current system is far too easy to produce food, but some of this could be simulated just with a skill check at the time of planting crops and having them then produce based on that. To that I say: 'meh'.

Additional context

Eventually this same system should be expanded to include native wild plants, making dandelions and burdock and other flowers and shrubs into crops under the same ruleset. That would allow garden bushes that don't live well in new england to naturally die out over time, and would also allow wild plants to grow and spread appropriately. As well, as the apocalypse progresses and weather patterns change, we'd see natural die-offs of plants that no longer suited their environment.

Once this is the case there is a concern that when you load a previously unvisited OMT, and we have to run through the growth and death of every plant in that OMT for several months, there could be an overhead cost. We'll need to test that, because the calculations here aren't that complex so it may not be a big deal. If it is, we may want to calculate a cache of what mapgen-placed plants will do over time without intervention, so that we don't have to run through months of simulation of plant life every time you load a new overmap tile later in the apocalypse. Instead we look at the cache and say 'it's been x months, load the automatic state for a grape after x months'. We'd pick a timeframe based on lag. I'm only writing this here to remember... managing pre-existing plants will need to be another PR that discusses spread and things.

One thing that might be nice would be for the player to just create a zone to farm, and say how much they want to plant, and of what. The skills/proficiencies of the player might increase the density of what you could grow.

Abstract away things like lettuce and corn growing well together when planted side by side, etc, etc.

Aka, twenty corn in a 5 * 4 plot, but you might be able to get 15 corn and 10 heads of lettuce in the same space once you've got a few crops under your belt or read a few books about soil nutrients and direct sunlight impact.

That might need a weird multi-tile structure to work, so that's a ways away yet.

Would the player get any penalty from repeatedly planting the same crop in the same area? I get that this is a bit of a newbie trap, given that land is not at all a premium, and only new players would get caught by this gotcha!, but it is realistic that plants would suffer if this isn't considered.
For the creation of fertilizers, I wonder if we should get compost piles, or worm vermicultures started? You could end up with better or worse quality soil, depending on what was in your compost. Bio-accumulation of toxins, and all that.
Side note, there are plants that can be grown better in pots, depending on local soil conditions. Things like green onions, garlic, radishes, etc. This does take up much more space, and they are movable, at the expense of utterly not being worth it to move them, calorie wise. Should this be allowed as an option? It would lead into indoor growing, and all of the catastrophic problems (for the player) therein.

Devil's Advocate crapping turds on your beautifully thought-out post! ---

Please, please don't get carried away. I'm begging you. We have so much stuff that's on a collision course with the reality vs gameplay right now, and I know it's going to get bad - bad for the the gameplay. Chris' reply involves which crops can be planted together!? Oy. See, it's unavoidable.

Erk i've read a lot of what you've done, and I love you guys. I do. Anyone that will freely code on a GPL/OSS project with no regard about how the code may be used, even monetized, is a hero, even if it's not the most technically clever or cutting-edge code. Doesn't matter if it's tensorflow probabilistic reasoning on CUDA rigs you'd rather farm bitcoins with or cataclsym-DDA, you're still a GNU hero! _( hey let's rename "zombie hordes" to "zombie hurds" - how appropriate, individual units functioning as a group.)_

Anytime there's tangential discussion on a given implementation on something in cdda lately, it inexplicably heads toward the intersection of Game & Reality. Almost every time. At first it bothered me but now I see it simply as it's what is going to happen, we can't prevent it.

So instead I just want you all to be painfully constantly reminded about it. (yeah I know, I do apologize about that part, the verbosity.)

Besides the dreaded "overhaul" word here, two other current discussions when I type this involve realistic ballistic glass, based on it's actual certification level for layers of composites & glass, weight, thickness, and how many rounds of a given caliber it can withstand; the other being about standing still is stopping bleeding too quickly and negates need for bandaging, and changing the ability of being able to self-treat arterial bleeds at least well enough to get to an NPC or autodoc that can help you, citing real-world reference when some medic who reached in and clamped with fingers.

In those examples in reality?

We would 100% DIE (in 30 seconds) if we had a deep chest wound with multiple arterial bleeds , broken limbs, and gaping bite wounds contaminated various XE compounds from our zed friends; you would very likely bleed out before you got your armour off to actually get to the bandages in the medkit in your survivor rucksack.

The ballistic glass? It would take 10 hours to install and if you made it possible to construct it (should be) the first 1000-hour task. You'd need a crane to lift it and a helper to install it without damaging it. And ballistic glass just like plates in body armour are single use, you only ever use a damaged one again when the only other option is to go without. Once hit they are structurally compromised, destroyed.

I always make a jab too about the food system now with the caloric density being moved over to the ingredients so that recipes are variable in nutrition and vitamin load - my joke being, once someone extends the ingredients in the JSON to include the essential and near-essential amino acids, we'll use the in-game cdda dietician to map out our actual IRL eating.

Please, please always be mindful - we're gamers first. Then coders, content developers, humans. Gamer supersedes.

Reality involves your loved ones dying, lovers lying and cheating, getting fired or laid off, growing old, getting sick, and dying. We play games to FORGET about that shit for a little while. I don't want to have to retain a zed lawyer for zed court for all the zed atrocities I've committed. I don't want to pay monthly bills to the Merchants faction for this squat I'm living in. Who would? It's boring.

Please keep the fun aspect in mind first before implementing anything that will be even the least bit button-mashy or micromanage-y. I too want to start a Cataclysm Coffee Company and sell it back to the merchants for an insane profit or some unique weapon they won't sell me but only trade for 500# of coffee, but we want to play games to have fun, not do work! To distract us from reality, not emulate it.

Reality is shit. :hankey:

To borrow a quote, this sounds great... but it also needs to "just work". As long as it ends up hitting the stated points (native plants spread naturally, non-natives tend to die out over time, farming has options, highly invested farming is more highly rewarding) I think I'll love to see it.

Here's some concerns or points I want to bring up in the topic.

To simplify matters, when plants are put outside, we should assume all plants in the same OMT experience the same amount of light, the same range of temperatures, and the same amount of rainfall. We can track this on the OMT level throughout the day and apply them to plants in the tile at the end of the day.

But, is this going to be obvious or available to the player? OMTs are not something that is well-defined for the player's local boundaries, where farming takes place. Imagine in a worst case scenario where two adjacent OMTs have drastically different conditions over a long enough timeframe that a player ends up with two halves of a field - one ruined, one pristine. And their cardinal sin? Building over an invisible boundary. This does not lend to a good player experience.

To some extent such behavior would be, in my opinion, an abject failure. But minor differences between adjacent tiles, where such changes are not immediately recognizeable... that's where the potential for insidious problems lay. I believe some form of equalization would be necessary to avoid this, where any given tile is averaged or in some way clamped in range to the values of its neighbors.

@chrispikula

create a zone to farm, and say how much they want to plant, and of what

That's a separate thing, but just fine. This is about setting up the mechanics of farming, having a 'zone plant' definition like this would be a wholly different discussion not at all related to how farming works.

Would the player get any penalty from repeatedly planting the same crop in the same area

No, that also would be abstracted at the level of a skill check when planting.

For the creation of fertilizers, I wonder if we should get compost piles, or worm vermicultures started?

That's compatible with the farming system laid out here, but also separate.

there are plants that can be grown better in pots, depending on local soil conditions.

See the proposal: I wouldn't say we should get into the granularity of soil conditions, but a plant that needs more tending would in general do better in a pot in this example. There's some argument that certain plants could like pots better than others, but I don't personally think we need to delve too far into that. It again falls into the "player vs avatar" knowledge thing: I assume a knowledgeable avatar uses a large enough pot/raised bed for a happy plant.

@Anaglyphic Please read the issue before commenting. The very first section talks about how the whole purpose of writing this up carefully is to get more nuanced farming without making it a chore, and the crux of this proposal is abstracting most of the work of farming into a single tend stat.

@RenechCDDA

Imagine in a worst case scenario where two adjacent OMTs have drastically different conditions over a long enough timeframe that a player ends up with two halves of a field - one ruined, one pristine.

The reason to abstract it to the OMT level is that that's the level that light and weather are calculated on. In order to get the experience you're describing the terrain types would have to be dramatically and visibly different - one desert, one grass, for example. The only exception is water, if a storm only partly hits you, which is one reason for writing the overwatering system as I've done so that you don't get punished for watering your plants.

I endorse this farming mechanics concept. Farming is really boring as is, and interacting with it as it slowly grows will make the process far more enjoyable IMO.

@I-am-Erk

@chrispikula

create a zone to farm, and say how much they want to plant, and of what

That's a separate thing, but just fine. This is about setting up the mechanics of farming, having a 'zone plant' definition like this would be a wholly different discussion not at all related to how farming works.

I was thinking of the plot thing as a way to make growing crops still kind of 'fun'. If I have to tend each and every crop tile, many times during the growing cycle? Oh, please no. I just won't grow crops at all then.

Currently, I usually try to make small vehicles with plows, seed drills, etc, before I start gardening by hand. If feels less real-world time intensive.

There is much fun in SS13 tending for plants so I appreciate this touch of ( planed, in discussion ) love for plants. Let not dismiss any comment that involve an other game, so please read me and discuss what you feel is wrong. Please tell me if this comment is irrelevant so I temper/deny it.

The tempo is of course not the same between these two games, and so while we allow the player to keep its plants tended and he still has time to explore, I see it as a great addition to the game. SS13 had to be unrealistic in regard to rounds duration, in CDDA the time scale allow for a better picture. IRL I have a garden not that small nor big, I can't really leave home for more than 2 days between spring and summer-end. I feel 2 days exploration trips are OK but I can't tell for nobody except me. Are 2-3 days exploration trips inline with the current game loop ?

I use agriculture quite intensively in most on my saves, yet I never really used plows/drills except for fun. More time to mechanic then farm than just farm ( also, I love NPC ) Their usefulness ( the machines ) is debatable. Manual plowing is the most time consuming task at the moment if manually executed ( by a lot, shovel work is hard, for a reason I can feel ). Mechanical plowing don't produce "dirt etc" which is another question.

Any works on plants would be appreciated by at least some of the players. Those who find it a chore may not use the system even in its actual state. Those who find it too easy can be disappointed by the lack of ( game ) mechanics behind.

I also want to point out that the actual amount of wield is not pointless ( if it had to be reworked for balance purposes I wont bitch ). The tending of crops could encourage the player to plow more than needed, in anticipation of loss.

It was already implied by the author of the discussion that the player may have text messages about the ( plants he is tending ) needs. Relative to skill(s). May the unskilled characters use tools in the first steps ? ( thermometer, hydrometer, kinda magic plant analyzer, or even a "plants observation" activity ? )

Sorry if irrelevant. Tell me, so it happen less/no more.

Eh, it's really overcomplicated for such a niche game aspect. Like, yeah, it would be nice to oversimulate absolutely everything, but these things aren't free from the performance standpoint. Long activities already take too long, without every single flower in existence tracking 5 different attributes every turn. Inb4 "someone will later create a magical implementation that will take 0 CPU cycles to do a million calculations, this is just a design proposal".

Your post is the only time turn is mentioned in the context of time in this post (~~in fact, no mention of when updates to plant data occur is made in this entire thread except by you~~ incorrect). Making random assumptions not supported by the proposal is not helpful to the discussion, please do not do that.

I was thinking of the plot thing as a way to make growing crops still kind of 'fun'. If I have to tend each and every crop tile, many times during the growing cycle? Oh, please no. I just won't grow crops at all then.

I imagine that "tend all plants" will be a zone command just like farming commands are presently. It's not that I don't want this, it's that that's not what this issue is about.

May the unskilled characters use tools in the first steps ? ( thermometer, hydrometer, kinda magic plant analyzer, or even a "plants observation" activity ? )

That's an interesting point. I don't know about gating them to diagnosing problems, that might be manageable

I have to (somewhat) agree with Anaglyphic: this is a well thought out idea, but sounds a bit tedious as well as potentially bug-prone (hello, vitamin deficiencies that didn't do anything or NPCs growing obese without food intake)

I see potential problems if the reality bubble is involved at all, as some players (such as myself) may want to use existing farms adjacent to a base camp. If the calculations can be handled without involving the reality bubble I think that may be fine.

Having companions tend crops at or near base camps (or the location where the PC is currently "settled", as it would be good if a base camp wouldn't be required) would be a good use of companions.

I'd suggest two different attributes for each plot tile, rather than the single Health one. In addition to the Health of the plot's plants, I'd add a metric for density or something similar, such that a perfect farmer would, under perfect conditions, keep the plant density at 100% as well as the plants at 100% health. Various mishaps such as poor planting, and some failures at dealing with problems would reduce the density, thus reducing the potential yield. Health, on the other hand, would fluctuate and can recover, but if you've only got 50% of your potato plants left at harvest, you can't get more than 50% of the potential maximum yield (and it would be lower than that if the the Health isn't 100%). [I ignore that fewer plants might allow the remaining ones to be larger for some crops, and thus recover some of the losses. That's a level of detail I don't think would add to the game]. In line with that, I'd have the planter's skill (and luck) affect the starting density, but with the starting tend_decay being the nominal one for that crop. Each tending attempt would result in a new tend_decay based on skill, plant health (a plant in poor condition would probably need more frequent "help" than a healthy one) and the crop used, but without the planter's skill affecting it.

@PatrikLundell

I see potential problems if the reality bubble is involved at all, as some players (such as myself) may want to use existing farms adjacent to a base camp

One reason to do math on a 24 hour basis is that it should be easy to track things like weather since the last time the map was loaded into reality, and update it when it reloads. That will allow things to grow and progress without the reality bubble.

Having companions tend crops at or near base camps

That is an assumption of this system, but not part of the basic mechanics proposal. NPCs tending crops is without question something we want/need.

I'd add a metric for density or something similar

You're actually the second person to suggest something like this, I'm going to see about including it as I add numbers and things. It also stops people from gaming Health somehow. As for how it will interact with tend_decay, I'll have to play around with the numbers.

@Zireael07 and others

OK, I've been polite, I'm going to get a bit more firm now because this is the third post like this after I attempted to point out the problems with the other ones nicely. This is a concept post, not an implementation. If you have feedback on the concept to improve it, please share it. If you just want to say "this could have bugs" or "watch out! Don't add micromanagement!", or "realism! ugh!", those are useless additions that do not provide actionable feedback. Please don't bother, it is a waste of all our time. I cannot improve this suggestion based on feedback like "other new systems have had bugs".

If you're not sure about it, wait a day or so for me to finish writing out the implementation recommendations with math and frequency so you can actually comment on it instead of just cautioning me that you imagine that I might suggest something tedious.

I have added some implementation information about specifically watering, temperature, and how plant json will look. Working on tending now, light can wait for a bit.

I also added this bit to the opening, in the hopes of allaying more "I imagine I might not like this" posts:

Key balance note: The balance intent of this is that if you plant crops outdoors, most plants should be hardy enough to get water from the rain and produce at least some yield with a minimum of tending. However if you tend your plants and water them, you'll get better yields. If you want to grow more delicate crops, they will need more attention, and maybe something like a greenhouse.

Currently CDDA doesn't model the majority of precipitation in New England. What are you thinking is the best way to take that into account on the water tending value? Apologies if I've missed this somewhere else in the discussion.

Edit: Just reread the note above mine and I think I see what you are saying and how that would interact.

Currently CDDA doesn't model the majority of precipitation in New England. What are you thinking is the best way to take that into account on the water tending value? Apologies if I've missed this somewhere else in the discussion.

Edit: Just reread the note above mine and I think I see what you are saying and how that would interact.

Yeah the numbers may need to be adjusted based on how we do rainfall, that's an issue that has to be sorted out in the directly related but semi-separate issue of tracking rainfall at the OMT level.

Looked at the newly proposed formula and concepts, seems good to me so far. My only concern is the rainfall. This is technically within the realm of 'numbers to be adjusted', but bear with me for a moment :)

30-40% water loss per day is possibly an order of magnitude too high. I know that weather was strenuously adjusted some time ago using real life data for the New England region, but the result is that currently rainfall events are scarce. Very scarce. So scarce that any number for per-day loss for untended, wild plants might boil down to either A) always surviving successfully or B) never surviving successfully. Attempts to balance in between that might be doomed to failure just due to the weather conditions.

This could be tackled from another direction though. Maximum water intake per day and a total water amount required over a single generation to successfully flower/germinate. (e.g. max 20mL per day, 2L total intake required to fruit = 100 day expecting growing cycle with a cap, so past 200 days it's just been stunted too much and will either die or not fruit). This could possibly be coupled with a local tile reservoir which does drain per-day according to the temperature or other factors, such as the bedding material. It could also be a OMT-wide reservoir based on shared root systems, as I suspect a per-tile reservoir (especially if wild spreading plants are simulated) might cause too much performance overhead.

This means that most farmed crops would still require daily or semi-daily watering while hardier wild plants could survive on rainfall alone. And of course it can also lead to interesting behaviors emerging from these systems, such as it being incredibly difficult to cultivate trees or large plants in a prairie region. (Although New England is not known for having prairies!)

@RenechCDDA The main issue I see with tracking moisture like that is that for contributors entering water needs, it doesn't have much resemblance to the kind of information we can get from gardening websites. That's not a strict barrier, but it means we need a lot more levels of translation to know how to take 'highly drought tolerant' and convert it to 'how much water over what time does this plant need'.

Ultimately the issue of rainfall per OMT is one that, at most, just needs us to ensure the average rainfall per OMT is being calculated at values that match new england. This doesn't necessarily have anything to do with in-game rainfall events per day, as rainfall events are only seen when there's enough rain to have a gameplay effect. We assume light drizzle isn't something that needs game modelling, but I believe it is still monitored in the code and can be accounted for at the overmap tracking level. That's really not the barrier it looks like.

I am not inclined to reduce water loss to a very low level and assume the rain is just there, because then this won't be extendible to other biomes or to changing weather patterns over time.

I'm guessing that specific types of OMT's will have lower water requirements/loss rates? Swamps, and adjacent to rivers, for example.

For the moment, no. It's possibly we could look at nearby standing/running water as irrigation. I don't think that should be an OMT level function

I'm going to close this and redirect folks to the identical discussion thread, https://github.com/CleverRaven/Cataclysm-DDA/discussions/49327 - I think this is unwieldy as an issue, and should instead be a "master discussion" which I will later break into much smaller issues combined under a single Project.

CleverRaven / Cataclysm-DDA

Farming overhaul feature recommendations/discussion #49302