James Liu

> Essentially, it's a builder pattern for interpolation curves. It would look like so: Seems good, the referenced [Curve PR in the RFC](https://github.com/bevyengine/bevy/pull/1837) could really use a better builder-like public...

Yes, this can be experimented with externally, and I am via https://github.com/james7132/bevy_prototype_particles (though that is slowly getting out of date with the rendering implementation), but ultimately I want this to...

IMO anything that would introduce a new crate or engine capability (looking at animation here), should probably fit into the RFC category and go through a more rigorous design process,...

> Another quick thought: as this is pitched as a way to resolve "scaling issues" and it does come with a number of tradeoffs (which are already called out), we...

I'm generally behind the goals here, but this only covers how we're going to seed new PRNGs, not how said PRNGs are stored, managed, and advanced. Things like query iteration...

> I'm not initially sure it makes sense to try to build determinism into the engine itself, if it is even possible. It seems more like something one has to...

Almost completely revised the RFC end to end: - Removed the mention of animation graph and mixing entirely, going to have a separate RFC for this - Dropped the idea...

Static and standard lasers should be doable via just stretched SpriteRenderers on pooled laser objects. However curved seems to pose a challenge as testing has shown Line Renderers to both...

This has several components that need to be implemented: * Adding an additional scale factor into rendering. * Scaling the collision boundaries for each bullet. The latter seems to be...

Under the hood, we use a two pass collision algorithm: an initial AABB check against colliders, and then call Physics2D.CircleCastNonAlloc to do fine grain collision detection. While computing AABBs for...