|
|
|
|
|
by johnnyanmac
534 days ago
|
|
you could say the same of Balartro on first blush. It really comes down to if we are approaching an engine's viability from a lens of a techie who wants to push the limits of the industry, or as a entrepreneur who wants a tool that fits their workflow. I'm a bit in the former, but those latter games do help get funding for projects so the engine can push further. |
|
However it isn't on the same league as the studios that care about shipping games in C, C++ and Assembly as main development tools.
Right now, other than Bevy existing efforts, and absent of regulations that force those studios to adopt Rust, there aren't many reasons on the market for those studios to change their tooling.
As small history lesson, it was the success of games like Quake that finally settled using C and C++ for game development, after they started to enjoy some love in the demoscene.
C on game consoles, followed by C++, only started to be a thing after the PlayStation, the first games console to ship a C SDK instead of having only Assembly based tooling. Also Yaroze only had C support.
C++ joined the party via the PlayStation 2 SDK.
C# was used for the first time successfuly on Arena Wars[0] back in 2004, with the studio doing their own OpenGL bindings.
It took Managed DirectX, followed by XNA and XBox Creative Arcade, MonoGame, Unity adopting MonoGame for their crossplatform rewrite (they were originally Mac OS only), lots of money to bring it to game consoles, for .NET based tooling for finally starting to be relevant as well.
Before Unity took over, it was already being used as alternative to create game tooling based on C++ and MFC.
Java never had much luck, because Sun understood game development even worse than desktop development, so the JavaGamming initiative went nowhere, even though there were nice engines like jMonkeyEngine, JOGL and LWGL.
There was LibGDX for a while, but the RoboVM acquisition from Xamarin, only to be shortly acquired by Microsoft thereafter, kind of killed what it had going for it.
Still, it is unavoidable on Minecraft, where Bedrock version isn't nowhere the mod community size as the Java one, and Android casual games. Also Android non-casual games do require some level of Java/Kotlin code, given that only rendering and audio is exposed on the NDK.
Note that despite all the Rust adoption talk by Android team, there are no plans for official Rust support on the Android NDK, and Kotlin Native might even get there first, still looking forward when this might change.
[0] - https://en.wikipedia.org/wiki/Arena_Wars