This won't really help you consider another runtime specifically, but it is an instance of not choosing Tokio.

When I was benchmarking with Tokio I found it had quite a difference (higher cpu usage) to other options I was exploring. My specific use-case was an async single-threaded application which does mostly network io + timers. I would be interested to see how Tokio fairs today (I tested it over a year ago) and quite possibly any advice or tips in writing efficient code with it. My benchmark was send/recv with a UDP socket and print out stats in a timer (that's the core idea of what I needed to use it with). Comparing both CPU usage and maximum throughput.

For normal async, I would probably still reach for Tokio, but the use case I was looking at was very much specific to what I was working on at my job (still am), and lower CPU usage as well as higher throughput is what we needed. We ended up building a small internal runtime that uses mio, it was also fun to implement. In the benchmarks we ran, it used less CPU % than Tokio, and achieved higher throughput, by enough that we thought it was worth continuing to use our internal one.

tl;dr: I'm working on a falling sand physics-powered, 2d block-based open-world survival crafting game with spells instead of weapons and tools.

Working on a game that takes elements from Terraria, Noita and Wizard of Legend.

The falling sand physics of Noita intrigued me, but I always wondered what it would be like in a game like Terraria.

I watched the Noita dev talks about their engine (Games Now! Talk and GDC Talk), and they were nice to get started, but they definitely omitted some of the hard details (due to time restrictions I imagine), and for some reason, I found it real hard to find a good lighting algorithm online that worked for block-based games (I ended up finding a simple one that was easily parallelizable, works for day/night cycles and moving light sources that are grid aligned).

Like Terraria, the world is made up of blocks, but for my game blocks can become part of the falling sand physics when they crumble in some way, and they can be interacted with through the falling sand physics too.

So I've got the interactions of things like fire burning wood blocks one pixel at a time, acid melting through dirt and stone, flammable gas, water. Example of fire interacting with wood here And a full image of what the game looks like with its basic UI here

Now I'm working on implementing a bunch of spells as well as enemies. Spells have cooldowns unless they're basic spells. What I really wanted to do with non-basic spells is to have them be cast by taking the element from the world itself and then casting the spell with it, much like bending in Avatar. For now though, I just want to implement something so testing it isn't boring (falling sand physics alone took a bunch of time).

I really want to see multiplayer in this, too, so I've been careful not to make it completely impossible to do later (I did abuse RNG a bit, but I'm hoping I can fix that later ;))

I also decided to make it in Rust, using bevy_ecs (not bevy itself) and Vulkano (Vulkan rust library) with SDL for windowing and fmod for audio.

Since I don't actually have a dev log or anything, I mostly use my existing (Terraria server) community so at least some people are around to help me test things or give feedback, so I post it all here: https://forum.dark-gaming.com/c/game-testers/54.

If anyone needs details for any of the systems I mentioned, let me know, some of that stuff was difficult to implement (I'm still refining them) and a lot of information is scattered around the web that makes it hard to implement this stuff (seriously with the lighting, did I just miss some obvious post somewhere?).

I'm working on a falling sand physics-powered, 2d block-based open-world survival crafting game with spells instead of weapons and tools.

I'm currently using bevy_ecs (not bevy itself) and Vulkano (Vulkan rust library), SDL2 for windowing and fmod for audio. Developing on Linux but testing and building on Windows every now and then.

I've been running a Terraria server since 2012, and have had a lot of experience in C# working with Terraria's netcode and Terraria internals (via decompiling and IL patching), so decided it was time to try make something of my own.

I didn't know any engines, but I had previously used SDL2 for smaller things. We started using Rust at work (not game dev related) and I had used Rust a few times for personal projects. I got really interested in some of the functional programming concepts from languages like Ocaml and Haskell, so I decided I would make the game in Rust, despite that it may not be the most popular path.

The games that use this mechanic are few and far between. I'm not sure where to find a complete list, but there's this wikipedia article on it. I can imagine why, though, because it takes what would be a small, simple game to run and turns it into a CPU using monster. I actually found quite a few game projects on github with this mechanic that were left abandoned.

If you've not played Noita, Powder Game or Powder Toy, I can imagine why my description doesn't quite make sense. I think a gif does far better than words in this case ha.

I was hoping that because there were few games that had this mechanic (and not just the mechanic as the game) and none of them were multiplayer, that it would stand out from games like Terraria in the genre.

Did you ever mention what you were working on?

Well, that still sounds like a nice project. And a more attainable goal than I've set myself possibly. Are you doing it simply as a way into Godot, or are you planning to do something with it? Like, publish it somewhere?