Microbe Stage GDD

NickTheNick wrote:

I have a question towards the new cessation of homeostasis approach to death. What would be the definition of death then? When all compound processes in the cell have stopped due to lack of reactants? How does bursting affect this?

Although I see that it's true that cells can burst but still be alive, I think the advantage to the osmoregulatory approach to death is that it defines cell bursting as death, and all means of killing things or approaching death revolve around having the cell burst. If we are to use the newly mentioned system for death, there should be some clear definitions of what kills a cell.

I'm in favor of death meaning bursting as well, since that means we can easily show to the player the compounds going back into the environment.

I like bursting too -- but what event could we use for death that would fit consistently with walled cells as well? That was the main reason I was trying to look at things differently, to find a point when we could reasonably say that a walled cell ain't alive no more and there's no use hoping and waiting and it's time to move on and play another cell. Maybe a time-speeding-up-screen-turning-gray effect as the inside of the cell turns to mush, leaving just a husk that decays away...

This is a video of plant cell dying, it undergoes apoptosis but still

video:

I don't think time speeding and showing everything decay is necessary, just graying out the inside of the cell and organelles get replaced with little bubbles to look like a mush.

moopli wrote:

I like bursting too -- but what event could we use for death that would fit consistently with walled cells as well? That was the main reason I was trying to look at things differently, to find a point when we could reasonably say that a walled cell ain't alive no more and there's no use hoping and waiting and it's time to move on and play another cell. Maybe a time-speeding-up-screen-turning-gray effect as the inside of the cell turns to mush, leaving just a husk that decays away...

I would suggest bursting combined with destruction of the cell wall. It crumbles as it bursts.

It think that sounds like a good idea.

Random quick question: Why do we use a reproductase quota instead of a DNA-replicated quota to measure progress to reproduction?

The change would be simple: replace all user-visible instances of "reproductase" with "%DNA replicated". You reach 100%, you now have enough DNA to spawn a functional daughter cell.

moopli wrote:

Random quick question: Why do we use a reproductase quota instead of a DNA-replicated quota to measure progress to reproduction?

The change would be simple: replace all user-visible instances of "reproductase" with "%DNA replicated". You reach 100%, you now have enough DNA to spawn a functional daughter cell.

We were thinking of it as both a metabolic and genetic barrier, but I suppose that since it's all under the hood anyway it makes no difference whether we think of it as purely genetic or genetic and metabolic. If you want, (and have the clearance, i don't know if you do yet), and others don't ahve a problem with it, feel free to open up a task in github about it.

Well whenever ATP passes a certain threshold, reproductase starts being produced over time. Falling below this threshold will not decrease reproductase levels, but cancel its production until the threshold is passed again. In this respect I don't think it really conveys DNA replication, but a combination of that with metabolism, like ~scio mentioned.

So, could we not have a marker for where the player is in the cell cycle? We can simplify the cycle greatly, as G2 is just "ready to split, but player hasn't pressed button yet", and mitosis is covered by some animation and diving into editor. This leaves us with G1 (the growth/metabolism part of the equation) and S (the replication part).

The simplest option would be to assume our cells don't have separate G1 and S phases, and simply have a DNA replication meter that behaves like reproductase. If we want to add some depth to each cycle, we could use a cell cycle meter instead of DNA, and have the last chunk actively eat a lot of resources (feed the beast!) to produce the DNA needed for a new cell.

I think I'll wait a bit before opening an issue (I do have clearance though), give it more time for criticism.

Moopli wrote:

Maybe we need a how-close-your-internal-state-is-to-being-dead predictor. The predictor would consider ATP level, organelle function, cytoplasm levels and some other things, and would display what looks like a health bar but works subtly differently -- it isn't dropping your health to zero which kills you, it's killing you which drops your health to zero. As more and more of your organelles stop functioning, as the amount of ATP on the market drops lower and lower (runaway deflation :D!), the health bar drops to signal in an obvious way that you're pretty much dead, but you could still pull through by some miracle. As long as there's still some slight chance that you could pull through, the health bar stays above zero and you can continue to play as the cell. Then eventually, the cascading failures cause everything to shut down; and it's time to go to sleep since you've been trying to keep that microbe alive into the wee hours of the night.

