The game performance has been talked about for quite a while now with effort going into finding the problems and talking about radical ways to improve the performance. These ideas about radically reworking the game has come up in other contexts as well.
Based on those points I think it’s finally time to talk this through and decide what to do (as Godot 4 is still not here, which might help a bit with the performance).
I’ll line out the main points first, then add a poll here (and one on the community forums: Discussion on reworking the game logic for performance reasons (poll) - Meta - Thrive Community Forum). At the end I’ll share my opinion and potential alternative future direction to decide based on whether this is done or not.
So the idea is that instead of relying on Godot Nodes to construct the microbes, chunks and other game elements, we would do our own game logic simulation. Then based on the simulation we can use Godot just to render the game. Of course we’d still fully use Godot for the game GUI as Godot’s GUI system is very good and it isn’t any kind of issue.
Why is this then such a big discussion? Well the reason is that I estimate it could take multiple months to complete this work. I think I could make this change happen in a month, but from experience I know that any programmer’s schedule estimates should be multiplied by 2-3 to get an accurate number. So at a non-optimistic schedule doing this gameplay logic rework would mean that there’d be one full release where I wouldn’t have time to make major changes for that release (so we’d likely have one very feature-bare release).
Here’s the poll on whether a lot of time should be put into reworking the game logic to get the performance problems under control (of course this isn’t a magic bullet for really slow computers where compound cloud simulation and just a couple of active cells already result in really low FPS):
- Yes, but not yet
I put in the “not yet” option for people who think we should wait for Godot 4 or more of the game to be completed, though I must say that the more work goes into the microbe stage the more effort there’ll be in this kind of conversion later.
Now it’s time for my own opinion. Based on recent discussions about other related things and the ever present performance complains, I think this rework project should be undertaken. I’m right now going to work on a microbe benchmark next which will be one of the main tools I’ll use to get an early estimate on how well this kind of change would perform. I do want to work on some prototypes before undertaking this work, so I’d say if there’s enough “yes” votes, I’d start working on this around March.
It would be really nice to finally be able to get people to stop complaining about the performance.
And finally some thoughts on the future if “yes” wins. I think we should keep the game logic in C# so that development is easier (finding volunteers to write good quality C++ seems a lot harder), and moddability stays excellent. We’ll be giving up something like 30% of performance compared to C++, but I plan on utilising threading as much as possible so that when Thrive is ran on computers with 4 or more cores we can still have C++ level of performance without any of the difficulty.
One potential change which I’m unsure whether it would be good or not would be to go from an OOP approach to an ECS approach. Instead of just reworking the way the Microbe etc. classes interact with each other and the game physics, the refactor would go much deeper and would change the game to use an ECS to split the game entities into multiple separate components. I think this will increase the refactoring time quite a lot. My guess is that by just ripping out the Godot parts and redoing the graphics stuff, it’ll be actually kind of a doable change to move the logic to C# in about a month. If an ECS refactor is also done I think that’d take quite a bit of extra time and would also require everyone on the team to get familiar with how to structure code in the future and work with the new structure. But do we have any huge ECS fans who’d be in favour of this change? We could always do a second refactor to make the game logic neater with an ECS after the performance related refactoring. I found one good looking C# ECS that might serve as a good base: GitHub - sebas77/Svelto.ECS: Svelto ECS C# Entity Component System
One slightly complicating thing with the refactor to C# is that we anyway need to grab a physics engine. I think I’ll grab some C# bindings for the bullet physics as I think that’ll probably be the best option, but if anyone knows of any other promising alternatives please do mention them. Using bullet means that we’ll have a native library that needs to be compiled. For this my plan is to of course make scripts for compiling the library, but also a tool to automatically download precompiled version. That way the impact on anyone not updating the physics library compiling the game is relatively minor.
So my plan for the refactor is to first do that benchmark I mentioned above. Then do a quick proof-of-concept prototype using that benchmark just to validate that this approach can truly achieve at least 2x the number of cells (I’m hoping closer to like 10x) at the same FPS. After that validation is done, I’ll setup all of the compiling scripts etc. properly and go into the game codebase proper to refactor all the game entities and setup a new base system for worlds to simulate physics entities with the custom logic. It’ll probably also make sense to update the editors to use the new approach as making two separate ways to draw organelles (in the editor and in the stage) doesn’t seem like a good design decision to me.