It's been another week of Arsenal development and we've made more progress!
This week we worked primarily on establishing some benchmarks as a result of the findings and discussion we started the week before. The result of our effort was a new git repo, bevy_benchmark_games, that now houses our first two benchmark games.
These benchmark games are "headless" games, which can run without graphics and user input in order to test the core ECS and systems of the Bevy engine without messing up measurements with rendering times or other inconsistencies. The purpose of these games is to have the general "shape" of a real game, containing all of the basic systems to make a game actually "work" while still being fully independent of graphics and user controls.
This is what our "asteroids" benchmark looks like when run with graphics:
It has asteroids, bullets, and a blue "ship" in the center that gets respawned instantly every time an asteroid hits it. It isn't pretty, but it doesn't need to be, it just needs to act like a game.
After building the benchmark game, we needed a way to actually collect metrics on how fast it was running. The benchmark will setup the game world, run the game for 300 frames and record: how long that took, how many CPU cycles were spent, and how many CPU instructions were executed. Then we do this 200 times. With the data collected, we then plot the data and compare it to the last execution times:
The blue section indicates the stats for the most recent run of the program, and the red section indicates the stats for the previous run. The graph includes the average for each value and shows you the percentage difference between the previous and current runs.
Next Steps
These benchmarks will hopefully help us evaluate the differences in Bevy performance due to our changes. With that done, we now continue on the development of our scripting solution.
In week 1 we were able to establish a prototype for dynamic systems in Bevy, now the next step is dynamic components. From my initial look through the Bevy code, dynamic components should be easy, and Bevy is already nearly doing what we need it to. After some discussion on the Rust forum I was also led to a way to improve the current design for dynamic systems to make it a little bit safer and less likely to have memory soundness issues.
I think I should be able to finish off the dynamic components and systems before the end of the week. Our changes will likely not be reviewed and merged by then as @cart has a lot on his plate with Bevy development and he is wisely focusing and prioritizing based on what is most important for Bevy.
Still, this will not halt our development! We can easily keep our own fork of Bevy for all of our changes until each of our changes is merged. Because Arsenal is delivered as a Blender plugin and not as a Rust library, it will be trivial for us to build Arsenal with any version or fork of Bevy necessary so that we can continue the development of our end, while @cart focuses on building out and improving the Bevy engine.
As soon as we finish with dynamic components and systems, we can start putting together the first prototype of our scripting integration. A lot will go into this scripting integration and we'll have to do some experimentation to find out how to best organize the system, but we've got a plan in mind and I can't wait to try it out!
I'm very excited for another week of Arsenal development. As we make progress I will try to post updates every week on what we accomplished. Check the Arsenal channel on our website every Monday evening to stay tuned. Praise the Lord!