4 ms·
The author has one major issue with Rust in gamedev: they can't easily try out new game feature ideas or gameplay tweaks by writing quick and dirty code. Such
by pornel 2y ago
The author has one major issue with Rust in gamedev: they can't easily try out new game feature ideas or gameplay tweaks by writing quick and dirty code.
Such unfinished code can be obviously buggy and unsafe, but in game dev it matters more to have short feedback loop to try how things feel, than to have a perfectly correct code all the time.
Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
This is a substantially different situation from other domains like application and services development, where it's easier to plan what you're going to implement, correctness is more important, and you don't need to try out 20 different JSON parsers to see which one has the most satisfying feel.
- spoiler 2y agoDisclaimer: never actually shipped a game. I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major "downside" you need to account for is that the type system will try to prote you from crashes. Which can be a bit of a chore since youknow it won't crash with the values you've given it. But if you're comfortable with .unwrap and the occasional unsafe while prototyping, it's honestly fine (at least within Bevy). Alternatively, they could try "scripting" behaviour first before implementing it in Rust, although from what I understand bevy's scripting support (I don't think it's explicitly supported, but bevy is very extensible) is still very early in development
- pornel 2y agoECS is like a whole another language on top of Rust, and it is dynamically typed. If you add a scripting language and blueprints, you're shortening the feedback cycles by using Rust less. I like Bevy, but it seems like Rust currently is much better suited for making game engines than the games themselves. Some "RustScript" is needed.
- kaoD 2y ago> ECS is like a whole another language on top of Rust, and it is dynamically typed. Can you elaborate? Or did you mean dynamically dispatched?
- pornel 2y ago1. You dynamically add components to any entity, so entities don't have a static type. Semantically they're comparable to a JavaScript Object where you can add and remove properties at will, rather than being structs or class instances with a closed set of fields. 2. Bevy's entity references are generational IDs, without static lifetime guarantees (and restrictions) of Rust's references.
- CaptainOfCoit 2y ago> so entities don't have a static type. They do, they're `Entity`, always. > where you can add and remove properties at will I don't think this is true for either `Component` or `Entity` in Bevy. You set what fields a `Component` has when writing the code, then it remains so during the runtime. There is no dynamically adding/removing fields at runtime, at least yet. What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime, is that maybe where the confusion comes in?
- spoiler 2y agoI think they used it more as an analogy: components fill a similar role as properties do in JavaScript.
- CaptainOfCoit 2y agoBut that's not really true either, is it? You don't query properties in JavaScript, at best you query for Objects of a certain shape/name. You don't encapsulate data in properties so one object has many different behavior based on those, you either split the Object into many different ones and have one parent, or you mix the behavior into the same Object.
- binary132 2y agoSomething wrong with Lua? ;)
- Aeolos 2y agoC++ doesn't do quick and dirty either. That's why experienced game developers combine a core engine written in a high-performance language (C++, Rust, C#), with a scripting language (Lua, Python, hand-rolled). That approach gives you the best of both worlds: high-performance core with high-velocity iterations for gameplay. Don't use Rust or C++ for scripting... madness lies that way.
- pjmlp 2y agoExcept hot code reloading and interpreters is something that C++ devs can reach for, and Rust ones not, at least for the foreseable future.
- bendhoefs 2y agoWhat do you mean by this? Rust has multiple game engines that support hot reloading and/ or scripting. https://fyrox-book.github.io/beginning/hot_reloading.html https://fyrox-book.github.io/beginning/hot_reloading.html https://github.com/jarkonik/bevy_scriptum https://github.com/jarkonik/bevy_scriptum
- pjmlp 2y agoThis the bare minimum, https://liveplusplus.tech/ https://liveplusplus.tech/ Also supports is kind of relative, "CHR is very new and experimental feature of the engine, it is based on wildly unsafe functionality which could result in memory corruption, subtle bugs, etc."
- bendhoefs 2y agoWhy is that the bare minimum? I also think that doc page is a little old. The feature is over 2 years old now and hot reloading is inherently "unsafe" in any compiled language. It's just letting you know that Rust's safety guarantees might go out the window if there are bugs in the code that handles hot-reloading.
- 2y ago
- ben-schaaf 2y ago> Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code. The problem might just be an aversion to using quick and dirty solutions. Rust does a good job of making it feel wrong to write code that's not production ready, but there's nothing stopping you from using unsafe wherever you want.