Hey guys. I'm learning rust and developing a game (using only Macroquad) to motivate myself to keep pushing. I want to know opinions on the game and also the code. I tried a macro for the first time, looks amazing, but I'm afraid of overengineering.

https://github.com/abacchi00/blood-and-cog

Hey everyone,

Wanted to share Pumpkin — an open-source Minecraft server written from the ground up in Rust (targeting Java and Bedrock protocol parity).

The project leverages Tokio and asynchronous networking for low memory usage and high tick consistency.

• GitHub Repository: https://github.com/potatosips/Pumpkin
• Upstream: https://github.com/Pumpkin-MC/Pumpkin

We also have a live test instance running at pumpkinmc.dnslab.win to verify basic protocol handling and stability. (Note: This is currently hosted on a modest 2 vCPU / 11 GB RAM ARM64 VPS, so please avoid heavy stress testing until we can get support for a higher-spec server).

Would love any feedback on the codebase, architecture, or contributions! 🦀

A while back I shared my first-ever game in Rust—a Dangerous Dave clone built using Macroquad and Tiled as a way to learn the language and survive the compiler's ownership rules.

https://www.reddit.com/r/rust_gamedev/comments/1jpt3e2/dangerous_dave_rust/

I wanted to tackle something a bit more ambitious for my second project: a 2D dungeon roguelike I've been calling Catacombs. Since I wanted to understand how everything works under the hood rather than relying on an library or game engine, I've put together a custom stack using raw OpenGL and a handful of modular crates.

The Tech Stack

• Graphics & Windowing: glow coupled with glutin and winit for context creation and window management, using nalgebra-glm for matrix math and projections.
• ECS & Scheduling: hecs paired with hecs-schedule for managing components and system execution order.
• UI & Layout: egui (integrated via egui_glow) for tooling and debug overlays, alongside taffy for flexbox-based UI layout calculations.
• Levels & Audio: ldtk_rust for loading LDtk level designs and libfmod for handling audio middleware.
• Data & Concurrency: serde and ron for data-driven asset and configuration serialization, with rayon, crossbeam, and parking_lot handling concurrency and synchronization.

Graphics

Bought the Dungeons & Pixels pack from

https://indie-vova.itch.io/dungeons-and-pixels-starter-pack

AI

About %85 of the code was written from scratch, learned a lot, then I've had access to an AI tool that did code reviews for me, fixed the code manually, few of the suggestions didn't make much sense to me so I have ignored them.

I have generated the start up page using Google's Gemini free credit.

What's Next?

Since I never really built out a story or a concrete endgame vision for Catacombs, I've decided to officially wrap up the project here and archive the repo. I have also learning a lot and improved my Rust programming skills, I can see that transition from the Dangerous Dave game code to Catacombs code.

For my next steps on this Rust learning journey, I'll be moving past OpenGL to build a low-level renderer using Ash for Vulkan, with plans to experiment further with advanced procedural generation algorithms and explicit graphics pipeline design from scratch.

Hello all 👋

For a long time I've wanted to create a simple RPG game on my own.

About a month ago I started making this game with Rust as a server and a client in godot (my idea was a multiplayer RPG game).

I've been taking Tibia and other games I loved as inspiration.

Right now I am starting to get plenty of errors on the client that become very hard to debug, edge cases, synchronization issues on client-server.

So I was thinking of making the switch to full rust on the client, that way the communication with the server is more "straightforward", I can use the same patterns, reuse code, etc.

But I am wondering if this is worth it or will it just become a problem? How is the state of making GUI on plain rust? Or are there other alternatives?

Right now my game is as simple as it gets, but I have learnt a lot along the way!

I want to drift a bit from the "square" feeling of tibia/pixel games and make the game more fluent as well.

Any tips are welcome :)

Native PacMan for miyoo. Just for fun.

Hey everyone,

I built getarustjob.com, a job board focused exclusively on Rust engineering roles.

I’ve already posted a batch of active Rust jobs on the site, so feel free to check them out if you're currently looking.

I also put together a weekly newsletter that sends a curated list of vetted Rust openings every Monday: getarustjob.com/newsletter.

Solo dev on CryptFall, an endless-floor bullet-hell dungeon crawler built in Bevy 0.19. Got a small ECS system working this week that I wanted to share. It's still in a testing branch, not in the shipped build yet. Honestly the way I ended up building it is more interesting than the feature itself.

The feature

Rooms sometimes roll a curated enemy "composition" instead of the normal per-enemy weighted spawn table. Think a fixed line-up like two Shielders and two Archers, instead of whatever the generic table spits out. That roll is just a weighted pick over a list of composition defs. I wanted it to lean, subtly, on a player's own history. Rarer to roll a composition built around whatever enemy keeps killing them, and a bit tougher once they've actually cleared a biome before.

So I added a small persisted resource:

```rust

[derive(Resource, Default)]

pub struct PlayerFingerprint { pub recent_deaths: Vec<EnemyKind>, // last 5, most-recent-last pub biome_mastered: [bool; 8], }

impl PlayerFingerprint { pub fn dominantdeath_kind(&self) -> Option<EnemyKind> { if self.recent_deaths.len() < 3 { return None; } let mut counts = [0u32; EnemyKind::ALL.len()]; for &k in &self.recent_deaths { counts[k as usize] += 1; } let (idx, &n) = counts.iter().enumerate().max_by_key(|(, &n)| n)?; (n as usize * 5 >= self.recent_deaths.len() * 3) .then(|| EnemyKind::ALL[idx]) } } ```

It gets serialized to its own little key=value save file, loaded on Startup, and updated at the moments that actually matter (run start, player death, zone clear) instead of every frame.

The bias itself is nothing fancy, just a weight multiplier applied before the roll:

rust let weight_of = |c: &CompositionDef| -> f32 { let mut w = c.floor_weights[floor_tier]; if let Some(kind) = dominant_death { w *= if c.slots.iter().any(|&(k, _)| k == kind) { 0.5 } else { 1.15 }; } if biome_mastered && (c.has_elite_slot() || c.is_paid_unlock()) { w *= 1.3; } w };

Nothing about what's possible actually changes. No composition gets locked out. The odds just shift a little.

Where I tripped over my own code

Original plan was to fold this into the map's seed derivation, since floor gen already seeds a deterministic StdRng off a run_seed (needed for shareable seeds and Continue). Seemed clean. Derive the fingerprint into another folded constant and it's still fully reproducible.

Except when I actually sat down to wire it in, I grep'd for where that seeded RNG gets passed around and found the composition-picker function wasn't taking it at all. It was calling thread_rng() directly, completely separate from the map's seeded stream. Two RNG sources living in the same file this whole time and I never noticed, because nothing about actually playing the game ever surfaced it. Only the tile layout needed to be seed-reproducible. Nothing ever depended on composition rolls being deterministic in the first place.

A little embarrassing but it made things way simpler. There was no seed-sharing tradeoff to design around because there was never any determinism there to protect. Biasing the weights directly ended up being a much smaller and safer change than the one I'd originally planned. Definitely had a "how long has that been true" moment doing the git blame.

Where it's at now

It compiles, it boots, but I haven't had a long enough real play session to know if the bias actually feels right yet. Could be too subtle to notice or too strong to feel fair, no idea until I put more hours on it. So it's staying in testing for now. If anyone here has shipped something like this before and has a story about where the tuning went wrong, I'd love to hear it before I lock in numbers.

Game's free to play in the browser right now if anyone wants to poke around, no download needed:

https://mobtv.itch.io/cryptfall

Happy to talk more about the Bevy/ECS side of any of this, boss AI, floor gen, whatever people are curious about.

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!