Should permanent extinction ever be allowed in an evolution sim?

I think the line you're trying to draw between 'cheating' and 'playing god' is mostly arbitrary when the experiment is running on a piece of consumer hardware. If you are running the simulation on a Pi 5 because it fits your budget and your desk setup, then your input is fundamentally part of that setup. When I set up my own cellular decay simulation last winter, I had to manually update the kernel because the upstream repository hadn't caught the latest security patch for the 3.18 branch. That was a neccessary intervention to keep the system stable, not a 'god move'.

My stance is that the experiment only holds value if you clearly define the rules of observation from the start. If you decide to let the grazers vanish and then boost the predator, you are no longer studying a purely isolated system; you are studying a managed enviroment. That changes the data, but it doesn't make the process fraudulent. It just means you are modeling human influence, which is arguably more real than an idealized, untouched ecosystem. I remember running a similar discrete-event model last year, using a Pico to handle the sensor data logging because of its low power draw. The moment I realized the parameters weren't yielding the results I expected, I adjusted the mutation rate by half. It wasn't 'cheating' the nature; it was calibrating the model to see how much a controlled variable could impact the outcome. It's just part of the methodology.

I think the debate over 'cheating' versus 'playing god' misses the point because it frames the issue around my feelings instead of the scientific integrity of the simulation itself. wether you run it on a Pi 5 or an old Arduino clone, the moment you intervene, you change the variable you set out to study. For example, when I was running a localized water cycle model, I was tracking the humidity in my small potting shed using an ESP32 and several DHT sensors. My whole point was to see how a sudden drop in transpiration rate would affect soil moisture. If I manually added moisture to compensate for a dry patch, I wasn't just being a weather god; I was fundamentally altering the input data and the outcome of the study.

If the goal is to observe how an ecosystem functions in a state of natural entropy, then the loss of a species, even if it's a dramatic event, must be treated as the intended data point. The survival of a species is not a measure of how entertaining the simulation is, but a measure of the system's ability to remain robust. Allowing a crash to happen lets you see the cascade effect, which is the most valuable data you can get. I suggest treating the simulation less like a narrative and more like a real physics problem where boundary conditions are fixed, even if they include mass extinction. It is a commitment to the initial premises. If you want the data on how robust a three-species model is, you have to accept the chance that it will collapse. Otherwise, you are simply running a highly complex, very expensive, but ultimately arbitrary digital terrarium.

I mostly just worry about how much overhead you add when you start fiddling with the code. Every time you manually tweak a population count or change a rate, you are adding more calculation complexity to the overall loop. In my setup, when I started running that complex sensor log parser, I noticed the CPU usage climb fast. I eventually had to optimize the dictionary lookups because the memory footprint started ballooning before the Pi even hit full load. If you boost parameters, check your system resources first.

I tried something like that with a bunch of small bots running around, and I ran into trouble more with the display than the actual math. I had to constantly tweak the timing of the updates becuase when one part of the program slowed down, the whole picture just started to stutter. It seemed like the timing of when the change happens is as important as the change itself. I was wondering if people ussually try to make the simulation run at a specific speed, like once a second, or if it just runs as fast as the board can handle without any limits?

I keep getting stuck on this idea of the simulation being 'broken' if I change things. I was trying something similar but with a Pico running just a simple data logging script, not a complex model like yours. I haven't gotten far enugh to worry about population counts, but I found myself spending hours tweaking the logging interval because the data felt useless otherwise. It makes me wonder if the 'cheating' is really just how much you care about the outcome. Maybe the issue isn't the intervention but the expectation of perfection from the start. If the system feels boring because it's running too 'correctly,' does that count as a failure? I just feel like I'm trying to find the balance between a fair test and something that actually feels interesting to watch.

Update: left the predators alone after that one boost and honestly the second poster had it right, once you intervene you've changed the thing you set out to watch. So the new rule is the sim stays hands off no matter how sad a crash looks. The grazers are actually re-evolving back in on their own now, which is way better than anything I could've done manually.