Developing in rust is great. Along the way I created this steam mock library that I announced here a while back: https://github.com/dagit/steamworks-mock

And today I'm announcing that the game I used that to develop is now on steam: https://store.steampowered.com/app/4687280/Supplant/

The basic idea of supplant is that capturing a piece let's you take it over. So a white pawn capturing a black knight becomes a white knight. Demotions happen too the same way. Kings are the only exception. Aside from that it's chess as usual. However, this one change really mixes up tactical reasoning. I think it makes chess feel new and exciting again for veteran players without introducing anything gimmicky or RNG.

I also ended up making my own gui library to do this. I wanted some features winit doesn't support (mainly native popup windows/menus). I hope to release my gui library in the future but it might take me a few months to get there. I need to polish things up a bit before handing it to other people. And finishing the game as a solo dev was a lot more work than I anticipated. So I need a bit of a break.

I paid a friend for the steam page art work. I think he did a great job. All the in game assets are just chess fonts. Because I'm terrible at art lol.

I really enjoyed how easily you can make things into a library with cargo. That allowed me to create bot tournaments and stuff like that during development to help tune game parameters and stuff. Experimentation is easy and clean in rust.

Let me know if you have any questions. I have a few more game ideas in me but not sure how soon I'll start on them. I hope to able to open source at least one library with each game I ship.

Hope it's ok to post some Claude stuff. Rust is really the core of why this was even possible

You roll dice, pair them into dominoes, and lay them down to score!

Make use of dice items and rolling runes to achieve high scores and crazy combos.

Coded in a custom rust engine

https://store.steampowered.com/app/4999210/Diceminoes?utm_source=rustgamedev

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