A Pokémon battle simulation engine

You would get the actual fun of Pokémon battles without grinding. And, yes, I know emulators with fast forward and so on, but even Pokémon Radical Red has mechanics on purpose to send grinding to /dev/null with dumb battles against Audinos in order to get EXP like craze.

BTW, Pokémon Unbound might be the best hackrom ever because of the environment and features, but when you just want to fight, an straight offline simulator would be much better.

The performance numbers for Generation I will not change as other generations get implemented (by design), and Pokémon Showdown will likely fare better as the game logic gets more complex but I would still expect at least a 1000x difference in performance even for modern generations - the things that make Pokémon Showdown slow do not go away as the generations increase, there is just perhaps less irrelevant stuff happening in later generations to slow things down.

The Zig patch in the source tree is optional and for performance reasons... but a ~20% performance boost is hard to pass up. This is not a general purpose patch, it is only relevant to this project which makes heavy use of sub-byte integers and has a very very comprehensive testing suite to ensure that the undefined behavior that could occur if this patch were applied and used to compile arbitrary Zig problems are not an issue.

I probably would not expect to use your program, although I had these suggestions anyways, since it would make sense to be improved even if other implementations also exist. However, I do think that your program does many things better than Pokemon Showdown does (I dislike much of the design of Pokemon Showdown), and the stuff you have written may be helpful when making a different one, if as you say, there are problems with the implementation in Pokemon Showdown.

Having a separate structure for active and inactive pokemons is good that what you have, and is what I had thought should be done also and, reading your documentation, I found out that Pokemon Showdown doesn't do that.

If I write one, I also would want to be more targeted in scope than the official games and Pokemon Showdown, although my scope would be a bit more than you have. What you did may be OK for your uses, although not quite what I wanted to make. I also intended to be more flexible in some ways; this might be slower than yours but would probably be faster than Pokemon Showdown.

> Team validation is an an orthogonal problem, and is almost completely solved by PKHeX

OK, although PKHeX is now another different programming language (C#), and the programs have their own dependencies (in that case, C# 13 and .NET 9.0), while your program also has the dependencies (a Zig compiler, which must be older than a specific version, and also JavaScript code).

> Your other requests (Unown/Spinda/PP UPs) are all client concerns

PP Up does affect the team definition and the game behaviour (it affects such things as e.g. whether or not Struggle is a legal selection). However, at least in the case of generation I, this might not be relevant if you allow starting the battle without being fully healed (if, as you mention, your library does not do team validation). For some later generations, it might be significant if PP can be recovered during battle in some circumstances.

If your program expects the client to decide whether or not teams are revealed, then you could say that my things about Unown and Spinda are client concerns, although I would have the battle engine to specify by the API that some things are exposed, in order that the caller does not have to know what is supposed to be exposed according to the specified rules.

> our switching scenario will also be handled whenever the generations it is relevant to get implemented. Pokémon Showdown already supports the concept of "maybe trapped" so presumably handles the scenario you're detailing

This is OK, then.

", Wrap does 0 damage against Ghost-type Pokémon instead of properly respecting immunity, "

This was the only significant effect I could find, it would change dragonite and wrap.

I think it would be a nerf, but it may be a buff. Wrap is also used as a kind of u turn, but it works both ways, currently you can use gengar to pivot vs wrap.

I think this would nerf dragonite as he wants to pivot away from gengar, and buff arbok, as it would allow glare-EQ vs gengar, even if they have psychic.

Not massive, but you never know what butterfly effects bugs like these can have, or even unknown interactions, we learned from the Body Slam 2015 revolution that for metagames so advanced small changes can have profound implications.

Finally, while the project is cool, selectively patching the most key feature (which in competitive games and in Smogon is decided by prioritizing high elo votes) would make for an interesting concession