There are a lot of parameters that affect both the randomization and scoring. Currently these are hard-coded. It would be good to extract them into a config, probably using serde_yaml.

Currently the screensaver seems to lean towards just starting with more planets and letting them fall into the center and make a single large mass. This is probably because it's easier to get more points by having more mass than by having more planets. This should probably be tuned somehow.

Some ideas:

• Constant multipliers for both mass and number of planets so we can boost or reduce one or the other
• Exponential powers on each, so the value of adding more mass vs adding more planets is nonlinear.
• Adjust scoring over time, so having more planets towards the end of the simulation is more valuable than having a lot of planets at the beginning (rewarding keeping them around)

These should all be included in the configurable parameters from #3

The current parsing relies on the yaml parser/generated serde deserializer, giving ugly expression trees like {"multiply": ["mass_count", {"constant": 3.5}]}. This should be changed to do some kind of better parser.

Two good choices are either an s-expression parser or an lalrpop based parser.

The genetic orbits scenario currently allows the database to grow without bounds. The database should occasionally be pruned to the top N scenarios, either as an occasionally-running background task, or as a shutdown task, or both.

Sometimes when I leave the saver running for a long time (e.g. over a weekend) on two monitors, when I get back, one screen will be frozen while the other is still running. I don't know if this is a crash or a freeze because if the saver crashes, I don't know if it gets re-launched, or if the last frame it displayed just stays up forever, but I couldn't find a crash in the logs last time I looked.

This has only happened for saver_genetic_orbits, not for any other savers I've experimented with in this engine, so that makes me suspect it has something to do with the screensavers interacting through the database. Perhaps they have conflicting transactions that aren't handled properly and so the loser panics on the failed transaction.

Currently the random scenario generator and the random mutator have low limits on how high they can set velocities/how much they can move velocities. This means that it's very hard to reach a state where planets don't just all fall into the center at the start. These should allow more variance.

It might be interesting to set up a headless mode for the genetic orbits screensaver which doesn't render or draw and just runs the simulation as fast as possible, as a way to allow people to run extra rounds of the genetic algorithm quickly in the background.

Modify the setup command to add an index by score desc to the Scenario table -- we select by score descending frequently, so having this indexed is a good idea.

Currently debug info is all printed to stdout using the println! macro. This is simple but misses some utility like logging the times and sources of messages. Switching to use the log crate and loggining macros should be pretty easy.

Running without setting a target window environment parameter causes the engine to run in a fixed-size window that has no border and accepts no input. The only way to close it is to ctrl+c in the terminal that started the screensaver. This should be changed to either run as a full preview screensaver (fullscreen and auto-close on any user input) or just as a regular bordered (and potentially resizable) window with a close button.

The planets for Genetic Orbits always have 16 segments for their circle render, which is fairly low, and becomes obvious for large planets. The number of segments should be increased, and possibly scale with the planet's size.

When planets collide, they are deleted immediately, before additional renders. Because draw positions are interpolated between physics positions over several frames (to make motion more smooth), this means that when planets "collide" they often disappear before visibly touching on-screen, especially when moving quickly.

Find a way to fix this, e.g. by moving the collision handler until before the next physics tick instead of at the end of the current one. This might effect scoring slightly (since "collided" planets will remain for an additional frame), but if we're re-tuning the rest of the scoring parameters, that probably doesn't matter too much.