4 ms·

Thanks for posting - hobby game dev here, know just enough to be dangerous.. if I was going to start a new project, it would be in your engine, seems like it sp

by sdwr 3y ago

Thanks for posting - hobby game dev here, know just enough to be dangerous.. if I was going to start a new project, it would be in your engine, seems like it splits the diff between Love + Godot, more robust than Love, not as geared towards novices as Godot. How opinionated is bevy? Have you ever had to make tradeoffs between features and developer accessibility? What is the "ideal" project to use bevy for right now?

_cart 3y ago
Bevy tries to have its cake and eat it too. We have a large, opinionated featureset (ex: how should rendering code look, high level materials, sprites, meshes, animation, scenes, etc) where everything works nicely together. However we are extremely modular to the point that you can do pretty much anything in Bevy. People build their own renderers, do command line only terminal UIs, custom UI systems, etc etc. We make tradeoffs all the time. We prioritize accessibility / developer UX to a pretty high degree. But this very rarely means cutting features. The hard part is generally _how_ we expose a feature, not _if_. "What is the "ideal" project to use bevy for right now?" Bevy is well suited to many project types. The biggest missing piece is a lack of a visual editor (we are working on this, and while you wait you can use programs like Blender or ldtk to compose your scenes). I'd say the ideal project is (1) Small-to-medium-sized in scope, to help mitigate the risk of using a younger engine (2) doesn't need a full Bevy Editor / can get away with code driven or external-editor-driven scenes.
alice-i-cecile 3y ago
Yeah, that's not a bad way to describe its positioning. Currently not a lot of batteries included: the experience is much more like "writing a web app using a framework" than it is "boot up RPG Maker". Generally speaking, Bevy is extremely flexible, with pretty generous defaults for enabled features to let beginners avoid worrying about toggling feature flags and controlling plugins. In game engine development, features are typically strictly additive, so features vs developer accessibility isn't a great way to frame the tradeoff. Instead, we often push work into the third-party plugin ecosystem to ease maintenance burden or let it mature. As for the ideal project, I would either say "solo programmer who wants to learn Rust and game dev for fun", or "small, serious team looking to build an unusual systems-heavy game".

by sdwr 3y ago

_cart 3y ago

Bevy tries to have its cake and eat it too. We have a large, opinionated featureset (ex: how should rendering code look, high level materials, sprites, meshes, animation, scenes, etc) where everything works nicely together. However we are extremely modular to the point that you can do pretty much anything in Bevy. People build their own renderers, do command line only terminal UIs, custom UI systems, etc etc. We make tradeoffs all the time. We prioritize accessibility / developer UX to a pretty high degree. But this very rarely means cutting features. The hard part is generally _how_ we expose a feature, not _if_. "What is the "ideal" project to use bevy for right now?" Bevy is well suited to many project types. The biggest missing piece is a lack of a visual editor (we are working on this, and while you wait you can use programs like Blender or ldtk to compose your scenes). I'd say the ideal project is (1) Small-to-medium-sized in scope, to help mitigate the risk of using a younger engine (2) doesn't need a full Bevy Editor / can get away with code driven or external-editor-driven scenes.

alice-i-cecile 3y ago

Yeah, that's not a bad way to describe its positioning. Currently not a lot of batteries included: the experience is much more like "writing a web app using a framework" than it is "boot up RPG Maker". Generally speaking, Bevy is extremely flexible, with pretty generous defaults for enabled features to let beginners avoid worrying about toggling feature flags and controlling plugins. In game engine development, features are typically strictly additive, so features vs developer accessibility isn't a great way to frame the tradeoff. Instead, we often push work into the third-party plugin ecosystem to ease maintenance burden or let it mature. As for the ideal project, I would either say "solo programmer who wants to learn Rust and game dev for fun", or "small, serious team looking to build an unusual systems-heavy game".