0.4.1 Features Discussion Thread

Yeah ok, sounds cool to keep milestones as milestones and use labels elsewhere.

Re saving I wonder what you, or anyone else, are imagining. I’m thinking that when you save you keep what your cell is like (which organelles it has in which positions) and you keep info about which species are in which patches and what populations they have, and the map of course.

However if you’re swimming around in an ammonia cloud with some compounds stored and have 3 bacteria to your left and then press save and then load that would be somewhat equivalent to pressing the suicide button. You’d be in the same patch with the same cell but the info about that ammonia cloud and bacteria would be lost and you’d just have the basic allowance of glucose and ATP.

I don’t know if that’s easier but I think very few roguelikes (which Thrive kind of is) let you keep progress mid run, you often go back to the pre-run area (which for us is the editor I guess). Seeing as swims are only a couple of minutes then losing half progress on one doesn’t matter I don’t think.

That won’t translate to the later stages where you can’t simply respawn after loading a save (strategy mode). So I would want saves to work like saves in microbe stage as well, they would save everything so it would be like you had paused and then unpaused the game.

1 Like

I can see the value in making a robust, general, solution once rather than having to write different things for different stages.

I for one am completely convinced by @tjwhale‘s suggestions for 4.1. The patch seperation will be the most time consuming of the three additions of course, but all of them add a lot of depth to the gameplay without being too difficult to implement (this is an assumption by myself, a non-programmer).
Also I think it‘s important to have the player, the one hex species, be the only species at the beginning of the game. As I remember a species already splits if it gets too numerous. This is exactly what will then happen to the player species and so life will diversify. This has three advantages over all cells already being somewhat developed at the beginning of the game:

  1. It would be very difficult to compete with larger, more specialized cells for the one-hex-player-species.
  2. It paints a more complete picture of the history of life on your planet.
  3. Mutations in NPC species will be more noticable than they are right now. If a cell already has three chloroplast and ten other organelles the player won‘t notice a fourth chloroplast. If at the beginning there are only one-hex-cells and a NPC species evolves chloroplasmids, the player will notice.

tl;dr: I‘m all for it, just remember to make the player species be the only one at the beginning!

1 Like

I agree with these points. I also think it means we can make larger, more complex cells, more dangerous as the player won’t run into them until late microbe stage. I also think having only a single hex and clouds at the beginning will be a partial tutorial, it will be a gentle introduction. I also really like the idea of your whole planet being filled with complex life and being able to remember back to when there was only the single hex of cytoplasm that started it all, I think that is so cool.

2 Likes

That only applies to NPC species. So the handling of the player species needs to be redone.

1 Like

A couple of thoughts about having a patch map. I think it can be split into several connected features.

  • So first there’s having a map where each patch has different species in and they split and migrate between patches.

  • Then there’s having a procedural map generator so when the game starts it can make a new map for you to be in, this depends on the depth of the ocean, amount of land, things like that.

  • On top of this there’s auto-evo where the environmental conditions of each patch determine how the cells in that patch evolve, which is going to be a bit tricky to get right, though I don’t think so bad.

  • There’s also the climate model, so the properties of patches changing over time and ocean circulation moving debris between patches, patches freezing over as the planet temperature changes.

  • Finally there’s the solar system model which determines how much light hits the planet, what spectrum that light is, what the base temperature the planet is and feeds into the procedural generator where metalliticity affects how much water there is on the planet.

So I think that’s actually quite a big list. I think if we want to go down this road we should start with just the first point and add the rest later, step by step. I definitely think it’s a good idea to have a lot of stuff from this list and hopefully all of it but if we can break it down and do it step by step I think that will help.

