r/rust_gamedev

Context: Monocoque is a pure-Rust ZeroMQ-compatible runtime (ZMTP 3.1), no libzmq, no C dependency. I have not posted since 0.1.3, so this covers 0.1.4 through 0.1.7. Numbers are on an i7-1355U (12 threads), Linux 6.17, rustc 1.96, loopback TCP, sender and receiver on separate OS threads, unless noted.

The headline is the backend split in 0.1.6. It runs on either io_uring or tokio now, chosen by a Cargo feature: runtime-compio (default, native io_uring) or runtime-tokio (the same socket stack on tokio, for macOS, Windows, older kernels, or to drop into an existing tokio program). They are mutually exclusive. Adding tokio was additive because the protocol stack is already generic over the io traits, so one small runtime facade names the concrete runtime and a thin tokio stream adapter implements the same owned-buffer io traits with no extra copy on the data path. No protocol code changed, and both backends keep sockets !Send.

PUSH/PULL throughput with coalescing on, per backend against rust-zmq:

On these single-flow loopback microbenchmarks tokio/epoll is the faster of the two. io_uring's edge is on real network I/O and high connection counts, not loopback ping-pong, which is why compio stays the default. Both beat rust-zmq once coalescing batches the writes, but coalescing is opt-in and you flush() when you want the bytes out, so it is a throughput mode, not the default.

0.1.4 and 0.1.5 cut per-message cost in a few places. Large PUSH frames now go out with a vectored write (writev via compio's write_vectored_all) instead of copying each body into the userspace send buffer: above SocketOptions::vectored_write_threshold in eager mode, the header and the refcounted Bytes body go to the kernel as an iovec, and the header buffer and iovec list are reused so the path allocates nothing. The default threshold is 32 KB, the measured loopback crossover, where skipping the copy starts to win by about 1.1 to 1.3x on the machine I tested for it (a 4-core cloud Xeon, not the i7 above). The worker-pool PubSocket coalesces a burst of queued broadcasts into one per-subscriber vectored write while keeping the fan-out zero-copy through shared Bytes clones. On the receive side, recv_batch blocks for one message then drains every further message already decoded from the same kernel read, and recv_into writes frames into a caller-owned buffer you reuse, so a steady loop does no per-message allocation. recv_into takes 64 B from about 7.7M to 9.7M msg/s, tapering as messages grow and the path turns bandwidth-bound.

0.1.5 also added worker-pool pipelines. A plain PUSH or PULL owns one connection, so it cannot drive a pool. PushFanOut binds once, accepts N PULL workers, and round-robins sends across them, which is the ZMQ load-balancing rule. PullFanIn merges N PUSH workers into one fair-queued stream with a batched handoff, one channel hop and one await per kernel-read batch instead of per message. That roughly doubles small-message sink throughput, from about 5.25M to 9.9M msg/s at 64 B on the reference machine.

0.1.7 is correctness work. PullFanIn had a memory bug: the merge channel bounded the number of queued batches, but each batch was a whole kernel read of unbounded message count, and a frozen message pins its whole 64 KiB slab page, so a sink that fell behind its readers held a growing set of pages. Peak RSS reached about 66 MB at 32 workers and 64 B, roughly ten times a single PullSocket at the same rate. Readers now forward each read in fixed-size chunks with the channel capacity lowered to match, so queued messages and their pinned pages are bounded regardless of payload or worker count, and RSS at that cell drops to about 15 MB with throughput unchanged. Separately, TCP_NODELAY was set at connect but skipped on three socket-creation paths, automatic reconnection, XPUB accepting a subscriber, and XSUB connecting upstream, so a reconnected socket ran with Nagle's algorithm on until the process restarted, quietly raising latency on the sockets you would pick for low latency. All three now apply the same setsockopt as the initial connect. Both fixes ship with regression guards: a peak-RSS bound on PullFanIn and fd-level checks that read TCP_NODELAY off the live socket, each confirmed to fail with its fix reverted. 0.1.4 also migrated the workspace to Rust edition 2024.

Repo, full changelog, per-backend tables and IPC numbers: https://github.com/vorjdux/monocoque

Run it and tell me where it doesn't hold up.

Stellwerk is the first game I have released. Players take on the role of an interlocking operator, setting switches, sequencing trains, and ensuring that everything arrives at the correct destination on time. As the timetable becomes more crowded, small ordering errors can lead to gridlock — a problem that Zach games are designed to solve.

It was developed by a lone developer using Rust/Bevy. It's available on itch.io (https://tilcob.itch.io/stellwerk). I'm happy to answer any questions about the design or technology used. I would be grateful if you could leave a comment on my Itch page telling me what you think of the game.

Every few weeks someone here posts a version of "imagine a Draw Steel video game." I couldn't get it out of my head, so I spent the last year building one in my spare time - LOTS of time.

It's a tactics roguelike. You build a party, drop onto a grid, and fight on the actual Draw Steel math, which was the whole point: the power rolls and tiers, edges and banes, all behaving the way they do at the table. Forced movement carries real weight, and yes, sliding something into a wall or hazard kills it the way you'd hope. Heroic resources and enemy malice are both in, so a fight builds and turns instead of just trading hits. Four classes so far: Fury, Censor, Shadow, and Troubadour. I'm going to try to add more before EA release, but at a minimum these 4 will be polished.

At it's core, it's full sandbox of the tabletop game alongside the roguelike on top. You can build your own party, pick one of the encounters it ships with or edit your own map and enemies, and just run the combat. Pick a party, drop them in, hit go. If you've ever wanted to see how an encounter or a homebrew statblock actually plays before it hits your table, that is what it's for. The enemies behave as close to their roles as possible too, but I will be tweaking that and hopefully adding a GM mode so you can run the monsters too.

A couple of things I figured this crowd would care about: none of the art is AI-generated (that's a line I'm not crossing, not a marketing bullet point), and it runs natively on Linux and the Steam Deck, not just Windows. I'm going to try to get Mac out at some point too, if possible.

It's an unofficial fan project made under MCDM's Creator License (Powered by Draw Steel, not affiliated with or endorsed by them). I backed the game originally during the OGL debacle and have been really enjoying it :)