For UI, a simple bar will be enough, perhaps with some pretty glow/pulse/flicker effect for nearing death. Then, for a player that wants to know how much trouble they're in, they could click on the bar and get an overlay (perhaps the pause-game-zoom-in-on-microbe thing) of how functional current systems are. This should be more than just eye candy, since, for example, a poorly-functioning nucleus won't be replicating DNA, and will do slower transcription, and a resource-starved cytoskeleton won't be holding the cell's shape all too well and won't be moving things around inside (or moving flagella and cilia) much.

However, a player shouldn't have to open that too much -- we're doing the hard work of distilling all the information on how functional and alive the cell is so the player doesn't have to.

On the GUI thread I recently thought of using a radar diagram to show compound levels/organelle health.

me wrote:

I have an idea on how to display organelle health and compound capacity very intuitively.
Using a Radar Chart we can show the levels of many compounds simultaneously and it becomes very obvious when compound balance is disrupted. it also will most likely save on screenspace, since we could easily overlay compound level and organelle health diagrams onto one chart using two different line colors.

I like feeding this idea into a more general health bar.
It would be possible to calculate area of the chart and have it translate directly into the health bar, but that's obviously not a good idea since lacking just one compound will often result in death.

We need some logical system whereby one extremely low value for one variable can have an absolute effect on the combined interpretation of all variables. This could be instituted by an interaction thresholding system. The system would work like this:

All compounds have a range from zero to n, where n is the largest amount of compound that can exist in the cell.

The level of our compound of interest is given by c

The cell has sufficient levels of that compound when c is above a threshold level K

On the radar chart, the level of a compound on a compound's axis from 0 to n is shown, with N being normalized to a general axis size for display. K is also shown on the axis.

The displayed level of any compound (d) is given by a piece-wise function

d =
1 when c>K
c/K when c<K

The health bar shows the combined d values for all compounds

