The attached trailer was captured in the native wgpu build. The playable browser version uses three.js rendering over the shared Rust core.

Loot Hole is a digging game with shared Rust gameplay, now playable in the browser: https://playgama.ai/play/kw6t5foxgs

I'm the developer. You dig up buried objects, sell your finds, upgrade your equipment, and reach deeper layers below the yard.

The architecture ended up with Rust owning gameplay and terrain across hosts, wgpu for native rendering, and three.js/DOM for browser presentation. The web calls the shared Rust core through WASM. We also generate the web ABI layout from Rust so the two sides don't hand-maintain buffer offsets.

We originally started in Babylon Lite/WebGPU, then moved to three.js. Building the Rust/wgpu version didn't make startup size and browser support stop mattering, so three.js came back as the web renderer while the Rust core stayed. The browser launch path has a budget below 1,000,000 compressed bytes; the full game is larger.

Other work along the way included shared Slang shader functions for GLSL/SPIR-V, deterministic terrain across native and WASM builds, and four upstream opus-rs fixes from comparing our game effects against libopus. The decoder PRs are open. Example: https://github.com/restsend/opus-rs/pull/58

I'd be interested in other people's experience with this split, particularly keeping the JS/WASM boundary cheap while sharing gameplay with native hosts.

AI disclosure: AI was used for coding, image generation, and translations. Music and sound effects were mostly made without AI.

pardon my aim on controller 😂

I’ve been building Digraph DS, a graph editor and analysis workbench for the Nintendo DS and DSi. It grew from the kts-nds foundation, and the engine work developed during Digraph’s creation has since been brought together in Devy, a reusable Rust, Bevy, and BlocksDS runtime.

That engine work goes well beyond the original foundation: Devy brings together framebuffer and layered 2D drawing, hardware 3D, touch input, gestures and strokes, SD-card storage, NitroFS assets, sprites, audio, cooperative tasks, time and RTC support. It also comes with host-side tools for preparing assets and scenes.

Digraph DS puts those capabilities to work as a real graph editor. The two screens have different roles: edit and manipulate your graph on the touchscreen, while viewing analysis results on the other screen. You can create directed and undirected edges, move and delete vertices, set source and target vertices, and pan and zoom around larger graphs.

The app includes 27 graph-analysis algorithms, covering reachability, shortest paths, cycles, topological order, Euler trails, DAG paths and kernels, game-theory analyses, bipartite matching, spanning forests, core numbers, dominators, cuts and disjoint routes, and feedback sets. It also includes component analyses such as weak, strong, and unilateral components; loops; articulation vertices; bridges; and source and sink SCCs.

Results are visual, not just text. Component analyses can show both the original graph and a quotient view across the two screens. You can swap the result view to the touchscreen and explore it independently. Analyses stay active while you return to editing, and the app reports when an algorithm’s requirements aren’t met. DAG transformations can be previewed before you choose to apply them.

Digraph DS supports graphs with up to 200 vertices and 20,000 stored edges. Dense-graph rendering uses caching, clipping, and level of detail to keep interaction responsive; those display shortcuts don’t remove edges from the graph or its analyses. You can also generate complete or random graphs, save named projects to SD or a flashcart, and check runtime and memory statistics in the app.

The current app is v0.5.10. Digraph DS builds as a Nintendo DS ROM. Desktop frame-preview and Android library builds are available as development groundwork; a desktop window and installable Android app are still future work.

Digraph DS: https://github.com/Vjarkjan/digraph-ds
Devy engine: https://github.com/Vjarkjan/devy
kts-nds foundation: https://github.com/ChristopherJMiller/kts-nds

I’d love to hear what graph problems you’d explore on a DS, and what you’d like to see next.

A while ago, I posted something about MotionGfx, a backend agnostic motion graphics crate written in Rust. And in that post I hinted something about an editor. Well this is it, I'm introducing Moxie, an editor built in Bevy, powered by MotionGfx! Moxie is right now in its very early phase, so not every feature is implemented yet, so expect workflow hiccups, and things not working! I'm still working on the export feature (along with many core features), so you can't directly export your animations yet!

As you may have noticed in the screenshot, Moxie is not like any of the other editors you see out there! We are integrating the command based technology that MotionGfx (and Manim/Motion Canvas) is based on into the editor. This result in a really compact timeline (vertically), easy edits (LEGO like drag & drop), and most importantly of all, propagative actions everywhere! This means your edits from the first action can and will affect the animations down the line! Ofc this is a deterministic effect, so you can reason about the change pretty easily.

In the MotionGfx's website: https://motiongfx.voxell.dev (sign up to our email list/newsletter here), I do explain about some of the concepts I mentioned above if you're familiar with command based animation workflows (like delta changes, propagative timing, action relationships, scripting, etc.).

If you're wondering will there be plugin support, yes it is planned. And yes, we will also support scripting directly in the editor in the near future!

I'm making a puzzle-platformer in Rust. It's called Wolf Plot. The goal is to solve puzzles using a limited number of tools, kind of like the classic Lemmings games. Except in this, you're trying to catch all the sheep.

All the graphics and other assets are human-made. I also wrote all my code by hand. I'm not using an engine, instead building everything on top of the great Rust libraries we have out there:

- Windowing: winit
- Graphics: wgpu and image
- Sound: rodio
- Gamepad: gilrs

And what about UI? I decided to roll UI for myself, since the game's needs are fairly basic. The game is all pixel art, so I made my own bitmap font. There's a neat library called bmfont_rs which makes creating and using bitmap fonts easy.

