Hi all, I’m Andross a new member of the team. I’m a grad student working on my M.S. in Computational Physics at the moment. Writing my thesis takes up a lot of my time but I figure I could use the time I would normally be playing video games to instead work on one that is as interesting as Thrive. Naturally I’ve got a pretty strong math/science/computer background and I’m looking forward to helping in whatever way I can.
3 Likes
Welcome Andross good to have you on board!
You can peruse the wiki to see concepts and/or github to see current tasks. Feel free to start any discussions if you have ideas for how to implement a new feature or improve an existing one (Fluid dynamics is something we want to eventually add for example).
1 Like
What sort of fluid dynamics are we talking about? In the microbial stage that would basically just be currents that give velocity to clouds, the player, and NPCs.
Exactly. Some sort of system that moves them all around and changes directions over time (and can probably be pretty random really). I think we have it currently for the compound clouds but it doesn’t affect the player or NPCs.
Hey Andross,
So myself, along with Seregon, are the theory team co-leads for the project. What the theory team does is basically programmer support, so if there’s a feature we want in the game and we need some scientific or technical structure underlying it then we’re here to provide support and prototypes for how things could work. My suggestion, if it suits you, is that you could be on both teams and be a programmer as well as helping with some of the scientific stuff, as you have a strong background. Teams are a pretty flexible thing and it’s not terribly formal.
So in general how things sort of work is that Seregon or I might make a prototype for a feature and then one of the programmers will use that as a jumping off point for building something. One of the challenges is balancing fun with realism. We want to prioritize fun and have Thrive be a great game, while keeping it as scientifically realistic as possible, so it’s an interesting challenge.
Here’s a few things that might interest you, feel free to work on what you’d like, we’re not very hierarchical. I’ve sent quite a lot of stuff just to give you an overview but please don’t feel you need to interact with it all or anything, I just thought I’d send a few things in case any of them caught your fancy.
Firstly I’d be interested in you opinion on this formula for balancing microbe speeds (max speed in the top post), do you think it makes sense?
Secondly here’s a prototype I made of some work by Michał Joachimczak. The idea is that in the microbe stage you move with flagella and in the multicellular you start to move by contracting your shape. I think this framework gives a way of doing that smoothly, ie you can start with a few cells tied together still using mostly flagella power and then slowly add more until you are using mostly body contraction. (Interestingly humans still have flagella powered cells, the sperm, also there are cillia (another microbe locomotion method) in the lungs for moving phlegm around).
Here is what it should look like
Here is where mine is at
There are some physics issues I got stuck on (the cells inside the microbe are meant to maintain their pressure for example) and, at some point, I’d like some help to carry on with the prototype and get it really good. So if you’re interested in that I’d be happy to work on it. We’re not thinking about multicellular transition quite yet but by the time we are ready to build it having a really good prototype would be very helpful.
Re fluid dynamics the parameters are that we want a fluid system for the microbe stage which moves the microbes, bacteria (which aren’t added yet) and compound clouds around. However it needs to be soft enough so as not to interfere with gameplay too much. Also I don’t know how much experience you have with super low Reynolds number fluids but they bamboozled me quite a lot when I first started. Basically the microbes are sort of swimming in treacle because the length scales and velocities are microscopic compared with the viscosity of water.
However players kind of expect turbulence and vorticity so it’s a bit of a balance between what feels right and what is realistic. For example for a real microbe acceleration is basically instant, it’s more like a rowing boat going across a sand pit than a river, microbes can’t glide.
Here’s the thread where the current implementation is discussed, it’s pretty long but it does have nice pictures.
Anyway that’s quite a lot of stuff. I hope it’s interesting rather than overwhelming! If you’d just like to work on something super simple that’s fine. Let me know if there’s anything I can do to help you settle in. I’m happy to answer any questions you might have about the theoretical aspects of the game.
1 Like
As far as the max speed is concerned I think that what you proposed seems like a good compromise between realism, fun, and simplicity. The only non-realistic thing would be that there is a natural diminishing return when it comes to continually adding the cell while keeping that ratio “x” the same. There would be some damping effects due to increased drag but those would be really minor (assuming a similar shape for each cell just being scaled up or down) unless your cell eventually becomes very large. The “correct” maximum velocity would be found as follows:
Typically drag through a fluid would go as
F_drag=C * v^2 * A
where v is the velocity and A is the surface area whose normal vector would be parallel to v. Since we are in a 2D environment we could replace A with some sort of arc length. And C is the drag coefficient which depends on the Reynolds number and the object’s geometry, I also tied the density of the fluid into this parameter (we could simplify this by ignoring geometry and simply having it be a set value for each biome). Then we would simply solve Newton’s 2nd law with the forces being
(force_of_flagella * number_of_flagella - F_drag) / mass = acceleration
this would be a non-linear first order differential equation because F_drag has v^2 and we would obtain from it v(t) which would have some maximum value because at some v, F_drag would cause acceleration to be 0.
However, this is a game and should be simple enough for everyone to understand the basics of how it is working. I think the best bet would be to have your variable x not simply be the ratio of flagella to total organelles but to give each organelle a weight. Cytoplasm should weigh less than the nucleus for instance. So that it is instead something like
x = num_flagella / (num_vacuole * mass_vacuole + …)
If we want to have something that will prevent players from making insanely large cells with a single flagella and abusing the “no less than half global max” mechanic we can instead have that 0.5 value be a function of the total size of the cell. For instance instead of the function being
max_speed_for_the_cell = global_top_speed*(0.5* sigmoid(15*(x - 0.33)) + 0.5)
We would introduce a variable y that scales as the total size (number of hexes) of the cell increases. For example
y = 1/(1+(size-15))
15 is the size of the starter cell
max_speed_for_the_cell = global_top_speed*((1-y)* sigmoid(15*(x - 0.33)) + y)
Here’s a plot where y is just the size ranging from 15 to 100
It really only impacts the small x regime, if we wanted to make it more impactful we could decrease the numerator but that might be punishing the low x cells too much.
Thoughts?
1 Like
Nice reply, thanks 
On your first point I think this is part of the bamboozling nature of low Reynolds number fluids. I got surprised by it when I first started reading about it. So the v^2 term in the drag is just a v when Re is low enough. here’s a wikipedia page about it.
Drag (physics) - Wikipedia’_drag
One way to think about it is that the (u dot del) u term in the Navier-Stokes works something like u^2 (though that is very non-precise) so when u is small enough it doesn’t really do anything and you get the Stokes equation instead. Here is a page about it.
Moreover it actually doesn’t really make a difference. So if, for simplicity, you assume mass = 1 and solve
(1) dv/dt = f - v^2
where f is the total force of the flagella and v^2 is the drag you get a solution like v(t) = sqrt(f) tanh(sqrt(f)*t)
and tanh assymptotes to 1 pretty quickly so the terminal velocity will mostly be C*sqrt(f). And in the low Re fluid the time it takes to accelerate or decelerate is very close to 0, because the velocity is so small. Imagine the rowing boat on a sandpit, when you are pulling the oar the boat moves at it’s top speed and as soon as you stop pulling the oar is stops really fast.
Whereas if you take
(2) dv/dt = f - v
in the linear case you get v(t) = ce^(-t) + f, which quickly assymptotes to f. And because the forces are small sqrt(f) will be close to f and so the result is much the same.
It’s a pretty counter intuitive situation! I get pretty confused by it. It is interesting though I think. Of course it’s all a bit academic as mostly the player will press W and move some speed and that’s all they’ll know!
On your second point Nick brought up the question of whether different organelles should weigh different amounts. I think it depends on the ratio of the masses. So if a nucleus weighs 1.1x as much as a cytoplasm then I think it’s not really worth worrying about it and just having them all weigh the same, but if a nucleus weighs 10x a cytoplasm then it will be very noticeable, so it’s worth deciding to either make it pronounced or not have it at all, I don’t really mind. As you say that is a good formula for x taking into account mass.
On your third point I think that y = 1/(1 + (size - 15)) is a nice idea, I like the principle that a large cell without proper propulsion should be slow. However I think you have a singularity at size = 14 which makes the denominator 0 and I’m not sure that’s what you want. I think a couple of tweaks to the formula and it could work really nicely!
I was able to fix your link (the parentheses were probably causing the issues) by putting it inside actual html <a> tags, which is something that discourse allows (a safe subset of html), which is a very nice feature.
Also, and maybe this is kind of an ironic thing to say after such a deep discussion.
I was wondering about direction of flagellum. So if we use this complicated formula to work out the top speed how fast do you move sideways or backwards and does it matter which direction your flagella face? And it all becomes a bit more complicated.
So I had the thought that maybe we could just give every cell a free, invisible, flagella that points backwards. That way we could use the simple stokes model (each flagella produces a force and the cell is resisted by a linear drag which increases a little with each additional organelle) and every cell would be able to move at least a bit. And also then you could have flagella pointing any way you like, you could put them all on the front and use d to go backwards really fast, it would work fine.
Don’t know if it’s mad but it might just be easier and I do like it when things are easy
About
The singularity at size=14 is only an issue if you’re able to take elements away from the starting cell. However, we could easily use some other function so long as the values stay between 0 and 1 and limit as size->infinity = 0
While playing I was actually wondering if flagellum direction implemented speeds in different directions or angular acceleration. Once we have the framework for speed in the forward (lets say +x) direction under the assumption that all flagellum are on the back we could then extend this to velocity in two dimensions. A basic idea for moving up down left right would be to run something like the following whenever a new organelle is added to the call to calculate velocities in the w, a, s, and d directions. In this function the variable x would be 1/weight.
w_vel=0
s_vel=0
a_vel=0
d_vel=0
for each flagella:
- mag_vel = global_top_speed*((1-y)* sigmoid(15*(x - 0.33)) + y)
- vert_position = center_of_mass_y-flagella_position_y
- horz_position = center_of_mass_x-flagella_position_x
- vert_comp = mag_vel*vert_position/(horz_position^2+vert_position^2)
- horz_comp = mag_vel*horz_position/(horz_position^2+vert_position^2)
- if y_comp > 0:
w_vel += vert_comp - else:
s_vel -= vert_comp - if x_comp > 0:
d_vel += horx_comp - else:
a_vel -= horz_comp
This would mean that if your only flagella is on the back then you can only move in the “w” direction. However, it would also mean that more flagella doesn’t necessarily mean faster movement. If you had one on the top, bottom, left, and right then your cell would move at the same speed in any direction but that speed isn’t very high. If you put multiple flagellum on one side then you can move more quickly in a particular direction. I haven’t taken turning into account at all and we would need to think about angular velocity (how quickly the cell turns to follow the mouse)
Let’s move this convo somewhere else so when we get to implement it we can find it easily 
If you run thrive 3.4 you will see that flagellum direction does matter to move left you need flagella on the right etc. to move forward you need flagella on back etc.
Also, I probably missed most of the convo. So if that was already known I’m sorry.
1 Like