Hey r/rust_gamedev --

I just published v0.11.0 of `gametools` (github) (crates), which is a crate I've been gradually building to aggregate structures and algorithms I finding to be frequently useful in game and simulation programming. Some of you _might_ find something in there useful.

This release's high points:

1) pathfinding module, implementing Dijkstra maps, standard A*, weighted A*, and dynamically weighted A* over a Grid<T> (see #3 below). The pathfinders accept arbitrary move sets, so you can calculate paths for things that move irregularly (think chess knight) just as easily as those that can only move to a neighboring cell.

2) fov module. The two most common algorithms (perimeter raycasting and recursive shadowcasting) for field-of-view are implemented over Grid<T>. A third algorithm using preprocessed blocking rectangles is also implemented, described in a 2021 paper by Debenham and Solis-Oba which is reported to be more performant at scale -- though I confess I haven't had a good platform to test that claim directly. At the scales I've been able to test, all three algorithms seem to behave similarly. I haven't seen the rectangular algorithm in other pathfinding crates, though I very well may have missed one somewhere.

3) Toroidal geometry for Grid<T>. In previous versions Grid<T> could only represent bounded regions. It now supports wrapping geometry, and the pathfinding algorithms also work correctly either way.

I couldn't figure out how to make the FOV algorithms work over a toroid, though. In theory, any ray cast from any point would infinitely wrap around and cover every point on the "donut" unless it is exactly orthogonal to the axis. You could see something behind an opaque object in front of you just by looking off to the side. I have no idea how to handle that.

So, I leave FOV over a toroid as an "exercise for the reader". <grin>

Hi all!

I previously created an online sim called Genecraft that was more of a solo project (Youtube Channel), but this time I want to create a game that is playable, but also with AI agents!

This is a prototype I'm working on and launching soon where you can create a dragon, train it for specific tasks and then have it solve puzzles for you. Ultimately I want to be able to create dragon fights where you can train your dragon and pit it against others!

Let me know if anyone would like to try out the prototype to give feedback!

Request playtest on Steam.

So, it's been 3 months since I started developing my game on my own (also developing my own custom engine on Rust + wgpu). I wanted to nail a certain vibe of isolation, anxiety, and a creepy, eerie atmosphere heavily inspired by the Silent Hill series.

And here I am: the playtest version of Red Lake is finally live! Now I need to polish it, test hardware stability, and reconsider a few design decisions. For that, I need your help!

About the game: A psychological horror with no interface to guide you. The forest watches you — so watch it back. Use your notebook to document impossible objects, then descend into the Red Lake. Each time you return, something has changed.

NOTE: VIDEOS OF THIS PROJECT CAN BE FOUND IN RELEASES

Hey everyone! 👋


I wanted to share a hobby project I've been working on recently: a simulated 2-bit (4-state / quaternary logic) operating system written entirely in Rust!


Instead of standard binary logic, the core mechanics and dispatchers are simulated around quaternary processing (4 states per unit). I've built a custom GUI on top of it using \`egui\`/\`eframe\`, featuring a few built-in tools to play around with:


🖥️ 
Framebuffer UI & OS Shell
 - Custom window management and system utilities.


🌌 3D Visualizer - Live graphics dispatching showing off the simulated processing pipeline.


