0.4.1 Features Discussion Thread

#11

Well, I think we should at least add a nucleus. But otherwise I’m for early game reductionism to stop the player getting overwhelmed by a load of organelles when they first enter the game.

Good idea. It can be the start of balance tuning.

This is a nice one. More variety is always good. Maybe we could have their spawn increase over time so players get used to dealing with cells first and then, once comfortable with that, are confronted with new objects in the environment. They also open the door for new organelles like lamellipodia which allow surface attachment and crawling.

I had a glance back through the GDD and found a few things small enough to implement in the near future.

  1. Foreground texturing. Like the background, a few translucent layers above the layer of microbes and compounds.

  2. More active differences between biomes. Right now the only difference is the background, but I assume it’s not too difficult to change individual compound spawn rates for each biome. This should make the game more tactical as players can choose to stick with a biome or change to a new one, even if this switching system is overhauled by a patch-based system in future.

  3. Persistant light spots. Chloroplasts in these light spots would work more quickly. Could also be tied to the above as they’d be more common in lighter biomes.

  4. Bioluminescent organelles. We already have the editor icon for them, and while they don’t serve a gameplay purpose yet, it would be a cool visual addition to cells.

  5. Bump up the role of cell inertia and change how fast cells can move with and without flagella. At the moment there’s little advantage to adding flagella as the speed difference isn’t considerable. I would like to see it so that flagella-less cells are more or less stationary, at least at some point. Until currents are added this wouldn’t be fun at all, so for now cells should still move at some rate without flagella, but only with flagella will they actually be able to turn and move effectively.

  6. More readability of reproduction and health. There’s very little going on to tell me how close I am to entering the editor unless I watch all my organelles closely.

There are two major things I want to see at some point soon, though I recognise they’re difficult to include for 0.4.1.

  1. Currents carrying cells and detritus around. Wiring the fluid simulation controlling compound clouds into momentum of cells would in my opinion add a lot to the realism and game feel.

  2. A revamped health system involving osmoregulation. More info here: http://thrivegame.wikidot.com/microbe-stage-gdd#toc8

#12

This can be started only once the biome selection for the player is done. But if that is planned for 0.4.1 then this is really easy to make.

Also it seems that there is a lot of support for the pilus on the community forums as well.

#13

These are some wonderful ideas so far. Something I would like to add is not only do we need to make 0.4.1 feel like a fun game, we need to make it feel like a polished game. Currently, even in 0.4 there is not really a balance in Thrive, more = better right now. Some builds are clearly superior over others, while roleplaying as a passive plant cell or speedy sonic cell is possible now, there are no reasons to do so other than roleplaying. Eventually the dominant cell will be some giant pancake with two of every organelle going around murdering everything, this occurs even in bacteria.

Different biomes will indeed help with the situation, but I think in 0.4.1 we can add some basic limiting factors such as wider cells moving slower than thin cells, or organelles having negative effects, such as chloroplasts decreasing the overall speed of your cell. Or maybe even make some organelles incompatible with each other.

Also something else I would like to see is a basic options menu, so the players can actually change their resolution or volume in game.

#14

That is already in the 0.4.1 milestone on github: https://github.com/Revolutionary-Games/Thrive/milestone/10

If there are any issues there that shouldn’t be worked on for 0.4.1 those should also be discussed.

#15

My suggestion with the github milestone is that we should remove everything and the only add back things we actively want. I think it’s become a bit of a dumping ground and it would be nice to start with a clean slate as it would be nice to do a relatively small patch I think.

@1n48yg I agree about balancing between different cells and their viability and organelle gluttony. I think having compounds less abundant will help, making the player fight to survive requires quite a lot of scarcity. Also I wonder if having bacteria flee the player a bit more would help as they are a free lunch right now. I agree more broadly this is a big issue we need to work on. I think it’s hard to fix properly until we seperate the biomes, being able to use chemoplasts and chloroplasts simultaniously won’t be possible then, now it’s super OP.