There's no demo yet (look out for Steam Next Fest) and I'm still deep in it. I've been running tabletop games for years, so a video game feeling faithful instead of a generic tactics game with the name slapped on matters to me more than anything. Mostly I want to hear from the people who actually run this system: what would make a Draw Steel video game feel right to you? You're the people who'd spot where I got it wrong.

If you want to follow along, it's up on Steam now and you can wishlist it here.

Programmers learning Rust struggle to understand ownership types, Rust’s core mechanism for ensuring memory safety without garbage collection now you can see exactly what's permission is going on with the code
https://8gwifi.org/online-rust-compiler/

Another update on the engine that doesn't use triangles.

For those who've been following this: remember the gaps between the points and the animation that felt stiff? Last post was barely a day ago, but I put in hours on this and look how it changed.

Now the models barely have any gaps from any angle, the animation moves solid and smooth, the textures load clean, and all of this in 4K… without dropping below 155 FPS.

It's still millions of little points generated on the GPU, zero triangles. But compare it to the video from a couple days ago and you can see where this is heading.

There's always more to do. But every version looks more alive. 👇

I've just released bevy version of my little project ;)
link to the game is here:
https://maiu-online.com/

Замість того щоб анімація програвалась по юніформу часу, вона програвається через фазу дистанції. Можна буде купу цікавого наробити так як воно працює зі скелетом 😋.

Також ото що пульсує, видає звук пульсації серця - теж залежить від відстані.

Hello! I'm Nico. Founder of and building Keylight, a licensing layer for macOS apps.

The idea came from a simple frustration: if you want to sell a macOS app outside the App Store, licensing quickly becomes messy.

You either use a full payment platform where license keys are just an extra feature, or you build your own system with keys, activations, renewals, offline access, analytics, customer portals, etc.

Keylight is trying to be the focused middle layer:

• Issue and manage license keys
• Support subscriptions, renewals, upgrades, and onetime purchases
• Add offline license checks for macOS apps
• See useful analytics around activations and usage
• Work with providers like Stripe, Paddle, Lemon Squeezy, Polar, Gumroad, etc
• Use a Swift SDK to integrate into your app

The goal is not to replace every payment provider.

It’s to give devs and small teams a proper licensing system without taking a big cut or forcing them into one specific checkout stack.

I’d love feedback from SaaS builders here:

Would you prefer a licensing tool to be tied directly to payments, or kept separate as its own layer?

And if you sell downloadable software, what’s the most annoying part of licensing for you right now?

Site: keylight.dev

Found lemonyte's bouncing DVD screensaver written in Rust and added a missile that
launches from the farthest corner of the screen, homes in on the logo, and blows it
up with an animated explosion. The logo respawns elsewhere with a fade-in afterward.

https://github.com/VALLL67/dvd-screensaver-missile

I would really appreciate any feedback regarding pretty much anything, thankss!

And I hope to inspire other people to release more games made with Bevy since it's such a wonderful engine

https://youtu.be/Qkx0DrnnZjQ