# Xenobotanical Update - The FROOT must flow!

## Abstract

This is a design doc for my overall thoughts on an expansion to the gardener/fruit mechanics for xenomorphs, in order to expand their gameplay mechanics.

Right now, gardeners are just a strain for drones, and they're not extremely useful. They can only make six fruits (the included picture is from an exploit), and because of that they're pressured more or less to only really make healing fruits. I really enjoyed gardener, so I wanted to try to expand upon this mechanic, and make it more central to the xenomorph playstyle. And I'm gonna code it.

## Goals

* Expand upon the base xenomorph fruit system to create a different way to be a supportive role for the xenomorph faction.
* Expand upon the base hive structure, making hives more important to defend.
* Make it fun to grow and use fruit.

## Non-goals

<!-- Just like goals, but the opposite! Every feature has boundaries it won't step over. These should be written as if they start with "We will not...". -->
* Make it a requirement for the hive; this should be something they can do, but not need to, incase they find it boring.
* Replace existing healing factors. It's supplimental, not replacing.
* Slow down or inhibit xenomorphs from performing their existing duties.

## Content

<!-- Now's where you get into clear detail about everything your feature does. **You should still be explaining 'why' things are that way, *as* you describe what.** Be as detailed as possible. -->

#### *BUT WHAT IS IT?*

So it's a total rework for drones; rather than being able to plant resin fruits anywhere, but a limit of 6. The idea is to flip this on it's head; xenos can grow unlimited fruits, but they can only grow them in specific resin plots, similar to human hydroponics trays. These trays will be expensive, so they'll be placed in the hive; you CAN place them outside, but they're not very useful for combat themselves, and they'll be easy to loose. Drone castes can grow fruits in these plots, without limit.

#### *Will that not make hundreds of fruits?*

Possibly?
I had a few ideas about this. First, the fruits would take longer to grow - not much longer, probably about two to four minutes each, meaning xenos would want to expand the number of plots they have in order to grow more fruit. As well, we could make fruits expire after a specified time, or make them have reduced effects with time. This way, you'd constantly be growing fruits, but you wouldn't have a million active fruits.

#### *Why would your average xenomorph use this?*

Well, I was imagining this could be a sort of xenomorph-stim; give xenos pockets again, the number depending on caste and such, and let them hold fruits. This way, a runner could have a speed fruit, or a healing fruit, to give them a slight boost. That could improve your basic alien gameplay, adding a new mechanic, as buffs are either temporary AOE, or given directly from the queen. This would give more agency to an average player, and can make the playstyle more skill based, since you would have to choose which fruits to take, and when to use them.

#### *Would this not mean you would need xenomorph supply lines?*

Possibly! I think the idea is cool, but I can see why it'd be annoying. Therefore, an alternative could be to add in a sort of "resin box" structure that can only be built on hive weeds. Resin boxes would have a global inventory, so you could put in and pull fruit from any resin box, removing the need for a supply line but giving more reasons to defend mini-hives. The destruction of a box could drop a few fruits from the inventory, giving marines a way to get fruits for their research department.

#### *I don't think that the current fruits are good enough to expand on this.*

Currently, the fruits are designed to be made by a specific drone strain, and not be entirely game changing. The fruits may need reworks in order to be useful for this, but at the moment I'd like to just keep the fruits as-is, just to make sure the base mechanic is good.

## Alternatives

<!-- Provide potential alternatives to your feature, either ones that align with your design values, or ones that don't that you suspect will be suggested. If you are including the latter, make sure to explain why you didn't choose that. -->
Will discuss with other people and players first.
## Potential Changes

<!-- Most of the time you're not going to get the best design first try. It helps to try your best to predict what *could* go wrong, and suggest alternatives that can be taken, without sacrificing your design. -->
Will discuss with other people and players first.