1 of 12

Juice your Simulations: What Science Can Learn from Game Development

Alice Cecile, Staff Engineer @ Bevy Foundation

For Scientific Computing in Rust 2025

2 of 12

Games and simulations

complex logic
rapid iteration
graphics, interaction, audio, web deployment…
performance sensitive!

I’d use Bevy, personally.

- Alice I. Cecile, Bevy maintainer

Having spent a fair bit of time building both scientific simulations and games, there is a shocking amount of overlap. They both involve:��- complex logic that has to be evaluated quickly

- uncertain requirements and rapid iteration

- all sorts of incidental bells and whistles: graphics, user input, audio, the ability to deploy to web…

�What a brutal requirements list! Thankfully, we have tools that can help: they’re called game engines.

�I happen to make Bevy: an open source Rust game engine. Honestly, I think it’s one of the better options for some classes of scientific model: it’s fast, flexible and makes it really easy to manage complex logic and share reusable bits across your projects.

But this talk isn’t a sales pitch: let’s talk about all of the cool ideas that you can and should steal from game dev.

3 of 12

Why do we model?

Explore: test theories, build understanding
Teach: communicate to students and peers
Deploy: generate real-world outputs

All models are wrong, but some are useful.

George E.P. Box

4 of 12

Explore: rapid iteration

Don’t waste time on:

optimization
polish
architectural complexity

Take the time to:

think carefully about questions and answers
design minimal experiments
improve your workflow

When exploring, iteration speed is absolutely key. But to me, the most important lesson there is about the things you shouldn’t do.��There’s two reasons why you should avoid optimization, polish and architectural complexity.

The most obvious one is that they’re a waste of time: you’re still exploring, and don’t need them yet!��But the much more insidious reason is that they actively slow down changes.�That fancy numerical approach that gives you a 10x speed improvement? Well, now it’s much harder to see what some weird new behavior does.�Beautifully formatting your rulebook? It makes changing your rules much slower.��Polish, in all of its forms, is a vital part of both scientific simulation and game development. But there’s a time and a place for it: doing it early is not simply pointless; it’s actively harmful to your project.��At the same time, I see a lot of game devs and scientists making the opposite mistake: conflating rapid experimentation with “rushing”.�The goal is to learn about the system you’re exploring, and barreling blindly forward simply isn’t effective.�Instead, you need to think carefully about the questions you have, figure out how you can improve your certainty via the simplest, cheapest experiments, and then reflect on those results to devise new questions and solidify your understanding and vision.�

And when the urge to polish and build something durable strikes you, there is something productive you can do: improve your workflow, and build up a solid foundation.�

5 of 12

Explore: build a foundation

live inspection
pause/play/step
scenarios and checkpoints
asset-driven workflows and hot patching!
automated testing

For all of their differences, each simulation (and each game) share certain core foundations that can be reused across projects, and persist even when you suddenly decide to pivot.��The most important of these tools are the ones that make experimentation itself easier: letting you make changes faster and fix problems sooner.��Game devs have all sorts of delightful tools and strategies for this, that as a scientist, you should actively steal.

Make it easy to inspect the state of your simulation as it runs, and set up nice pause/play/stepping functionality so you can slow things down and examine what’s going on.��Spend some time investing in a solution to save the current state of the simulation, and use it to define reusable scenarios, and create checkpoints for overnight model runs.��Stop wasting time on compilation, and explore tools like asset hot reloading or code hotpatching that bypass all of that.

�And finally, take a bit of time to set up some automated tests, and run them in CI. You don’t need to go crazy, but testing tricky logic can save you a ton of time and heartache.

�Do stay tuned: at the end of this talk, I have a demo that shows off some of these tools!

[Image from bevy-inspector-egui: an incredibly useful prototyping / dev tool for Bevy]

6 of 12

Teach: unfolding ideas

encourage play
introduce one idea at a time
show detailed info in tooltips and menus
graphs and stats!

So, you’ve explored your system, and you’ve drawn some interesting conclusions that you want to share with the world. Maybe that’s some students, maybe that’s your supervisor, or maybe it’s Reviewer 2 at that fancy journal.��How do you actually teach people with your simulation, and persuade them that your interpretation of the dynamics is correct and interesting?��Well, I think you can take a page from game design here, and teach people to learn through play. Really! Games are incredibly complex things, yet even small children figure out their nuances all by themselves.��Think about the key dynamics of the system you’re modelling, and slowly and carefully unfold those dynamics with your audience. Start with the very simplest possible form, then slowly add mechanics, changing either the rules or the starting conditions.�Write up the results of these little experiments of course, but let the reader play, and prove to themselves that this is what they’re actually seeing and build an understanding for how the system works.�

As people get curious about the details, embed little explanations: in tooltips, menus and little encyclopedias. Add cute little dynamic graphs, and quickly summarize the state of the system for your user. Don’t just dump it all on the poor reader up front: organize it, and let their curiosity draw them into the details.��[Image is of Poly Bridge 3, part of a series which does an excellent job with tutorialization]

7 of 12

Teach: add some juice!

provide tactile feedback
highlight important events and actions
sound, animation, particles
not just fluffery: information processing!

