For. 3 I’d really like to make the backgrounds dynamic instead of using image textures which don’t seem to work well on bsf. Hopefully I will be able to implement things myself once I understand coding better. For the future im definitely planning an algorithm that allows accurate and pleasant underwater lighting. Another great upgrade would be mball membranes, better health system, fluid toxins and some new organelles.
In addition to Future Release Plans thread there are the issues on github that could be used as a list to pick stuff from: https://github.com/Revolutionary-Games/Thrive/issues
Also some fan favorites we could prioritize:
- options menu (with fullscreen option)
Those are probably the most requested things I see. There’s also mac support, but that’s not really something that could be planned.
Here are the things I have planned to work on that are thrive related, they’ll be done when they get done. In the (approximate) order I plan to do them:
- write a git LFS api to ThriveDevCenter and move Leviathan and Thrive assets to use it. It would easily allow any team member to create git commits that have changes to the assets. This would also allow different branches.
- Move the engine to use variable rate ticks and not use interpolation with local games to help with the lag that Oliveriver feels when playing
- Add physics constraints to the engine and then do the pilus as an example of that
- Investigate if we can use the bsf forward rendering mode (and add a way to toggle it, maybe in the launcher + a dialog popup telling people that intel is bad) to fix crashes for intel people
- Create a sound source component and replace the microbe one off playing sounds with the sound components, which hopefully will make the audio nicely 3D spatialized.
- Try to track down any crashes that get reported
- Maybe get started on binding agent stuff to also test out the physics system (basically a button which you can press when you have the binding agent organelle to just become attached to any cell of your species that you touch)
Here are then some things I dream about doing once the git lfs stuff is done:
- make a new type of dev build option, I’ll probably name it
dehydratedwhich doesn’t include any git lfs contained files in the zip. Instead just a list of file identifiers and paths + a script that would download the files.
- With the majorly reduced disk space requirements I’d then configure CircleCI and Appveyor to make dev builds that are uploaded to ThriveDevCenter. This would make dev builds automatically for every commit and pull request.
- Add a way to link the launcher to a ThriveDevCenter account, and allow playing dev builds with the launcher. Allowing login to ThriveDevCenter with a community forum account that was in a specific group, like supporter or something for patrons, would then allow those people to use the launcher to play the dev builds.
- Add some controls to ThriveDevCenter to promote certain builds to be “build of the day” to make it be sent to the people who have linked their launchers.
So basically I’ll be busy with a bunch of stuff even without attempting to do much gameplay stuff
And finally I’ll suggest some issues that could be included in 0.4.3 (for other programmers to work on):
- The new GUI (of course)
- pilus (I’ll work on this)
That’s quite a few issues but many are pretty fast to do (if I did them). I also included some harder ones. These are mainly ones that don’t really affect gameplay, so I still haven’t really suggested other gameplay stuff than the pilus to be included.
Three things I think is important for the next release is:
Procedural patch maps
Saving and loading games
AI cell migration
Other then that, I think it would be good to think of ways to make each biome more interesting. Saying that I mean adding stuff like heat and light sources. Maybe more things floating around like rocks of various sizes and shapes (or whatever else we can think of)
That said, the biomes are already pretty different and awesome, I just want to add as much as possible to them before moving our focus onto something else
I agree with all of you, good points have made.
I was thinking that we didn’t introduce yet appearance or behaviour tab, I would personally like a lot image behaviour in particular because with new patch system changing patch could mean changing behaviour try to adapting new conditions.
I plan to:
- Keep working on GUI main part was already start, need to be test, patch and report need high work too and editor need to be finished too.
- Help solve as many issues as I can.
Here are the major bits i want:
-AI call migration
-iterate upon the new auto-evo to at least reduce or eliminate non-viable cells.
-Choosing membrane type in editor?
Now that we have patches it’s a good time to make them more unique, so it’s a good idea to make certain compounds toxic, like hydrogen sulfide. We could start simple by making them harm you and add more effects later.
We already had a thread about this topic, i think it’s a good issue to start working on.
Another option is an idea that was originally Nick’s to have some sort of bar which shows how much ATP you produce, how much you use when still and how much you use when moving. We could put this in the editor and then lock you from leaving if you can’t produce enough ATP to live when still (as you will just die). I think this might help people not put the nucleus on too early in error and hopefully wouldn’t be so hard to make as one of those numbers is already there.
Re pilus what sort of background tech do we need for the different types? So a pilus which just stabs is the basic kind, would a straw, injector (like a needle) or sex pilus use the same collision stuff? What about a harpoon where either you fire it like an arrow or one where you fire it and it’s attached by a line to your cell, would those need different code?
The basic pilus needs two new engine things: a cone shape collision shape (or maybe a convex collision shape) and a rigid physics constraint that is created once between the cell and the pilus. Then basically using the existing like physics callbacks it would just deal some damage to the hit cell.
Any of the extra stuff like: it getting stuck to the hit cell, it being detachable and a physics rope being attached to it, are all extra work, and need further engine features than the basic one, and much different code in Thrive to handle them.
Also I think that if we select some of the auto-evo improvements we should go all out and have all of these:
- cells migrate to new patches
- species split under certain conditions
- the player is forced back to a patch their species is in if they die in a patch where their population is 0 or less
- there is a cap on the number of species or cells that can spawn at once to reduce the major lag spikes
- looking into there maybe being a bug where non-bacteria use the bacterial colony spawn code
- species should adapt to the patch they are in and be able to select beneficial mutations (this almost needs a fully featured auto-evo algorithm to work well)
One thought I had is that we can do the species moving/spreading, splitting, being capped in each patch etc without having to build the whole of auto-evo. We could just assume that if we had a working auto-evo (which is just random for now) then under what conditions should species move and split etc.
I wonder if that might make it easier to just tackle half the problem at one time.
However the patch map will never be great until it has all of auto-evo working so it might be nice to try the whole thing but I think we are quite far from working it out.
As you say the problem has really two different parts, which can be done basically independently. I wouldn’t really say that that makes it that much easier, unless someone was trying to solve both parts simultaneously in their head, and didn’t realize it could be split into separate parts. As it looks like it’s going to take a bit longer until the auto-evo algorithm by Nick is done, that part could be marked as non-gating.
Yes i would like to get back species splitting as soon as possible.
And the species cap (Or a light cap that would make it far more likely one or more species go extinct after a certain amount of species exist in a patch and so would add some darwinness)
And the cell cap
One question: how hard would it be to get set up so the tooltips (and basically everything else in the gui) autoupdates by reading the game files rather than being hardcoded?
When balancing it was reasonable to make sure I edited the tooltips as well as the underlying values however I think it’s good practice in general not to have hardcoded stuff in the gui and have one place for each value which is authoritative.
If it’s a relatively easy (if slightly boring task) which might work well for a new programmer then that’s one thing, if it’s a big hassle it’s probably not worth it.
I think that a requirement would be to first do:
After that it wouldn’t be too difficult to have the logic in the UI for calculating how effective the organelles would be with the current patch’s properties. Though some care would need to be taken to not duplicate the logic. Something like providing C++ native function callbacks for the GUI to query stuff from the process system (in order to not have to implement the process system almost a second time in the GUI).
It would be super nice to have this. I think this is a task that doesn’t need me to do it (other than give some advice on how to do it properly), so it could be worked on by some other programmer.
I’ll make two lists, a list of everything that I think would be the most important to try to implement soon, and a list of features that I can personally try to contribute towards. The list of future features is not in any particular order.
It’s a long list, and I’m not saying we need to implement EVERYTHING on it; I’m just putting it here so we have a place to refer to.
Important Future Features
1. New UI. It looks great and the sooner we can implement it the better!
2. Fluid mechanics and currents. Having fluids that move the cell and things in the environment around will both add to the sense of immersion as well as make sessile organisms more viable.
3. Dynamic backgrounds. Getting rid of the static background images with the static bubbles. Adding dynamic bubbles instead, with blur and visual signs of water movement. Also cells that move in the background. I think this will hugely improve the game’s visuals and immersion!
4. Species migrations. The ability for species to migrate between patches will be huge in making the world a living breathing ecosystem separate from the player, and make him feel like a small piece within it. For example, if you evolve to become a prokaryote before entering a patch there’s a chance that prokaryotes will never reach that patch.
5. Improved tutorials and help menus. I think a small tutorial at the beginning can make the game more accessible for new players that we bring into the community. It doesn’t even have to be a finalized tutorial, just something placeholder so the game is easier to get into. It would also be cool to replace the help menu with a first version of the Thrivepedia!
6. Reduce compound yield from engulfing organelles/cells to 25%. Then add lysosomes as a new organelle, and they increase the compound yield you get from engulfing to 50%. It’s a little too easy to harvest compounds from engulfing organelles right now, and this would allow us to add the lysosomes organelle to the game.
7. New ambient SFX like bubble sounds, underwater echos, etc. The gameplay does sound a little quiet right now.
8. Fix species renaming. It would be a nice QoL feature.
9. Tooltips for cell stats in the editor (speed, generations, osmoregulation cost, etc.) At the moment I think a lot of players don’t initially know how to interpret these.
10. Dynamic tooltips. Make it so that tooltips automatically pull information from the data files of organelles or stats or whatever they are linked to, so that if the values of the organelle are changed so is the tooltip.
11. Reduce the speed of cells that are being engulfed.
12. Simple Auto-Evo algorithm. Using the auto-evo thread we can try to create a simple version of auto-evo for now?
13. Radial blur on the screen.
Features I Can Help With
- Auto-Evo. Depending on how far I manage to progress before the next update, I may or may not be able to create a simple Auto-Evo algorithm for the Microbe Stage based off of what I’m working on in the auto-evo thread. The good news is that the Microbe Stage version of auto-evo doesn’t need the entire algorithm (since features like intelligence, flying, terrestrial life, and more are irrelevant), but the bad news is the algorithm is a hefty project and may progress at a slow pace.
- Improved tutorials and help menus. I can help write the tutorial entries and entries for the Thrivepedia.
- Dynamic tooltips. After working on the new organelle tooltips I can give a shot to the dynamic tooltips, but it’d be a lower priority for me than the auto-evo algorithm which I think is the most important feature that would be good to finish sooner rather than later.
Re lysosomes if having just one hex in your cell buffs you a lot with low drawbacks (I guess it needs osmoregulation and will make you slower) then won’t it be the case that everyone would use it without thinking?
I think there’s changes we could fruitfully make to the AI to make them run away more such that it’s basically impossible to eat anything faster than you.
If you mean when a cell dies it drops too many compounds I think this is probably true, especially if you meet a flock. Though I also wonder if there is also stuff we can do with AI to help cells last longer, like stopping moving when they are out of ATP or seeking only energy compounds when they are low.
No because the lysosomes would have a moderately high osmoregulation cost, so it would only be “profitable” to evolve them if you are planning to engulf a lot.
Wouldn’t it be easier to try to make backgrounds look like they did before the bsf change? At least in the short term? It seems like changing the whole background system would be a big task.
This is something I’ve been thinking about, making predation more interesting. The way it should work is that once you engulf a cell it stays inside you untill you digest it, in turn slowing you, in this case lysosomes would make digestion take shorter.
I think bacteria can’t eat other cells and instead expell digestive enzymes to break down their food.
I think doing something similar could make some interesting mechanics and would make prokaryote gameplay more unique, we should talk about this in another thread if we end up implementing it in the game.
IRUY already made Some background sounds for different biomes and Twiggs has been working on new sound effects for the UI and the game in general, since we already have some work done this is a feature we should add in the next release imo.
Good luck with that. It may actually be easier to actually replace the background system than try to completely subvert the auto exposure settings, and risk having to tweak every other graphic in the game to continue working.
Edit: I’d like to add that the auto exposure min and max values are specified in Biomes.json and someone could experiment to see if capping the exposure at really low values would make the game look really dark (and the backgrounds similar to what they did before).
Ok I hope everyone has had a chance to contribute, seems like a good time to boil this down into a plan.
Gui. Lets move to the new design which looks awesome and get that change finished. Also re tutorials and player support I think the tooltips are really helpful there so I think it would make sense to do dynamic tooltips which recalculate what they say based on patch conditions and maybe warn the player if an organelle is useless. Lets put Nick’s energy bar in the editor too which shows how much energy you are producing vs how much you are using when still or moving, I think that will help a lot with cell design. That would get the gui into a really good place I think. The reproduction progress bar has been a big success so good job everyone there.
Let’s have a final discussion about species splitting and moving patches, resolve that and then implement it so we have AI species migration. We’re all largely on the same page I think we just need to boil down what we have into a set of mechanics we can implement. I think re auto-evo we should keep discussing it and try and make some prototypes for getting it working, I don’t think we’re ready now to implement this release.
Lets get the basic pilus in, lets teach the AI to use it and then balance that combat. I think it would be good to continue the agents discussion and if there is time finish that and implement the cloud based agents (though I doubt there is time for that). The X’s are a bit of a problem late game and so moving on from that would be great.
Several people have brought up that compounds are too abundant from dead cells late game. I think we should address that by working on the AI to teach it to stop moving when it’s low on ATP, get it to more actively seek out energy sources and get small cells to run away more effectively. Also we should change the spawn system so giant clouds of large Eukaryotes are rare (though they are great occasionally). I think Lysosomes could have a place in that so lets keep discussing them, we need a good design for them. We can also reduce the speed of cells being engulfed.
Lets work on the star and planet generation, get some gui for that made and then discuss what sort of disasters we want and how we want the planets to evolve over time. I’m hopeful I can do most of the implementation on that.
hh your list of small features looks nice to put in for when people are looking for something. Also your personal todo list looks cool, it would be great if you could put pilus relatively high up on it.
Re backgrounds I think it’s cool if we can improve them, I think we need a bit of a plan of how we’re going to do that, I’m not sure what the options are so it’s great if anyone wants to work on them and maybe experiment with what is possible. For example if we want dynamic things it would be nice to work out what and prototype it. Hopefully the star and planet stuff might give us the ability to do procedural lighting which might be cool, though I am concerned it might come up with crazy colours.
Sound: if anyone wants to work on sound feel free.
I think gato said they are working on an appearance tab so that’s a cool thing to include too.
I think we should have a discussion about bio-luminescence, how should it work, can we do glowing clouds, what should the mechanics be, does it tie in with the eyespot etc.
This is quite a lot in the end so we may not get through it. It’s fine to push stuff we don’t have time for I think.
I made a milestone on github: https://github.com/Revolutionary-Games/Thrive/milestone/13 I also set the tentative due date to be December 31, 2019.
And added issues:
“opened on 12 Apr 2018”
I think this is this bug (I opened an issue for it now, but I was pretty sure I had done that before?):
I’ll open an issue once this is decided.
I think we need some experimentation to happen before a direction can be selected. But I’ll open an generic issue to remind about this:
Added those and also added this one:
Also I put a few of those issues I want to work on to the release (and assigned them to myself)