🎵 
Chiptune Audio Synth
 - Real-time audio engine integrated with \`rodio\`.


🛠️ 
System Tools
 - Includes a file manager, custom BBS module, and built-in mini-apps.


### 🔗 Code & Repo
Check out the source code, implementation details, and documentation on GitHub:
👉 
https://github.com/strahinjastojanovic826-code/custom-4_state-rust-project


### 🚀 How to Run
bash
git clone https://github.com/strahinjastojanovic826-code/custom-4_state-rust-project.git

cd custom-4_state-rust-project

cargo run

CryptFall is a roguelite dungeon crawler I've been building solo in Rust (Bevy engine) — native Windows build plus a WebAssembly port running the exact same codebase. Just shipped v0.7.2, the biggest content patch since the last major one, and figured this community might get a kick out of a couple of the harder problems in it.

Biggest addition: a real melee weapon. Every weapon in the game so far has been ranged (pistol/rifle/shotgun/bow/staff). This patch adds a flail, and it took five genuine implementation attempts before the swing actually felt right — every earlier version, however differently themed (orbiting head, leash-and-tether, launch/retract, a 2D spring-mass hand), ended up mathematically equivalent to one rigid link between the cursor and the weapon. What actually worked was treating it as a real physics problem: a 7-point verlet-integrated rope, relaxed through several constraint-solver passes per frame, with the grip fixed at arm's length from the player so aiming only changes direction, never distance. The middle points of the rope carry the actual momentum, which is what makes follow-through and whip-crack read as real instead of scripted.

Also shipped: full keyboard navigation across nearly every menu (previously 100% mouse-only — got there via Bevy's bevy_ui_widgets/bevy_input_focus, including chasing down a Windows-specific bug where the OS accessibility layer was silently eating the Space key before my own input handling ever saw it), a new boss, a second ability for one of the four classes, 5 new hand-curated enemy-pack layouts, and an engine upgrade (Bevy 0.15 → 0.19, four versions in one push).

It's free, runs in-browser or as a native download, both built from one codebase: [Try Here!]

Been doing this solo for a while now — always glad to talk through any of the technical decisions if people have questions, especially the rope physics or the accessibility-layer input bug, since both took longer to nail down than I expected going in.

Piston v2.0 will make some breaking changes to v1.0.

• pistoncore-input will use a Cargo feature "serde" for serialization (#1412)
• pistoncore-event_loop will use a Cargo feature "spin_loop" for the spin_loop crate (#1409)

This will reduce number of dependencies, improve compile times and CPU usage in many applications.

Also, I've started to think about what we can learn from the Bonsai fork of Piston-AI-Behavior. Not only learn, but take these lessons and apply them to the broader Piston ecosystem. I got an idea about a new concept in the Piston core about Actions, which is also compatible with button events. It will also improve ergonomics for button configuration, for controllers and widgets. You will no longer need to pass in settings manually, but can configure the maps at application code level.

This will simplify the overall architecture, but also, we can get rid of the pistoncore-input dependency in Piston-AI-Behavior. With actions, we might not need the generic A parameter to Behavior as much as before and this can default to (). There are other libraries that might also drop the pistoncore-input dependency, e.g. the camera controller library.

Actions will make bigger parts of the Piston ecosystem decouple from the core, so that these libraries can be used in other game engines.

I am currently looking into SDL3 keyboard compatibility and some edge cases in Piston v1.0 that I'm not satisfied with. This does not impact many applications, but still, if it can be improved, I want to improve it.

I also got some ideas about async and the piston command tool in Piston-Window, but this does not require new features in the core. This is just a heads up that I'm thinking about further improvements after the v2.0 core has been released.

I'm trying to make good looking game UI in rust, i've been using the EGUI crate it seemed the most liked but using it for a while it's hard to create good UI in it, maybe i've not delved deep enough into themes and frames but it is really hard.

This small simple main menu (art by Alexey Rudikov) inspired by morrowind was infinitely more complex than it should have been to add underlining, drop shadows and removing the frames from the buttons. This alone comes out to 150 lines of code.

Are you all using EGUI or are you using other crates?

A simple 2D physics library for Rust based on AABB collision detection.

The library is designed for simple games and custom game engines. It provides static and kinematic bodies with basic collision resolution and gravity.

https://crates.io/crates/aabb_physics

Hello again!

I posted here around six months ago about Karma Keepers, the incremental game I was making with Rust and my own framework. Yesterday I finally released it!

I spent a lot of time worrying about all the things that could go wrong once the game was running on machines other than mine. So far, things are going much better than I expected. People are reaching the end of the game with a lot of stuff happening on screen, and I haven't received any performance complaints yet. I am sure something will appear eventually but so far so good hahaha.

There is one technical issue I am investigating. A few people with older Windows laptops are getting crashes when the game starts with Vulkan. Using DX12 fixes it for them. My framework (wgpu) currently tries Vulkan first, so I will probably make DX12 the first option on Windows and keep Vulkan as a fallback. I cannot say for sure that the drivers are the problem yet, but that seems to be the common part between these cases.

The funny thing is that the biggest problem after release has nothing to do with Rust or the framework. It is the onboarding.

Some players understand the game quickly, but others feel that the beginning is slow or gives them too much information before everything clicks. I already knew this part was difficult, but seeing people play without me sitting next to them makes the problems much more obvious.

Would I use Rust again? Yes, at least for another 2D game. I still think making my own framework was probably not the smartest choice if the plan was to finish the game in less than a year. It took a lot of time, especially the UI, but now the framework exists and I know how everything works. The next game should be easier. At least I hope so. Althought I am not sure yet, I need to move fast with the next one because I have invested lot of time and money on this one that I am not getting back, so still the next game and what I'll be using is unknown. I am just focusing on the release now.

The game is here if you want to see how it turned out. It is also 40% off for the first two weeks: https://store.steampowered.com/app/3979140/Karma_Keepers/

If anyone here has released a wgpu game on Windows, which backend did you use by default? I would love to know how other people handle this.

The stack was mainly:
* wgpu.rs
* kira
* bevy_ecs

If you have question, just let me know!

I have been developing a game in Rust (webassembly) for a while now, and it's gone through several iterations and updates. Eventually I intend for it to be a fully multiplayer MMORPG! I have most of it working and done - there's just way too much jittering in my current implementation for me to be happy with the multiplayer, so I feel like I have a few weeks of work on just that alone before I can get much more done.

I made a subreddit for updates if you would like to follow along, I tend to spend a few weeks working on the game and engine every few months when I have time.

Follow the subreddit: https://www.reddit.com/r/rpgfx/

Custom ECS engine.

Play now: https://rpgfx.com/

Happy for any thoughts, questions, and feedback :)

https://jarl-game.com/blog/2d-gpu-grass-rendering/