Using game engines (Bevy) for scientific simulations?
Out with the old
Running simulations is part and parcel of being a scientist.
Most simulations are simply numerical computations; run it once and plot some results. For this, scientists have long relied on Python, MATLAB, R, Julia, or Fortran, C, and C++ for the more computationally expensive stuff.
These have served me well too, and if I require visualizations beyond simple plots, they typically covers them too (e.g., left video below).
Recently, I’ve also been experimenting with Blender as a visualization tool. Thanks to its integration with Python, one can perform all their computations in Python, and simply “plot” them in Blender1.
1 See also this post where I plotted our local stellar neighborhood with Blender.
Of course, even without Python, Blender is quite powerful in simulating physical systems, especially with geometry nodes. Combined with its beautiful rendering capabilities with Cycles, it is great for scientific visualization (e.g., right video above).
Still, despite my love for Blender, I find the hybrid Python + Blender workflow to be a little clunky, and I’ve never really been fond of Python for running simulation either.
So what are the alternatives2?
Videos games are some of the most complex world simulations we have. Complex system scientists run cellular automata to study the science of complexity, all while there’s games like Dwarf Fortress, which is arguably the most complex cellular automaton-type simulation we have.
So why not use a game engine?
For one, I still have the same problem with the Python + Blender workflow, except this time it’s C# + Unity, C++ + Unreal, or GDScript + Godot.
Thankfully though, there’s Bevy.
In with the new: Bevy
Released in 2020, Bevy is a relatively new free and open source game engine in Rust. It is also quite experimental, having breaking changes every few releases. Yet, it has produced fantastic and beautiful games like Tiny Glade, Fields of Aaru, Times of Progress, and many more.
More importantly for me, unlike other game engines, Bevy require no GUI or visual editor3. This means that the workflow is similar to traditional computations that scientists are familiar with, where everything is just code.
3 Though it is a planned feature, and there are already alternatives like Jackdaw.
In addition to its speed, Rust is also a joy to write in with type and memory safeties, and one can achieve beautiful renders and visualizations thanks to Bevy’s ray-tracer Solari.
Interactivity
You might have already noticed from the video above, being a game engine, the user can interact with their simulation freely in real-time. This is especially great when exploring the system that you are simulating.
In fact, just imagine combining any feature of a video game into your scientific simulation:
- Freely changing the initial conditions
- Freely changing the position or properties of an agent that you are simulating live
- Saving and loading different states of the simulation
- Seeing the plots of some measures live
I have always dreamed of a more efficient and convenient “UX” for scientific computational research.
How many hundreds of times have you gone through the same old boring workflow of writing the same templates of codes, looping over multiple initial conditions, keeping track of quantities that you’re concerned about, running them, plotting the results, rinse and repeat4?
4 I’ve grown quite weary of writing the thousandth quantum system in Python/Julia that I’m genuinely making (albeit slowly) an interactive general open quantum system builder in Bevy.
And consider all the times in a group meeting where all we can show is some pre-made plots, and all we can say is “I’ll go back and check” when asked about what would happen if we changed something in our simulation?
By spending some extra time and effort on coding upfront, we can put all of this behind us5.
5 If you are doing serious investigations into a particular system rather than just one-off numerical computations, it’s probably worth it to spend the time and effort.
ECS, the natural ABM?
The bus route and flocking simulations above are what’s called an agent-based model (ABM), where a collection of autonomous agents or entities have certain behaviors, and react with their environment and one another under some rules6.
6 Agents.jl has a table of comparison between some popular ABM frameworks.
If you have even just one inkling of what a video game is, this sounds rather like one doesn’t it?
Almost all games employ some version of this, and games that exploit this feature into gameplay are often called systemic games7, where almost all systems inside the game interacts with one another, either to create a simulation, or to generate emergent gameplay.
7 This video by Game Maker’s Toolkit is a nice summary of systemic games.
This kind of games are especially suitable for a kind of programming paradigm called entity component system (ECS), that Bevy is based on.
Let’s look at the flocking simulation as an example.
| Flocking simulation | ABM (object-oriented) | ECS (data-oriented) |
|---|---|---|
| A bird | Agent object | Entity + Component |
| Bird’s position & velocity | State variables of agent object | Component data |
| Boid behaviors (separation, alignment, cohesion) | Agent object’s methods | System functions acting on the components of entities |
| Simulation progression | Loop through each agent | World tick |
In the traditional way to implement ABM (object-oriented), each agent carries its own states and update functions, i.e., each agent “knows what to do” in the simulation like an actual bird.
On the other hand, in ECS (data-oriented/driven), an agent is an entity that is assigned some components, and is defined/identified by what components it is assigned. What we call a “bird” is just an ID attached with the components of position and velocity.
Perhaps one could frame this philosophically: In the data-oriented ECS, a bird is only considered a bird if it has a position and velocity, while in the object-oriented ABM, a bird is a bird by definition.
Furthermore, the ECS bird has to rely on the “world” or system to update its components, i.e., each agent “does not know what to do” in the simulation. The “world” will look at all entities who has certain components and whose components fulfill some conditions, and updates them accordingly.
This is like if reality suddenly dictates that “everyone who wears glasses and live in Singapore are now taller by 1cm”, and updates them accordingly (ECS), as compared to each human having a secret “power” in them that once these conditions are fulfilled, will grow taller by 1cm (ABM).
This somewhat less intuitive way of doing things turns out to have a lot of advantages in terms of scalability, parallelism, modularity, and performance (Tasnim and Zhao 2026), and is becoming more and more popular.
No limits
Finally, as Rust is a general-purpose programming language, there really isn’t any limits to the kind of simulations you can run, especially with its huge ecosystem of Crates.
There’s ndarray for high-dimensional arrays, nalgebra or faer for linear algebra, burn or candle for machine learning, geo for geospatial computing, and of course polars, the superfast dataframe that is supplanting the popular pandas in Python, thanks to tools like pyo3 and maturin that allow the calling of Rust libraries in Python.
You will write your scientific computations in Rust with memory safety, fearless concurrency, modern features, and huge performance gains (Veytsman et al. 2024), while Bevy is just another crate that will handle the rendering, interactivity, and ECS.
Many people also had the same idea to use Bevy beyond game development8, logic gate simulator, app to plot metabolic map, simulating rigid bodies, visualizing spatial data, fluid simulation, and even cold atom simulations are some examples.
8 There’s a great talk by Alice Cecile at the Scientific Computing for Rust 2025 workshop, who’s the maintainer of Bevy and who used to be a complex system ecologist.
9 Bevy is also cross platform, allowing one to run their interactive simulations on Windows, MacOS, Linux, Android, iOS, and even the web with WebGL2 or WebGPU. See some examples of running on the web here.
With Bevy, computational scientists can gain a fundamentally different workflow where interactivity becomes native to their simulations, beyond the same old run and wait cycle9.
As a final demonstration, here’s a simple three-body interaction rendered in Bevy with around 200 lines of code, demonstrating that it also has the potential for just scientific visualization like Blender.