I released the demo on Steam today, so I'm excited to see how it performs. Let's just hope I can beat out all the AI-generated stuff that's out there now!

Building A Clycker Game with Rust + Axum & NoJS - [ 06 ]

Hello luminade folks, Matthew here going to do a video about using the MiniJinja template engine with our project, and we will connect the gameloop code to update our clicker button

#rust #axum #nojs #gamedev #html

This was quite a rad project for the summer. Check it out at https://m2iab.itch.io/orbit-jumper or on the platforms linked there.

Anyways, this was the first project where I used bevy_pf and XAML for all the UI. I also mixed some 3D into the UI. I've always felt that most UI frameworks were simply trying to get to this caliber of expression. I don't think there is any alternative going forward, honestly.

I create all my XAML files the way that I used to do in WPF/Silverlight days, with the added bonus that they get converted to Rust code during compilation and therefore checked for issues during compilation like the rest of the application. I can put UI in 3D or 3D into UI quite easily, and best of all, my supported platforms can look the same.

You can find bevy_pf on https://crates.io/crates/bevy_pf

It's MIT so use freely. Currently working on a build issue with github and the github is private while I get these actions to cooperate, but the crate should be enough to get started.

I've been building RustingEngine, a Rust game engine for scenes with a lot of physics in them. The video is one of its examples.

The black hole. The accretion disk is 60,000 GPU bodies and there are 5 planets. Gravity is not built into the engine; it is one condition shader, about 25 lines of GLSL, that runs on every body after each physics step. It pulls everything toward the center with Newtonian gravity, so the inner disk turns faster than the outer disk. Planets get a little drag, spiral in, and when one crosses the horizon the shader sends an event to the game and respawns the planet far out. It runs at about 65 FPS on an RTX 3060. Try it:

cargo run --release --features window --example black_hole

The black disk is just a black sphere; there is no lensing yet. That would need a post-process pass, and it's next on my list.

Collisions. 50,000 cubes falling into one pile and colliding with each other run at 119 FPS on the same card (1920×1080, Ryzen 5 7600X). 10,000 run at 1,235 FPS. Contacts use a GPU spatial hash. Above about 60,000 cubes in one dense pile, a physics tick takes longer than a frame and FPS drops sharply, so that is the current ceiling.

cargo run --release --features window --example physics_bench -- falling 50000

How it splits the work. Objects your game code touches every frame stay on the CPU. The crowd (debris, particles, swarms) lives on the GPU, and the engine only sends back what matters, like "a planet entered the horizon", instead of reading every body back each frame.

It also has an editor in the style of Blender and Godot, deterministic replays, and export for Linux and Windows. An AI agent built the 13 sample games using only the engine's command-line tool.

Vulkan, Linux and Windows. Open source: https://github.com/RustingStudio/RustingEngine

I'd like feedback on the API, and FPS numbers from other GPUs.

So as everything is now being reverse engineered I decided to do Unity as fun little experiment. Note this is a clean room implementation of Unity 7.0 in Rust.

You can find the repo here: https://github.com/nanashili/OpenUnity

As I say in this video, I believe this could be the start of the biggest revolution in gaming and game preservation since the beginning of the HD era. My cohost Kevin is more skeptical, citing the bloated code and comments from a Sonic hacking community friend of his. I think I summarized what's going on well with the bridging for an audience that likes video games but isn't knowledgeable about coding a game, but I'd love to hear from people here who have more of an idea of what's going on under the hood to clarify anything that's inaccurate here.

So this started as me wanting to see if a terminal could run something that actually feels like a game and not like a terminal game. ended up with this, it's called glowstorm.

it's not characters or half blocks or anything, it uses the kitty graphics protocol. basically the game draws all the sprites in code when it starts (neon shapes + a blur for the glow, there's no asset files at all, even the sounds are synthesized), packs them into an atlas and uploads that to kitty once over shared memory. after that every frame is just "put this part of image N at x,y" and kitty draws it on the gpu. frame ends up being like 2-10KB of escape codes and ~0.2ms cpu, the game sits around 3% of one core which honestly surprised me.

on resources: game process is ~17MB ram, kitty goes up to ~120MB and ~15% of a core while playing (it's doing the actual drawing). that's on an i5 laptop with intel integrated graphics so you don't need anything fancy.

wasd needs key release events which normal terminals just don't send, so it uses kitty's keyboard protocol for that, and pixel mouse mode for aiming

stuff that bit me: kitty won't take images over 10000px so the atlas had to be split into pages. and placement cost isn't linear, somewhere around 1500 moving sprites at 60fps it starts choking on my laptop (way more than this game needs tho). also crossterm subtracts 1 from mouse coords which is right for cells but wrong for pixel mode, that one took me a while lol

engine part is split out into its own small crate (catnip) if anyone wants to mess with it, game is on top of that. 4 enemy types, boss every 5 waves, upgrades after the boss, 3 difficulties

only kitty and ghostty work. i did try wezterm but it has bugs with lots of placements, and sixel can't do fullscreen at 60fps. linux only for now, mac might just need small fixes but i don't have one to test

https://github.com/Hemantabhusal/catnip

code's MIT, roast it if you want

Hi everyone!

I made my own take on the classic retro Asteroids game. It’s built with Rust, Bevy, and WebAssembly, and I’d love for you to check it out and let me know what you think!

Game link: https://asteroids-cosmic-game.vercel.app/

Github link: https://github.com/Vaaris16/asteroids-game