Recently we have been discussing how to rework the ATP system in Thrive to work more like a sort of stamina bar. The reasoning behind this is that currently the ATP bar is entirely meaningless except for when the player is either currently out of resources, or decides to leave the editor with less generation than movement cost. Additionally, a stamina system can support a new strategic layer to the game which would make things more interesting and hopefully enjoyable.
After a bit of thinking after our most recent discussion, I feel I have finally developed a more concrete idea for how a reimagined ATP system could work, and have decided to create this thread so it and any future discussion is not easily lost in the relatively disorganized nature of our developer chatroom.
The Main Idea:
My proposal so far is that instead of reworking standard movement cost to always drain a player’s ATP when moving, we could grant new abilities and features to the players and AI that will allow them to begin willingly expending their excess ATP in exchange for various benefits. My reasoning behind this is that we will not be taking anything away from the current gameplay this way, and instead will be adding on to what already exists. This will be less likely to impact playability and enjoyability.
An example would be something like this: A cell want’s to boost themselves, so they enter boost mode and start moving 20% faster. By the time the danger passes, they have expended half their ATP and exit boost mode to save their energy, and now need to wait a couple seconds to let it regen so they can be ready to escape the next danger. They could expend all their energy but that would leave them unable to sprint for a while, and would be more vulnerable. It’s this strategic layer that I would love to see in Thrive.
ATP and how it will be consumed:
As of now, ATP quantity is only important so long as the cell is capable of producing more than is consumed which is currently not difficult at all! A great amount of discussion was held on how we would change this,and I have now decided that ATP production and consumption under normal circumstances are fine as is. Instead I am proposing that when a cell chooses to perform certain actions, their ATP production will be either slowed down or completely stopped depending on what works better for us. As long as the player still has ATP, they will be able to continue using their ability until they run out of ATP or stop the action. Once the cell is no longer using such an action, their ATP generation will resume it’s normal pace after a momentary pause (Probably about a second or two).
The important question here is; Should we slow down ATP production? Or stop it outright? I personally feel like slowing down ATP production would be better (Maybe something like a 25% reduction), as it would help mitigate the problem of running out of ATP much too quickly, it would also mean that certain incredibly efficient cells could potentially bypass the ATP cost all-together!
With this system in mind, we need to decide on what actions and abilities should reduce the player’s ATP. An obvious choice is “sprinting” which I will discuss below, but it’s also worth considering if mechanics such as engulfment mode or shooting projectiles should also drain the player’s ATP.
“Sprinting” was one of the topics brought up most often during our discussion, since it is a natural and obvious use of stamina mechanics in any videogame. Sprinting will be a togglable mode that drains the cell’s ATP in return for a boost of speed, which can be a game changer for predator and prey both as it will allow cells to speed to safety. It will need to be used carefully however, because if a cell expends all their ATP they might not be able to dash when they really need to!
There are many ways to go about implementing a sprinting feature like this, so I will list a couple potential methods below;
Method A: Provide a multiplier or simple addition to the cell’s base speed stat upon entering sprint mode.
This would simply be applying a bonus to a cell’s speed when they sprint. Something like a 25% or +30 increase to speed when activated. This is easy to understand, and I feel like it could be easy to implement as well.
Method B: Apply a dynamic multiplier or additive bonus determined by placed parts.
This method is a bit different, in that instead of all cells having the same sprint speed, the bonus would be determined by parts that provide said bonuses. For instance, flagella could have their normal base movement bonus, but also provide a 4% sprinting speed bonus. So a cell with 2 flagella would move 8% faster when sprinting! This method is more complex, but also much more interesting than the previous method due to it’s dynamic style. This method would also give us a great mechanical use for something like microbial jets which could provide a large sprint bonus but no normal movement bonus were we to be so inclined.
If we go with this method, I would prefer if sprinting would be disabled unless the player had parts that enabled it.
Changes to Balance:
This wont work too well without a moderately intensive change to how ATP generation and storage is handled unfortunately. Cells currently do not store very much ATP, and also consume it REALLY quickly when they suddenly dont produce any at all. In order to allow this feature to function properly, we will need to see about either separating ATP storage from the current all-encompassing capacity value in order to allow cells to store much more ATP, drastically rebalance ATP production and consumption rates to allow for slower regen and drain, or both. The objective here is to have ATP drain and regen at reasonable rates on average so that cells will be able to perform actions for a decent amount of time, while also being mindful of wasting ATP incase they find themselves in a bad situation.
I unfortunately dont have any concrete ideas for specific values at this time, as this is something we will have to experiment with. I will definitely think about it though, especially when I get some feedback from everyone else!
Many other ideas and concepts have previously arisen from this discussion and haven’t exactly been ruled out, so I might go about posting them here later if the other developers do not. That being said I look forward to seeing what everyone thinks of this idea, and apologize if this post is particularly disorganized.