health (h) = d(1)*d(2)*d(3)*...*d(however many compounds you're tracking)

In a perfectly healthy cell, c for any value is greater than the required K value, and thus health shows as 1, since it is equal to 1*1*1*1...etc
As soon as one compound drops below a healthy level, the system begins to tank, and if any compound in the system drops to 0, h drops to 0.

This might seem like an elegant system, but it's not quite good enough. There will be complications.

For instance, what if having none of a compound is bad for you, but won't kill you? In this case, we need to establish a minimum lower bound for that compound's d value and interpolate between that value and the K value as c approaches zero for that compound

I'm sure there are other problems, but I'd like to post this before it gets too long.

Also, I'm cool with the cell-cycle timer idea.

At the moment I have no solutions to the problems you mentioned ~scio, but I wanted to say I also agree with using a cell cycle system for reproduction.

One important complication is the dynamics of the system -- if the first 10 derivatives of ATP level are pointing down, having a high ATP store means little.

Luckily however, in the case of our simulation all reactions are order 1, so a linear extrapolation will suffice. So we can do a quick simulation, linearly extrapolating between iterations, and gauge the stability of the compound stores. Ugly, not the cheapest, but still pretty darn cheap, and it should give us reasonable stability information.

However, how that stability can get turned into health info eludes me yet.

Why do you suggest we gauge stability as part of health? I would rather keep the health value simple and stability/extrapolation confined to the radar diagram readout.

Hmm, I'm reconsidering -- I was thinking, since a microbe that's losing ATP at an alarming rate has not long to live, it wouldn't make sense to say it has a lot of health even if it is otherwise alright. But you have a good point -- health value should be simple. In the above example, the player would be suitably warned anyway by their ATP stores dropping like crazy and the associated health loss, so it's a nonissue.

Sorry to interrupt, but here is the download for an updated version of the GDD:

http://www.mediafire.com/view/qs945eb8hwgssa8/Game_Design_Document_-_Microbe_Stage_v2.0.0.docx

Note: The format is messed up in the Mediafire document viewer, so I recommend you download it and open it in MS Word.

I've made several changes, which should all be outlined in the Editing Notes section of the GDD. Some notable changes I made include:

• Adding an Editing Notes section, to keep track of what was changed each update, and to leave tasks for future editors.
  
• The whole section of functional edges was removed. From what I could tell it was not consistent with the concept of the microbe stage.
  
• Added appendix with tables explaining compounds, compound processes, and organelles
  
• Added some new concept agreed on recently in the forums (such as unlocking organelles through plasmids)
  
• Changed some concepts that have since been changed (such as moving organelles or hexes being free)
  
• If something is highlighted in yellow it requires revision
  

The GDD still needs work on areas like procedural generation and placement of cells and compounds, as well as an update on agents based on recent discussions between moopli and ~scio (Don't know if it has been concluded yet).

Do you mind if I DL this and then copy it to Google Docs so we can edit it as a group rather than force you to take the burden every time we need an update?

Instead of asking permission like ~scio, I decided to go ahead and put it on gdocs (sorry if that's rude, I'm just too practical, and in my defense I asked already and you didn't give a flat-out no). It's open for comments (and will remain so unless we start getting problem commenters), so feel free to point out typographical errors, formatting problems, corrections based on discussions we've resolved, and the like.

Well actually the goal was for anyone to download it and then upload a download link once they'd edited it, but if you guys prefer Google Docs we can switch to that.

EDIT: Btw don't worry it's not rude.

Yay

Yeah, that could've worked, but I was intimidated by the idea of "taking over" the GDD just for the small typographical changes I felt like making before, and I'm guessing other people were too, sicne as co-lead, you'd probably have much more authority in making changes to the GDD. But, now that it's on google docs, my misconceptions are now moot.

With that done, Nick, ~scio, who wants to assume ownership of the doc? Anyone want editing permissions?

Thanks for putting that up. Nick and I should both get editing permissions.

Exactly as I thought -- I just don't want to be forced to guess what your emails are. PM?

Concerning the Radar and Health Bars.
the radar actually sounds epic but you may have noticed on the GUI thread I opted for the simple design for now.
Question for the radar to ~scio: So would the distances on the radar max out at healthy levels, or would it show if you had surplus?

Question about the Health Bar: I see what we're trying to get at, but if we want to make a practical, I have a feeling we need to just factor in the key essentials and some minor repercussions. (going for realism here would be almost impossible) Like scio said, having 0 of something may not be detrimental to the cell but may mess up the equation for the health bar.
Since the cell has soo many processes and is using many different compounds in different ways, wouldn't it be best to break it down to a few key processes and then analyze a few other compounds that could trigger chain reactions that affect the cells health. We all know ATP, Water, Oxygen and the key essentials, so we can easily factor those in. But also, there are things like autophagocytosis that can come into play. If your ATP drops to a certain level, your body will start eating its own mitochondria (which it isnt using) to generate more ATP. So once your ATP reaches a certain level, your mitochondria start dissapearing, which affects health. So low ATP has other reprocussions.
So could we make a list of key compounds and then a list of notable repercussions? (moopli suggested some:

moopli wrote:

for example, a poorly-functioning nucleus won't be replicating DNA, and will do slower transcription, and a resource-starved cytoskeleton won't be holding the cell's shape all too well and won't be moving things around inside (or moving flagella and cilia) much.

Then we could make 1 or 2 equations that factor into the health bar. (Maybe all combined into one, or 2 equations that add up to the whole health bar, one accounting for the compounds the others for organelle functionality) As far as warning the player, I think it will only serve as a good general warning, and maybe if you hold your mouse over the bar it will tell you which parts are the issues?
Thoughts?

I agree that keeping the healthbar simple is a good idea, and I'll give some thought to exactly what the healthbar is going to measure so that we can implement it well. For the radar chart, I was thinking it would show maximum free levels of compounds ("free levels" meaning that if something gets moved to storage, it's not shown.

I commented this in the gdocs GDD but I think it might be better to discuss it here.

Regarding how reproductase is produced by maintaining a threshold of atp:
- Having to stockpile ATP would limit microbe design and the gameplay by a fair amount which I don't think is a good thing. Something like a low vacuole count microbe might not be viable (even with scaling of the required amount of atp) and the player is pushed towards working on an excess of ATP instead of working towards goals like unlocking organelles, where they might forget their ATP and create some excitement.
- This can be changed, but currently the microbe is smart enough to throw away its ATP in favor of glucose as it is a smarter way of storing energy, this wouldn't be smart with a requirement for stockpiled ATP.

I rather like the currently implemented solution where reproductase is produced like any other compound with a variety of compounds as the input. This input could even be determined by what the microbe is constructed of.