Given some recent feedback we have received in regards to the current state of gameplay in Thrive, I believe it’s a good time to review our current state of progression in the game and provide a new paradigm in how progression should be approached.
Currently in Thrive, the range of progression has always emphasized incremental growth and expansion of the player’s organism as they evolve to fill a specific style of gameplay or niche. In order to progress, the player need only place more parts to expand their energy collection capabilities to prepare for the nucleus, typically investing in specific strategies to do so. Players are essentially discouraged from removing older parts in favor of expanding their size with new parts of any kind. The result is a steady pace of growth that can be pretty satisfying, but can unfortunately result in some pretty messy organisms if the player is unfamiliar with the winning strategies of Thrive.
This method has served us well in it’s time, but unfortunately now falls short of expectation with the introduction of the dynamic environment with it’s greatest flaw now shining through; Our model of progression currently emphasizes growth and specialization, but not adaptation. The environment can change a lot in the span of a million years, and in order to allow our players to adapt to changing conditions, we are going to need to adjust the rules of the game to afford greater agency in the hands of the player.
The Proteome Progression Model
The concept of a proteome refers to all proteins encoded within an organism’s genome irrespective of expression. If a cell possesses genes for lactase but otherwise does not express it, that protein still resides within their proteome despite.
In the realm of genetics, replication errors that alter the expression of genes are by far the most abundant and likely method of mutation. A single point mutation can malform a cell’s signaling receptor and force it to continuously produce lactase where it would have otherwise only done so under specific conditions or perhaps not at all.
Drawing inspiration from these real life concepts of biology and genetic principles, I have devised a new experimental system of progression with the intent to simulate situational expression of pre-existent genes in the organism to better respond to environmental changes. My hope is that this model will provide players with greater situational agency, while also inspiring a more tactical approach to Thrive’s editor.
Now that the environment is capable of changing, players will need to be able to quickly adapt to an environment that can completely flip on it’s head within a couple generations or more.
Parts will average around 20-25 MP per hex in ideal conditions, allowing roughly up to 5 protein changes per session. This will provide players with the extra leniency they need to ensure their own survival should their intended way of life no longer pan out as anticipated. As you might be aware however, this advantage is sure to diminish with size as it becomes increasingly time-consuming to shift focus from one metabolism to the next. Just like in real life, simple bacteria will prove to be uncontested in their swift adaptability.
Being able to freely adapt any protein as the situation demands would be a bit uninteresting on it’s own so in order to spice things up a bit, placing parts with no prior copies present will incur a greater MP cost; Probably around +40 MP. This is intended to simulate the difficulty of evolving novel proteins and will encourage players to sometimes keep at least one defunct protein around should it be potentially useful when conditions change. This is intended to simulate how the proteome works in reality, albeit largely simplified for sake of gameplay. It also adds another use to increased size in a cell, as more size means more space for unused proteins.
Parts that currently exist within the cell will be highlighted with a soft glow in the parts-list to better distinguish them from unowned parts. A graphics artist would probably have a much better idea though, as UI is not quite my strongest forte.
Unlike the internal workings of a cell, the shape itself is the result of complex interactions between several proteins working in tandem to achieve a desired anatomy. As such, anatomical changes in an organism tend to be (but not always) a much more intensive and gradual process in evolution. Thus placing parts to create new hexes will cost additional MP; Probably +20 MP per hex. The primary purpose of this decision is to both limit the amount of cellular complexity players can stack on in a single session, as well as to inspire a more engaging decision-making process when evolving the cell.
With up to five potential part placements within a limited space, we will need to adjust how players make changes to their cell to keep the editor approachable. Therefore all parts can be instantly replaced by placing new parts over them. With or without the +10 MP cost, this will allow players to easily make changes to their cell’s metabolism with a single click so long as it does not adjust the shape or size of their cell.
Considerations:
This model of progression is pretty much guaranteed to make adaptation easier for players, and I suspect it will likely feel satisfying to progress as well.
The Nucleus
The biggest foreseeable obstruction to it’s functionality however is the nucleus, as it’s large size is already a substantial hurdle in the present game. Unlike the metabolic parts which have smaller precursors to replace such as the chloroplast, the nucleus is an entire 10 hexes of space that grants no direct benefit to the cell’s processes that must replace other more vital parts. With this new system of progression, the players won’t be able to just slap that sizable sucker onto the side of their cell either, they will actually have to create empty space in advance to be dedicated to the nucleus at a later time or else sacrifice vital metabolic parts.
I predict two potential solutions to this problem, but would like to encourage playtesting before attempting to implement either. Personally, I want neither of them if we can reasonably get away with it.
-
Reduce the nucleus part to 7 hexes in size.
-
Implement a new proto-nucleus that is smaller in size and benefits to act as an additional step of progression.
Method 1 is by far the easiest and most preferred solution for sake of simplicity. A 7 hex nucleus is substantially easier to place on the cell and only requires small adjustments to the model. It also makes the organelle more symmetrical which is more of a tertiary benefit. I’ve actually flirted with doing this in the past and even prototyped the change. It didn’t create any substantial problems at the time.
For those who don’t know, the nucleus model is actually three separate models in a trench coat. The positioning and scale of the nucleus proper, as well as it’s side organs can be adjusted independently using the godot editor alone if we wanted.
Method 2 takes the paradigm shift much further in it’s own unique way by basically making for an awkward transition stage between bacterial and eukaryotic. I liken it to the current situation with our early and late multicellular stages… But if we must, I would recommend the proto-nucleus be a 3-4 or 6-7 hex part that expands the player’s symbiont capacity by +1 and effective cell size by +25%.
Note that these methods don’t have to be mutually exclusive if it really comes down to it.
Adaptive Cost Information
Informing the players how much parts will cost when and when not creating new hexes is another more difficult subject that may require some more complex programming and the addition of a completely new UI feature.
I suspect the most feasible solution is the inclusion of a “price tag” that is projected on the top right of the user’s cursor when hovered over with a part selected from the list. The price would be the base price plus any applicable modifiers. It’s not an easy solution, and I would like feedback on this matter when possible.
In this example, the part would cost 40 MP since it is not creating any additional hexes.
We would want to accompany this feedback with a quick tutorial blurb during the player’s first editor session, probably around the same period the game wants you to place your first part.
Conditionals
The only other foreseeable issue in my own eyes is implementing the conditional cost changes, which requires some know-how I do not personally possess. I have been informed by one of our programmers that the changes could be easy, but I am aware that our MP cost calculations can already be rather finicky in the editor which can potentially cause unforeseen issues when additional conditionals are implemented.