rusty_engine VS zemeroth

Rusty Engine is a very simplified wrapper over Bevy made by one of its contributors which allows you to basically get straight into game creation using code without having to learn proper ECS patterns and Bevy systems.

One of the guys who contributed to Bevy made a wrapper around it called Rusty Engine. It vastly simplifies what you need to do to bootstrap a game with Bevy while introducing you more gently to the concepts you will need to learn when transitioning to a full Bevy project.

Ultimate Rust 2 uses Rusty Engine for the game prototype project(s) at the end of the course. Rusty Engine was created specifically for the course. More info about Rusty engine can be found on the GitHub repository, linked above.

If you are the kind of person who wants to learn Rust first, and then Bevy later, then I suggest starting with Rusty Engine (full disclosure, I'm it's author). It is a simplification layer around Bevy that removes almost all game engine concepts, so you can practice out your beginner Rust skills making simple game prototypes.

- Rusty Engine doesn't support drawing primitive lines, polygons, or circles. Bevy 0.8 added the ability to draw polygons and circles, so I'm planning to add that "soon", but Bevy does not (yet) support drawing lines, so that is still up in the air. Given the OP's stated desires, this may eliminate the current version of Rusty Engine from consideration.

Check this one out: https://github.com/CleanCut/rusty_engine

Update: I couldn't stop thinking about this 👆🏻, so after updating to Bevy 0.6, I circled back and tried to make Game generic over the game state struct...and it worked this time! I don't know if Bevy 0.6 did something to make it easier, or if I just smartened up sufficiently, but there is no longer any need for the macro call. 🎉 The change will be in Rusty Engine 4.0, which I will release as soon as I figure out what to do about bevy_prototype_debug_lines not having an upstream Bevy 0.6-compatible release.

i've used both in zemeroth: i migrated it from ggez to macroquad mostly because ggez at that time didn't support android and web targets. but i'd say that the main difference is tech stacks they're using: while ggez extensively reuses the existing rust gamedev ecosystem (winit, wgpu, rodio, etc), mq was written mostly on top of minimalist or its own specialized libraries (see miniquad).

nope, /u/not-fl3 is the author. i'm just using it in my zemeroth.

Trying to get back to the development of my turn-based game Zemeroth: going to finish the first iteration of settings screen for configuring widgets' size and screen offset, and get back to writing devlogs for the v0.7 release.

Depends on CI system you prefer. Here's Zemeroth's Github Actions release config for example: https://github.com/ozkriff/zemeroth/blob/master/.github/workflows/release.yml

Tutorial is based on a public test of zemeroth game.

zemeroth: a 2D game with desktop versions, but also a wasm online version

Oh, I was really waiting for this episode as my Zemeroth game shares a lot of history with mini~ and macroquad. Here're some of my thoughts.