- Linux support
- Fix for audio crash on some systems
- Parallax background
- Editor symmetry
- NPC membrane coloration
- Fix for membrane glitch on large cells
- Chloroplast spawns in the environment
- Some editor fixes
- New .exe icon
- Fluid simulation
- Compound clouds
- Temporary text tutorial
- Sound effects overhaul
- Wobbly cell membrane
- Basic rewrite of the process system code
- Smoother scrolling
- Minor adjustments and bug fixes
- Agents acting as compound clouds
- **New GUI**
- **Randomised microbe generation and mutation**
- **Overhaul of reproduction and health systems**
- AMD graphics support
- Organelle mass
- **Refactor engine to remove lag**
- Overhaul of process system
- Adjusted compound densities
Release thread: Release 0.4.0 Thread
Concrete issues are collected on this board: https://github.com/orgs/Revolutionary-Games/projects/2
Collected list of features to add at some point is now on the wiki:
Old plan: Future Release Plans
Great job with creating this thread; I’ve been wanting to do something similar for a while.
I think you did a pretty good job with the list and I cannot really think of anything to add. The features I want to work on for the next couple of releases are:
- Fluid dynamics/compound clouds for some really realistic gameplay.
- Agents/Revamping health system/Organelles
- Reproduction works in a scientifically correct way.
I am also assuming that the following is going to be worked on by the other programmers/graphics designers for the next release(s):
- Updated Flagellum model (I have one on my laptop, so I’ll add this when I have time)
- Tutorial/Help panel (just need to modify the text, I can actually do this right now if someone can send me the text they want written)
- Options menu (jjonj was working on this, so it will probably be in the next release or so)
- Linux support (probably the most important issue right now, since we’re lacking a programmer because of it)
- Endocytosis (once we get bacteria in)
Rescaling the hex grid is super-easy, we just zoom out the camera
What do you mean by:
- Agent System
- Improved AI
- Microbial Biomes
Organizing your list into a few streams:
This, of course, is my blocker:
These will involve mostly C++/Ogre work:
- Fluid Dynamics
- Compound Clouds
- 3D Background
- Dynamic Membrane
- Less Geometric Membrane Rendering
- Membrane Colouration
- Colour Variation Between Organelles
These all involve GUI:
- Improved Help Panel
- Improved Compound Panel
- Options Menu
- Starting Settings
Herobrine is not a bug, but a feature:
These are probably easy from a code perspective:
- Updated Flagellum Model
- More Organelles (though cilia will first require a rethink of flagellum calculations)
- Rescale Hex Grid
- Rescale Organelles
- Agent System
- Ambient SFX
- Improved AI
- Microbial Biomes
- Endocytosis for Organelles
- Improved Reproduction
- Improved Health System
Adding my own:
- Rejigger Process Rate Calculations
- Basic Population Tracking
- Big Entity-Component-System Refactor (so big, it has 4 difficult issues on github)
- Maybe some random AI microbe mutation / random starter generation
Now, I’ll assume the Agent System is the system simulating ligand-receptor affinity using matching of pseudorandom codes, since that’s the only thing I can imagine that could be.
So here are some quick thoughts on what will depend on what:
- Rejiggering Process Rate Calculations -> Agent System, Bacteria, Improved Health System
- Bacteria -> Endocytosis
- Lots-o-stuff -> Auto-Evo
- Lots-o-stuff -> Multicellularity
- Fluid Dynamics -> Compound Clouds
And some thoughts on how a few things will be implemented:
- Tutorial: Will need a trigger-scripting system, which allows us to write simple conditional lua functions an have the System worry about when to run them
And now my thoughts on what we should get done for 0.3.1:
- Rescale, new organelles
- All the GUI things on the list
- Bacteria, Agents, Clouds, and all the ancillary things for these
- Maybe a couple other things on the C++/Ogre list
- Better AI (necessitated by a switch to compound clouds)
- Big ECS Refactor (though I’m considering bumping it off until just after 0.3.1)
- Some basic random generation/mutation of AI cells
- Population/chemical success tracking for Auto-Evo
And what I want to work on:
- Process Rejiggering
- ECS refactor
- Random generation/mutation
- Population success tracking
Hmm, now about the “Microbial Biomes”: If you want us to create varying types of microbiome that the player can swim into, I can definitely get into doing that for 0.3.1. If it’s the biome stuff for Auto-Evo, well, there wouldn’t be any point to it yet.
@TheCreator I think Oliver wrote it up as part of the GDD but I’m not positive.
@Moopli By agent system I mean what you said, since currently we only have OxyToxy and none of the other features we have planned for agents are currently implemented.
By microbial biomes I mean the ability to choose the parameters of your start location (so it would be part of Start Settings). The GDD says:
“Start Location – This parameter is not tied to difficulty, so is still editable when a fixed difficulty is selected. The player chooses one of several microbial start locations (tide pool, stromatolite, hydrothermal vent, etc.)”
I updated the original lists. However, wouldn’t all the changes proposed for 0.3.1 warrant it be named 0.4.0? Would you guys want to make a minor release before 0.4.0 including the easy to implement features? If so, which features would go in 0.3.1 and which ones in 0.4.0?
What are you referring to?
I’m in favour of more small releases rather than few large ones. Even if a couple end up being mostly superficial (a release with Linux support would do nothing for Windows players, for instance) it shows fans that we’re continually working as opposed to going through several months of stagnation over a major feature, and should build a better relationship with them.
A couple of things I’d like to see which haven’t been suggested yet:
- Editor improvements (symmetry; divided sections for structure, surfacing, etc.; saving and loading improvements)
- New GUI (not too much of a worry until we get new 2D artists, but especially for the editor this needs revamping)
- Combat (to give more gameplay options)
Here’s the thing – we have a few big features which should probably all be released together (because there’s a lot of interrelationship between how each part affects gameplay), but that would mean we need to have another long release cycle. We also have a bunch of smaller features which we could pack into a shorter release cycle, but in many ways that will make the next long cycle harder. We also have a few big ideas on doing some big refactoring, which will be needed for auto-evo, planet simulation, etc.
The big features I’m thinking of are bacteria, compound clouds, and the agent system. I think it would be best to develop the 3 in parallel, because they’re quite interrelated but not so much so that one would have to wait on the others, which would probably mean each of us (@crovea, @TheCreator, and I) would do one.
Meaningful combat would require both clouds and pili, pili also require the agent system.
So if we want those in the next release, we probably can’t do a fast release cycle.
That leaves a bunch of things that are more superficial from a code perspective, like some more varied AIs, some more organelles, maybe clustering emitters to make the sea more interesting, more species, basic random species generation, random species mutation, parallax background, etc. I’m wary about coding up lots of this kind of thing before we do a major refactor, because it makes the refactoring much harder, and it can easily lead to spagghetification. But I can accept doing things this way – having a release where we avoid big redesigns, just add a whole bunch of these kinds of features, and tune gameplay.
I think you should go with the option that makes it easiest for the programmers (which as you said would be to wait a while for a big release). There’s no obligation for us to release the next version by a certain deadline, especially if it means making the job more difficult down the line.
Well, I guess one more factor is that we might not realize certain things the engine should allow for until we’ve written more small features. So, really, I’d be fine either way, on the balance I think it’s a choice between having different sets of features to test at different times, nothing more. The option where we don’t do as many deep modifications of the engine also has less risk of big delays, too.
Yep, a lot of the things rely on one another. For example,
You need fluid dynamics for compound clouds; you need compound clouds for bacteria; you also need refactoring of the processing system for bacteria. You need many of the same things for agents (including a redoing of the health system) and you need agents for combat.
My suggestion is to start working on the three big things that @Moopli mentioned and whenever someone finishes a feature we could release. By the way, dibs on doing the compound clouds/fluid dynamics.
Speaking of redoing the compounds processing and storage, I have three solutions: (1) We could quickly add organelle upgrading and allow the player to specifically evolve vacuoles that only store ammonia/reproductase/o2/etc; (2) We could have priority depend on proportion, i.e. we add up all the priorities and get a number (say 17), then for each compound we set aside their priority number/total priority space. This way we will always have a good amount of compound; (3) Release as is (no-one is going to really play the game as it is right now anyway—to be blunt, it’s a bit boring without a set objective) and worry about it for next release.
Finally, I am having a really hectic week right now (I fell a bit behind with life doing bug fixing for 0.3.0), so I’m not going to be as active and won’t be able to contribute much for the next couple weeks or so.
(2) Is a great idea. And in case, say, you fill your quota of a compound but there’s still empty space in your vacuoles, we could allow compounds to top-up above the proportional quota. Then, when deciding to eject, you simply eject the lowest-priority compound that’s above the quota (or do something smarter, by, say, ejecting a bit of everything above quota, scaled against priority).
Am I right in thinking that, from Nick’s list in the opening post, Linux fixes and compound clouds are the two highest priority items for 0.3.1?
Yes [post must be at least 10 characters, lol].
I made some updates to the OP. I was thinking, we could try putting the name of the person working on the feature beside the feature in the list for v0.3.1 to keep track of who’s working on what, and which features have not been assigned to anyone. Thoughts?
Sounds good, although I’m not sure how we could divide it up fairly.
We simply break the work down into tickets on github, and let the programmers figure out who will do what
Can I help? Looking at the work you’ve already done on the compound clouds, I think we could really smash fluid dynamics out of the park if we worked together on it.
I don’t see why not. In fact, you can take over. I haven’t really been able to work on it, and I won’t have much time for the next few weeks. Plus, there are a lot of other features that I want to work on.
To help get you started, all of the code I have written so far should be on this branch: https://github.com/Revolutionary-Games/Thrive/tree/Fluid-Sim, I think. I’ve temporary used a particle system to simulate compound clouds, but this should be taken out. The FluidSystem class creates a dynamic velocity field that stretches around the player (it’s not the most efficient implementation, but it will work for now). By calling xGrid(xPos, yPos) for each entity with a compound cloud component, you can get the velocity in the x-direction at its position. The plan is to follow this paper, but stop after page 8 (the section titled evolving velocities) and use the curl noise velocity field generated by xGrid, yGrid. To do this, you will most likely need to create another rolling grid that contains the density of each compound cloud at each grid cell. Or, you know, do what you think will work best.
I know that this is all probably confusing, but feel free to ask me any questions, and I will do my best to help.
PS. It might be a good idea to move this discussion to either the fluid sim thread on this forum or the slack group.
Am I right in thinking Linux issues have been fixed, or are there still some kinks to work out? Either way, with that and the OpenAL crash fix (which isn’t on GitHub yet but @crovea said he’d found a solution on Slack) I’m thinking it might be a good idea to release 0.3.1 pretty soon.
Since compound clouds, bacteria, etc. might take a while to implement, it would mean waiting a long time for the next release if we were to include them in 0.3.1, even if other parts of it (particularly the Linux build) are ready. In my opinion, 0.3.1 should be released soon (once everyone’s back after Christmas inactivity of course) with the bug fixes, then work can start on 0.3.2 with new gameplay features. That way, the maximum number of people are able to play the game without issues in the interim.
Ignore this post. I’m just creating a checklist for myself of all the things I want to do so that I don’t forget.
Create dynamic background
Give NPC microbes their own color
Allow the membrane to be any size (not confined to the small rectangle)
Create parallax background
Implement fluid sim and compound clouds
Add in bacteria that swarm and look realistic
Make bacteria release compounds clouds
Proof of concept toxin (same as current oxytoxy, but with an organelle model and a toxic compound cloud that diffuses withe time)
Cell combat system (toxins that affect all organelles)