-
-
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.
-
-
procedural-spider
Small game where you play a big spider chasing small spiders, written in Rust and Macroquad.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
When you feel like doing more custom stuff, I recommend looking at both their checkbox widget https://github.com/emilk/egui/blob/master/egui_demo_lib/src/demo/toggle_switch.rs, as well as the source code of builtin stuff in general. Other than some of the more difficult parts I'd say a big part of the codebase is very readable and I actually spent a lot of time looking at it for inspiration on how to do things. Considering the builtin widgets are implemented using the same ui.painter() API you'd use to make your own custom UI I'd say egui is one of the few projects where "source code is documentation" is actually working out pretty well :)
In terms of pure Rust engines/frameworks it seems the overall "problem" is lack of scripting, at least from my perspective. Mun seemed extremely interesting, but since even the project itself says "don't use it" I guess it's not a real option, and considering the amount of time we spent on the GDScript/Rust integration I'm a little worried that rolling something more custom would be even less efficient.
Out of the other Rust engines we've tried I think Macroquad was the most interesting option, and even though I've only made a few small projects in it worked extremely well and was what I'd expect from a game framework. While working in Bevy I felt like it was "writing fun Rust", but it wasn't really making a game. Macroquad on the other hand got immediately out of the way, and using it together with hecs was a painless experience where the whole time I felt like I was working on "the game" rather than "building systems that are invisible to the player".
But the thing is, we have to manually test every build via Steam anyway. Sometimes weird things happen, and at least playing through some part of the game is IMO necessary. I've spent quite a bit of time trying to use cross for cross compiling, but the rabbit hole when it comes to building dynamic libraries seems to go deeper than I'd like, and ultimately couldn't make this work to work on all combinations of all platforms (i.e. using cross on both linux and windows).
I feel like ECS is that in a lot of ways, where the sweetspot is narrower than it seems. I'd veeeeeery much recommend trying out Macroquad + HECS (or even bevy_ecs). I remember the feeling I got after taking yet another round of gamedeving with bevy and going into macroquad, and I was just blown away by how much more productive I was. Maybe it's the way my brain works, and maybe I'm too much of a "hacker" to do things properly first, but if you want a specific example check out this small game I made in Macroquad (link to github in description). I went from "never used this" to "maybe I should do procedural animation" to finished game in about a day.
Congrats on the release! And really eye opening write-up. I read that you will go back to Unity - I wonder if you’ve heard of heaps?
Thanks! Probably the biggest issue with had was overall input handling and fonts. We're still on egui version 0.14 and actually using our own fork (https://github.com/darthdeus/egui/tree/make-memory-areas-public) that exposes some private functions/data in egui. I reported a few issues and honestly don't remember which one was the reason, I think it was this one (https://github.com/emilk/egui/issues/800).
The problem with input handling was less to do with egui itself and more to do with Godot and the fact that godot-egui was extremely new at the time, and I actually spent a lot of time talking with setzer as we used it.