@Oliveriver I like a lot of your numbered ideas, they are cool. I agree that flagella feel a bit underpowered. When you say “Well, I think we should at least add a nucleus” what do you mean? We’ve been talking about having the player start as a single hex of cytoplasm as the only life form on the planet and then having the adding of the nucleus be a major gameplay moment you have to work towards. I think that’s a pretty strong idea.

I really like light spots and bioluminscence, though I’ve been thinking that might be worth doing after we have the patches separated as piling them on top of everything else might be a bit confusing.

#16

Most of the github issues are small (or larger) technical problems. Right now I think only a few things like pilus, cilia, saving, appearance tab, environmental oxygen levels, fleshing out bacteria, organelle upgrades, process panel, freebuild editor, fluid dynamics (and maybe options menu) are the only non-technical issues there.

Okay there are quite a few gameplay issues as well. Should some of those be pushed back to (what I assume will be) 0.4.2?

I found this issue that might warrant rediscussion: https://github.com/Revolutionary-Games/Thrive/issues/192

#17

With gameplay features it’s definitely easier to think of stuff to do faster than it’s possible to do it. This means a master todo list will grow over time rather than shrink.

I imagine it’s the same with technical issues, it’s easy to find things that are fixable but hard to actually fix them. All the talks I have heard about shipped games include pained statements about all the bugs they wished they had time to fix.

My suggestion for both issues is to keep a background list of all the things it would be good to do in an ideal world and then each patch just pull a few things from that list and focus on those. I think that helps keep the work focussed and not overwhelming. Also we can focus on the things with the best effort to return ratio.

So I’d suggest putting all those issues in a general pool and then pulling out some technical issues you think would be good to focus on, maybe 4-6 of them, to put in 0.4.1 and then we can save the rest for later. Next patch we can pull out some more and do those. Same with the gameplay features, lets move all of them out and then put back in the ones we want.

#18

I guess it might make the release milestone seem more plausible if most of the technical issues weren’t assigned a milestone. I just feel like that could make it so that for example adding the executable icon back (which a few players have complained about) would take me 10 minutes to do (+ the time it takes me to switch over from Linux to Windows and then back). So I’m trying to get more visibility for the small technical things.

But if you think it would make it easier to track when we can release 0.4.1 if only just a few select technical issues were there and all the rest were in the backlog (without a milestone assigned). I can do that.

One thing to decide before that is: do we want an options menu in 0.4.1 (a lot of issues are related to that) and do we want saving (a bunch of issues are also dependent on that)?
Once those are decided I can move a lot of issues to the backlog. I’ll keep a few technical things I think should get focus.

Edit: one more thing to consider: if we don’t implement saving would: https://github.com/Revolutionary-Games/Thrive/issues/289 be an alternative to let people at least save their creations (that would be much easier to make).

#19

Is it worth having a “small technical things” folder or milestone or something? That might help keep them organised. I would prefer if the 0.4.1 milestone could be relatively small and focused.

Re saving or options I guess seeing as they are deep engine things I suggest it’s up to you when you want to do them. I don’t mind if neither make it into 0.4.1, I think we can still live without them, but if you’re keen to tackle one then go for it. I don’t know what options we could offer specifically, things like fullscreen vs windowed are nice but don’t add that much I don’t think.

I’m not sure if it’s worth making a half way house saving feature. If we do that and then do real saving that’s like 1.3x as much effort as just doing nothing until real saving. However I don’t mind too much.

#20

I feel like that would sort of not be what milestones (ie. issues for tracking release completion) are about. It’s easy enough to be able to view the issues without a milestone. The labels are another way to organise the issues, so there could be a label for issues that aren’t part of a milestone but have higher priority than other issues without a milestone.

I would rate having creature saving and loading in the editor to be way less work as that can just be implemented with a few methods inside the editor for making the organelle placement into a string and loading it from such a string. Whereas proper saving needs to save every aspect of all the cells and compound clouds to work properly (that’s why it is so much work).

#21

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.

#22

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.

#23

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

#24

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!

#25

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.

#26

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

#27

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.

#28

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.

The GUI library situation
#29

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: https://github.com/Revolutionary-Games/Thrive/issues/509

I can make github issues for these if you want.

#30

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: