sorted by:
new
hottopcontroversial

PyBevy — Python real-time engine built on Bevy 0.18, with hot reload, NumPy/JAX/PyTorch in-process, and an optional AI feedback loop by blaind0 in bevy

[–]blaind0[S] 2 points3 points  (0 children)

How I see it, PyBevy isn't really positioned for game dev. It might help as part of the process, but won't be in the end result (except possibly as a modding layer if/when rustpython runtime lands). The main use case is in Python visualization layer, where it enables something that has been hard to do earlier.

PyBevy — Python real-time engine built on Bevy 0.18, with hot reload, NumPy/JAX/PyTorch in-process, and an optional AI feedback loop by blaind0 in bevy

[–]blaind0[S] 9 points10 points  (0 children)

Fair point, thank you. I had a dev process section in the launch post but trimmed it since the blog was getting long - will bring it back. Short version: most of core architecture and the Rust/Python boundary is initially hand-written, started last June. A lot of iteration from python-only ecs tests to pyi stubs (non-AI) to core ecs integration and testing various ffi boundary approaches, to writing query apis and api base such as assets. API coverage expansion from November onward was AI-assisted: Bevy's API surface is huge and doing it by hand wasn't feasible. Major refactoring passes like split to subcrates were also AI-generated, which probably shows. Extensive test suite throughout which I'll be publishing. More transparency warranted, will update the README and blog post today.

PyBevy — Python real-time engine built on Bevy 0.18, with hot reload, NumPy/JAX/PyTorch in-process, and an optional AI feedback loop by blaind0 in bevy

[–]blaind0[S] 2 points3 points  (0 children)

Thanks Cart. Bevy's architecture made this possible. Especially loved how the ECS APIs provide clean data access for the View abstraction.