Ok I’ve made some decisions about this. Feel free to keep suggesting ideas but they won’t make it in until 0.4.2. Here are the ones we’ll save for later, lots of good ideas here:

  • Switching guis. Naro’s concepts are awesome and if there is any chance the gui rendering engine needs to be changed I think we should do that first before committing to a big gui rebuild.

  • Light and darkness: I think there’s 3 great features here, eyespots, biolumiescence and light spots in sunlight patches. I think it makes sense to do this later when we have the biomes already separated and we can have some be dark and others light.

  • Saving: I think it’s up to @hhyyrylainen to decide when this should be tackled as it’s a deep engine issue, feel free to put it in this patch or leave it for later. We can continue to live without it, we could offer little things like maybe a freebuild button in the main menu where you can choose any patch and have unlimited MP in an editor session before starting to play properly. This would mean you could jump to any part of the stage. However clearly we need Saving at some point so maybe now is a good time.

  • Options Menu: I think this matters less than Saving. It would be nice to have a discussion of options that would be in the options menu to know how much they would make things better.

  • More multiplayer: What hh has done is awesome and doing more is a huge amount of work. Multiplayer is a great thing and it’s awesomeness to effort ratio is actually quite low I think.

  • Fluid drag based on shape: I am not sure about this as I’m not sure we want every cell to end up cigar shaped, I guess this is realistic but might make the game too uniform, crazy shapes are quite cool I think, not sure, open to discussion. I think the fluid drag based on size we have now might be better.

  • Environmental changes over time: this is a great and important feature and I think we need to sort out the patch map first before getting into it.

  • Clade diagrams: this is a relatively straightforward bolt on once the patches are seperated

  • Other features: Visual improvements, cilia, viruses, appearance tab, environmental oxygen and co2 levels (I think we should leave this until we have a basic patch map working before linking it to the processes), organelle upgrades, process panel, fluid dynamics, toggle clouds on and off (I’m not sure about this), having contextual organelle unlocking (like absorb a photosynthetic bacteria to get chloroplasts) this is cool and best saved I think, multi-nucleus cell (sounds cool as a late microbe stage feature)

Here are ones we’ll put in 0.4.1, I think it’s a decent chunk of work but not ridiculous:

  • Interactable iron rocks for iron respirators to use. One problem this helps with is getting life to spread out through the ocean more easily which is nice to have. We need to discuss the precise details a bit.

  • Overhaul cell death mechanics + first step towards osmoregulation as discussed here

  • Basic pilus, as a community favourite, with cell walls giving you extra defences to it. We may need to start on an appearance tab for selecting your cell wall, not sure.

  • Pause game when entering menu, not sure if this is already done.

  • Start as a single hex of cytoplasm, add a prokaryote version of the chemoplast (otherwise life will not last long!) and lock the membrane bound organelles until you have a nucleus. I hope we can avoid making copies of every organelle for prokaryotes, I’d like to not have too many duplicates though having some is cool.

  • Add patch map with species spreading. I think there’s two pieces here, I think we should make 1 map and build all the mechanics required for that (different species stored in a binary tree and different conditions per patch based on location, splitting and moving species between patches etc) and then after this, if there is time, build the procedural generator to make many maps. The generator is something we should 100% do but it may have to wait until next patch depending on how long this all takes.

  • Get the particleFX plugin working if we can and experiment with adding particles to the game.

Work on moving towards a more solid game by:

  • Modulating game difficulty: including making some biomes harder than others, decreasing compound availability over time, more aggressive predators and more frightened prey when appropriate. The hardest patches should have scarce resources and aggressive predators, though also there should be easier, more relaxed areas too.

  • Tackle organelle gluttony and over-viability of basic builds: make sure that having too many organelles is clearly bad and also make sure having too few becomes unworkable over time. I think reducing compound clouds over time (esp. glucose) will help and separating biomes will help reduce energy sources. Also chloroplasts may need a nerf to maybe slow you down, maybe switch to drag per hex rather than drag per organelle? Also more balancing of energy production so having a large cell is very costly.

  • Slight movement rebalance to make flagella more impactful though it seems we’re in a pretty good place with this already.

  • Rebalance time to reproduce: change phosphate and ammonia availability, balancing Nitrogen Fixing Plastid, add reproduction progress bar while swimming.

I’ll make a topic discussing the situation soon. I don’t think it can be resolved in the next 5 months or so. After 0.4.0.1 I think we can gauge how common GUI problems are in long playing sessions.

I’ve got quite a lot of school work coming up soon, so I don’t have much time for thrive before early summer. And I’ve got some higher priority engine issues to sort out before getting to saving. I’ll keep it in 0.4.1 milestone but mark it as non-gating.

I listed the things I think an options menu should have at the least: Create options menu · Issue #509 · Revolutionary-Games/Thrive · GitHub

I can make github issues for these if you want.

1 Like

I opened issues on github. Many of the issues don’t have enough details yet so more discussion and a lot of test builds with different numbers are needed.

Here are the issues:



















I also opened this issue:

2 Likes

This release ended up being quite a bit cutdown the release on Github now lists all the changes that made it to this release: https://github.com/Revolutionary-Games/Thrive/releases/tag/v0.4.1