Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Any plans for scripting/logic other than Rust? I can't imagine it working well to quickly iterative on gameplay


Rust isn't inherently slow to iterate, its just easy to write code that compiles slowly if you aren't careful. One of Bevy's primary focuses is to have fast iterative compile times. Changes to our examples can be recompiled in ~0.8-3 seconds (according to your hardware, os, and linker). We have a "fast compiles" configuration that works quite well.

First we do plan on exposing hooks to allow scripting languages to be plugged in to Bevy. We actually already have a pull request out for that.

However my default answer to the scripting question is that it is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

In the near future 3rd party Bevy scripting plugins will start popping up, but I doubt I will ever officially endorse them.


I also think on of the major selling points of Bevy is that "bevy game devs" are actually "bevy engine devs" ... they just don't know it yet. Bevy is implemented using the same plugin interface that games use, which blurs the line between engine code and game code.

Adding scripting languages into the mix removes this benefit and cuts down on the number of people capable of contributing back to the engine.


what about using rust for scripting but compiled to wasm, so beavy can (hot-re)load wasm modules?


thats a scenario im definitely thinking about :)


Can you easily serialize/deserialize the game state with your ECS system? I haven't looked closely at it.

If it were possible, your iteration times could be ridiculously low. Play the game until the bossfight you're iterating on. Dump it out to disk. Edit the code, recompile and run from saved state in a couple of seconds? That sounds amazing.

Unity has pretty good edit and continue for simple stuff, but it quickly falls apart once you start doing non trivial things.


Not sure about bevy specifically, but I know the rapier physics engine (which integrates with bevy) can serialize all of the physics state.

Plus, in Rust, if you mark types as Serialize you can serialize nearly anything you want. And it seems like Bevy makes full use of the powerful Rust type system.

So I’d guess “yes, you can probably easily serialize the game state in most cases”.


To do edit and continue with it you're really going to want full serialization, so if you eg model events as a closure instead of plain data, you're toast (coming from an outsider's perspective).

If the base engine supplies you with full serialization support for the inbuilt features and a list of rules to follow to maintain it, you're golden.


Wow you've got some good engine design sense. Have you by chance shipped a commercial game before? Most open source engines lak such concrete experience and sense.


The developers of EVE Online had this same thought, about C++, so they used python as the gameplay scripting language. A few years later faced with unsolveable performance issues with large scale battles they had to resort to slowing down time by a factor of 4, during large scale battles.

Just a single anecdote but can be important to keep in mind. As well, some types of scripting languages can have their own productivity problems as projects get large. Lack of types making code hard to follow, bugs harder to track down, refactors riskier etc.


The difference is that Rust is still quite far to support the dynamic capabilities and code reloading of C++.


People have been doing hot code reloading with rust for years now. I'm not sure what are all the pros/cons and limitations with each today. I wouldn't think there are fundamental differences.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: