• brucethemoose@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    20 hours ago

    I great example I saw is a dev who was building on a Rust game (with the Bevy engine), and switched to Unity.

    https://deadmoney.gg/news/articles/migrating-away-from-rust

    Collaboration - I started this project with my brother. While he’s sharp and eager, he’s new to coding. Onboarding him directly into game dev while simultaneously navigating Rust’s unique aspects proved challenging. We found ourselves with a steeper learning curve that slowed his ability to contribute effectively to gameplay logic.

    Abstraction - While my initial motivation was the enjoyment of Rust, the project’s bottleneck increasingly became the rapid iteration of higher-level gameplay mechanics. As the codebase grew, we found that translating gameplay ideas into code was less direct than we hoped. Rust’s (powerful) low-level focus didn’t always lend itself to a flexible high-level scripting style needed for rapid prototyping within our specific gameplay architecture. I found that my motivation to build and ship fun gameplay was stronger than my desire to build with Rust.

    Migration - Bevy is young and changes quickly. Each update brought with it incredible features, but also a substantial amount of API thrash. As the project grew in size, the burden of update migration also grew. Minor regressions were common in core Bevy systems (such as sprite rendering), and these led to moments of significant friction and unexpected debugging effort. This came to a head on one specific day where I was frustrated with a sprite rendering issue that had emerged in a new release. Blake had run into the same problem at the same time and our shared frustration boiled over into a kind of table flip moment. He turned to me and said something along the lines of “this shouldn’t happen, this kind of thing should just be solved” and that triggered the conversation that led to a re-evaluation. The point isn’t that specific sprite problem, but that because all systems in Bevy are open to tinkering and improvement, all systems were potentially subject to regressions.

    Learning - Over the past year my workflow has changed immensely, and I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. While Bevy and Rust evolve rapidly - which is exciting and motivating - the pace means AI knowledge lags behind, reducing the efficiency gains I have come to expect from AI assisted development. This could change with the introduction of more modern tool-enabled models, but I found it to be a distraction and an unexpected additional cost.

    Modding - Modding means a lot to me. I got my start in the industry as a modder and I want my game to be highly moddable. Over time, as I learned more about how to realize this goal, I came to understand many inherent limitations in Rust and Bevy that would make the task more difficult. Lack of a clear solution to scripting and an unstable ABI (application binary interface) raised concerns. I am not an expert in this area, perhaps these are all easily surmounted. I can only say that I did not find a path (after much searching) that I felt confident trusting.

    It sounds like Rust (game engines, and more) could use a higher level scripting language, or integrate an existing one, I guess.

    • dejected_warp_core@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      13 hours ago

      Rust […] could use a higher level scripting language, or integrate an existing one, I guess.

      One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it’s tough to implement a macro without side effects and enough compile-time feedback that you’d expect from a DSL.

      Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.

    • Croquette@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      ·
      20 hours ago

      I interface with low level communication protocols, mostly uart, so it fits my use case. But it is nice to see the hurdles people encounters. It tells a lot about the language.

      • brucethemoose@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        20 hours ago

        Yeah. I wasn’t trying to imply it’s a bad language at all; it just fits certain use cases. They are complex, like people.

        Still, it seems like it’d be cool for engine work, with C# or maybe a subset of typed Python as a scripting language.