But how do you get people to actually engage with your simulation, to learn with it, to fall in love with it and finally accept your paper to that high-tier venue?��I have one, very weird, very important word for all of the scientists in the audience to go look up after this talk is done: juice.��That’s the term that game devs use to describe the way that games make simple, ordinary actions feel delightful. There’s all sorts of tricks to learn here, but your two key goals are to focus on giving users feedback for every action they take, and carefully highlighting the most important information.��You might use color, sound, camera movement, animations, little puffs of particles. There’s no “add juice” button hiding in game engines: you need to figure out how to sell each action in a compelling and satisfying way.��Juice isn’t just fluff and polish though: it serves a real, practical purpose. Simulations, just like games, have a huge amount going on. Proper juice makes it easier to use your software, by focusing your attention on the things that matter, and letting everything else fade into a pleasant background hum.

[Images are of Nova Drift, an incredibly juicy arcade game]

8 of 12

Deploy: profile, then optimize

you can’t improve things you can’t measure
profile to find what’s taking a long time
isolate with benchmarks and stress tests

If and when your model makes it into production, you’re going to want to make it go fast. Game devs have all manner of tricks there, but the single most important lesson is that you have to measure.��Speculation and vibes about “why is my model slow” don’t work, no matter how smart you are or what your grant says. There is exactly one way to improve the performance of complex systems: find out what’s slow, and then make that bit faster. Repeat.��The best way to do that is to profile your application, using something like tracy, which uses spans to break your application into chunks and automatically measure the time that each span takes.��Once you’ve figured out what’s slow, try and make it faster!��If you’re having trouble picking apart the signal from the noise, make weird, extreme stress tests or write micro-benchmarks, and isolate the work in question.��[Image from https://luxeengine.com/integrating-tracy-profiler-in-cpp/, showing off tracy’s capabilities in game dev]

9 of 12

Deploy: building it isn’t enough

simply creating something cool isn’t enough. Sorry!
you have to actually market your work
refine the funnel
community matters: nurture it

The last lesson I have for you today is the hardest, most bitter one of all, as both a scientist and a game dev.�Simply building something faster, more accurate, more fun than all of the competition isn’t enough.��You have to go out into the world, and proudly share the thing you’ve made with other humans. I know, marketing.

But the world is a busy place, and no one will ever care about your work as much as you do.

It doesn’t have to be fake, and it’s not all about ads and influencers and glamor journals.��Think about why someone would care about the thing you’ve made, and share that with them, clearly and proudly.�Make it easy for them to find your work, easy to setup your model, easy to learn how it all works and easy to contribute.��And over time, you’ll build a community: of players, of students, of colleagues, of allies.�Cherish and nurture that, because it makes all the difference in the world.��Thanks for being part of that for me today <3

10 of 12

Live Demo: Hotpatching Rust?!

Try it yourself!

11 of 12

Thanks! Ask me anything!

Donate to Bevy 💚

Once an ecologist, now a game engine dev. I taught myself to program, and love mountain biking, plants and writing design docs.

Curious about the demo? Steal my code from:

github.com/alice-i-cecile/cellular-automata-demo

alice-i-cecile@bsky.social

12 of 12

From ecology to game dev

Be a budding researcher in complex systems ecology
Get very sick :(
Become a bored housewife
Make games!
Maintain a major game engine?!

alice-i-cecile@bsky.social

Usually, I think that “About Me” slides are dry and self-indulgent. In this case however, I think it’s helpful for people curious enough to poke through my slides to understand my weird perspective.��Once upon a time, I was a budding undergraduate researcher in complex systems ecology. I loved research, publishing multiple papers and pouring all of my academic energy into the work.��But one day, I got very, very sick. I had to quit my job as an RA, and scraped through the last couple of credits for my degree via remote courses. All of my plans for grad school lay in ruin.��I tried to work, but even the simplest jobs were too much for my health. So instead, I survived. And I tried to teach myself more programming, more statistics, more machine learning: things that I could do even if I was too sick to wander the forests.��Eventually though, I had a stroke of luck. Someone took me in, and gave me the support I needed to start getting better. They kept a roof over our heads; I played housewife and figured out what was making me so sick. Day after day, I slowly got better, until suddenly, I realized I was bored.

So I started making games, beginning with tabletop games. I loved game design, and eventually, I wanted to try my hand at video games too.��My partner saw Bevy via a social media post, and encouraged me to give it a try for the sort of sprawling, systems-oriented games I wanted to make.��I was immediately frustrated with how terrible the docs were, and got to work improving them, learning as I went. One thing led to another, and suddenly I had merge rights :D��I spent some time with Bevy-related consulting gigs, and even did a bit of time at a real indie studio. But the life of an engine dev was inescapable: as Bevy grew, we found that we had just enough funding for a second full-time paid maintainer. Cart thought I was the perfect fit, and I was thrilled to accept it.��I’ve learned a ton about game development over these years, watching, helping and even doing some of it over the years. But my time as a scientist has fundamentally shaped me, and I want to share the core lessons that I would take back to science with people who are positioned to make good use of them.