Live data from Hacker News

Bevy Isn't Ready for Large-Scale Game Projects Yet – A Novice's Experience

oneirical.github.io

1–10 of 11 posts

Re: Bevy Isn't Ready for Large-Scale Game Projects Yet – A Novice's Experience

#2
There has been a lot of hype surrounding Bevy. I fell for the meme and have been using it for approximately the last 6 months.

My personal opinion of it has wildly alternated between "the piece of technology that will bring humanity into the Fully Automated Luxury Gay Space Communism era" to "an unspeakable tangle of spaghetti which has imprisoned my hopes and dreams".

Now, it stands firmly at some place in between.

Re: Bevy Isn't Ready for Large-Scale Game Projects Yet – A Novice's Experience

#5
Great article, loved your style of writing! I'm not sure how they usually do things in the ECS space, but I think the natural thing to do for the spell megafunction is to split it up into smaller systems. The original system just slaps a spell component onto the entity that affects it and after that there are the spell systems that check for the tagged entities. Now the queries in the megafunction are greatly simplified. Also the spell queries are now more tightly defined

Re: Bevy Isn't Ready for Large-Scale Game Projects Yet – A Novice's Experience

#7

You had me at neuroevolution, that project looks awesome, can you please include a license?

Replying to myself and thinking out loud, one thing really saved me a ton of hassle in a recent project was leaning on DataFrames because they align really well with SQL tables and also can save you from needing to make new data structures;

especially in Rust, making new “classes” can be tremendously time consuming, reusing Series with a different dtype might save bevy users from needing to impl X for Y a billion different times to make a new struct Y. Series already has implementations for whatever is needed.

It’s too bad Polars separates Row from Series so hard in the type system, because this is the true 100x gain of Pandas: evading the OOP paradigm with thing_ser and things_df instead of class Thing and Tuple[Thing, …]

I.E. instead of forcing Bevy devs to pass around these heinous Query, Query, Query signatures and remember the order, maybe a “creatures_df” with appropriate columns would be more fun to work with because it’s a bit higher level but still performant (and possibly less code to maintain by pushing work onto Polars)

More focus on polars row feature imho is needed for the rust community to thrive, it’s a backwater in that workspace which could become a saving grace

Edit: also, an easy compilation gain is to… # Parallelize Rustc: https://blog.rust-lang.org/2023/11/09/parallel-rustc.html

Makefile:

RUSTFLAGS_VALUES = "-Z threads=8"

test: test-stable

.PHONY: test-nightly test-nightly: RUSTFLAGS=$(RUSTFLAGS_VALUES) cargo +nightly nextest run

.PHONY: test-docs test-docs: RUSTFLAGS=$(RUSTFLAGS_VALUES) cargo +nightly test --doc

.PHONY: test-stable test-stable: cargo test

cfg: RUSTFLAGS=$(RUSTFLAGS_VALUES) cargo +nightly -Z unstable-options rustc --print cfg

# Run tests and benchmarks every time a file changes

watch-nightly: RUSTFLAGS=$(RUSTFLAGS_VALUES) cargo +nightly watch -x "nextest run" -x "test --doc"

Re: Bevy Isn't Ready for Large-Scale Game Projects Yet – A Novice's Experience

#10
post #5

Great article, loved your style of writing! I'm not sure how they usually do things in the ECS space, but I think the natural thing to do for the spell megafunction is to split it up into smaller systems. The original system just slaps a spell component onto the entity that affects it and after that there are the spell systems that check for the tagged entities. Now the queries in the megafunction are greatly simplif…

I am thinking of implementing your suggestion in the form of Events directing and activating smaller systems! If I stick with Bevy, that is.
Post reply on HN