-
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants
I have a simple question that maybe someone smarter than me can answer confidently:
If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?
Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.
I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.
Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev and rationalized it by noting there's not a lot of complex simulation games running in browser (that I'm aware of). It's not clear to me if that's actually true, though.
-
I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants
I have a simple question that maybe someone smarter than me can answer confidently:
If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?
Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.
I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.
Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev and rationalized it by noting there's not a lot of complex simulation games running in browser (that I'm aware of). It's not clear to me if that's actually true, though.
-
-
-
I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:
We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.
Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.
All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.
[1] https://github.com/glicol/glicol-cli
[2] https://github.com/chaosprint/glicol
-
I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:
We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.
Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.
All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.
[1] https://github.com/glicol/glicol-cli
[2] https://github.com/chaosprint/glicol
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1].
The bigger problem is just inertia: large game engines are enormous.
[1]: https://github.com/microsoft/windows-rs
-
embryo-engine
An intensely data-driven, dynamic ECS-based game engine optimized and specialized for immersive sims and sandbox open world RPG games, designed with modding and easily creating large amounts of content and complex simulations specifically in mind. For those who look back on Deus Ex, Thief, or Morrowind fondly.
Quick note: I'm actually very slowly prototyping something like this here: https://github.com/alexispurslane/embryo-engine/
I'm disabled so I don't have a lot of energy to work on it often, but, especially once I nail down the last few design issues, I'd really love help, or even just a few eyes on the project to encourage me ;)
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
-
I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too.
There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.
[0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...
-
* https://github.com/joshhansen/Umpire
-
No blog unfortunately, the notes are all on paper. I have github page for the game where I ramble a bit: https://github.com/mikhmha/SWARMMO
But I'm planning to release the game for testing next month! Its a browser "MMO" game too so its going to be easy to try out.
-
phaser
Phaser is a fun, free and fast 2D game framework for making HTML5 games for desktop and mobile web browsers, supporting Canvas and WebGL rendering.
If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need.
[0] https://phaser.io/
-
I don't use Rust for game dev but I do for low level libraries and find it easier than C++ to get started. I have enjoyed it more than Java and like it for different reasons than Go, but it feels good to program in.
As for the design patterns that a complex game requires, if you are considering Rust for game dev and ecs design patterns it might be useful to check out projects that are Rust centric like https://spacetimedb.com/.
-
And yet the fact that Bannerlord game logic is entirely in C# makes this possible:
https://github.com/int19h/Bannerlord.CSharp.Scripting
which in turn makes it a lot easier and more convenient to mod. Try that with Rust...
-
ffi-overhead
comparing the c ffi (foreign function interface) overhead on various programming languages
The overhead for Go in benchmarks is insane in contrast to other languages - https://github.com/dyu/ffi-overhead Are there reasons why Go does not copy what Julia does?
-
-
burn
Burn is a next generation Deep Learning Framework that doesn't compromise on flexibility, efficiency and portability.
You can use libtorch directly via `tch-rs`, and at present I'm porting over to Burn (see https://burn.dev) which appears incredibly promising. My impression is it's in a good place, if of course not close to the ecosystem of Python/C++. At very least I've gotten my nn models training and running without too much difficulty. (I'm moving to Burn for the thread safety - their `Tensor` impl is `Sync` - libtorch doesn't have such a guarantee.)
Burn has Candle as one of its backends, which I understand is also quite popular.
-
> If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.
So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark
On this wee laptop the numbers are 532 vs 6381 cpu cycles when sending a message (one way) from one async thread to another (tokio) or one kernel thread to another (std::mpsc), when limited to one CPU. (It's limited to one CPU as rdtscp numbers are not comparable between different CPUs; I suppose pinning both threads to their own CPUs and actually measuring end-to-end delay would solve that, but this is what I have now.)
So this was eye-opening to me, as I expected tokio to be even faster! But still, it's 10x as fast as the thread-based method.. Straight up callback would still be a lot faster, of course, but it will affect the way you structure your code.
Improvements to methodology accepted via pull requests :).
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
