Call me paranoid but I don’t like depending on third-party stuff for the build infrastructure. So I looked into whether there is a more canonical caching solution for Github actions. Turns out there is: https://github.com/actions/cache/blob/main/examples.md#rust---cargo. It works well for my repo.

One has to commit the Cargo.lock file however. That’s probably recommendable either way.

Currently, when paused the application continues to loop. As a result, CPU load is still high. Worse yet, for me it tends to hang up then (most likely a graphics deadlock again). Setting loop mode has none of these issues.

This fixes #14, all mostly straightforward. The only complication is that Battle::fight needs two fighter references, one mutable, and the previous work-around no longer works with the types being opaque. The solution to split the vector into multiple independent slices might help with multithreading as well.

I used egui to display a floating window on mouse click. It displays the current position of the mouse pointer and the fighter type along with its color.

Using Debug trait to stringify fighter types is somewhat awkward but should do for now.

The only issue I noticed: when the app is paused, the figher info window will stop updating as well, even if the mouse is moved. I guess that pausing has to be done by skipping the battling after all. But we won’t get around redrawing even in the paused state.

Only usable I think if you're able to pause the simulation (see #23)

You'd have to tell each fighter to implement either Display or something similar. I wonder what's the best way to show this kind of info, a modal window that appears in the corner or something?

See https://rust-lang.github.io/rust-clippy/master/#wildcard_imports for recommendations on imports. This rule isn’t enforced by default but running cargo clippy -- -W clippy::wildcard_imports will make the warnings show up. In general, importing stuff in main.rs that isn’t used there but is transitively imported elsewhere is very confusing. Also, use super::* in tests usually takes care of all import needs.

I noticed lines in the display if I specify an image size that’s not square. Turns out, this is a regression from #36: wrong calculation in Battle::action().

While looking for the bug, I added a test making sure that Grid2D::get_pair_mut() operates on the same data as is returned by Grid2D::get() later. It’s probably a good idea to keep this one.

This commit implements a 2D grid API using a single Vec.

The API of this new Grid API uses Option. By manipulating and propagating Option, we can also get rid of code like Location::is_outside.

Location in general has also been removed and replaced by a pair of usize.

Made use of std::iter::repeat_with to construct the table of fighters. Also migrated to the GenerateRandomly trait, that generates one fighter at a time (to be used with repeat_with)

Got rid of pointless POKEMON_COUNT and RPS_COUNT constants while at it. The point was not requiring any consumers to import strum::EnumCount, but that size is used only internally now.

With this change, the --fightown command line flag determines whether own kind is attacked or not. If it’s the latter, no attack happens at all (previously it would still attack if no other pokemon were around).

The challenge here was implementing this without hurting performance too much. That’s why I have weakest_neighbour and weakest_neighbour_filtered as separate functions – any kind of decision making inside the function would degrade performance. And I choose the callback up front now so this choice doesn’t have to happen within the loop (I strongly suspect though that Rust already optimized that choice out of the loop before).

Seems generic enough since you only need to decide what happens when a matchup occurs. Chess pieces? Something from other games? Simulations (does it work for game of life?)