Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
bfg-repo-cleaner
Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
-
https://rtyley.github.io/bfg-repo-cleaner/ (Java) seems to be the favored tool; there's also https://github.com/xoofx/git-rocket-filter (.NET) and the built-in commands: https://stackoverflow.com/questions/2100907/how-to-remove-de...
You'll have to unprotect the branch to force push to GitHub, and anyone who has already cloned the repo may not appreciate basically having to start over, so better to get it over with ASAP!
https://rtyley.github.io/bfg-repo-cleaner/ (Java) seems to be the favored tool; there's also https://github.com/xoofx/git-rocket-filter (.NET) and the built-in commands: https://stackoverflow.com/questions/2100907/how-to-remove-de...
You'll have to unprotect the branch to force push to GitHub, and anyone who has already cloned the repo may not appreciate basically having to start over, so better to get it over with ASAP!
The simple truth is that a single talented, unencumbered (ie, as repo owner you're less encumbered by PR etiquette and feature direction), motivated developer in open source software, especially from what I've seen in the game-engine/framework space where multiple disciplines come into play, is far more effective than a large group of contributors will ever be as far as pushing large new features is concerned.
When it comes to picking a smaller open source game engine, it becomes essential to evaluate the hero developers involved: how committed are they to the project? is their effort sustainable ?
I think Bevy will work out long-term, because they have structured as a sustainable foundation with solid project management, however the lack of a hero dev that who can contribute to all the sub-crates [1] within the bevy ecosystem also means you have odd quirks in Bevy that will remain longstanding on the issue tracker, like for example setting the texture wrapping mode.
For that reason, Fyrox is worth serious consideration if you're constraining to the rust ecosystem of game engines/frameworks. Just one developer, but he's got the old-school experience and dedication, and the framework looks/feels much more familiar to a C++ game developer. It's not the sophisticated beast that Bevy is, but that's a good thing to the kind of person who would even consider these game engines/frameworks in the first place.
What really saddens me is that these hero game devs are still choosing C++ instead of rust. There are so many great flash-in-the-pan game engine/frameworks in C++, but they will never take off for a number of reasons.
When you look at how game devs approach development in C++, you come to realise that Rust is the language we wanted all along.
[1] https://github.com/bevyengine/bevy/tree/main/crates