> I still find C to be better anyways. Whatever floats your boat, programming language wise. People tend to focus too hard on languages and forget they're real

> I still find C to be better anyways. Whatever floats your boat, programming language wise. People tend to focus too hard on languages and forget they're really they're just a tool to build cool things. > What you did may be OK for your uses, although not quite what I wanted to make Totally understandable - engines are hard to be perfectly general because of the various tradeoffs and constraints involved. If my work and documentation helps make it easier for future developers to write their own engines that better suit their needs that's still a plus in my books. > OK, although PKHeX is now another different programming language You'd probably just stick it behind a simple API and run it on a server if you wanted to host a full blown simulator in the spirit of Pokémon Showdown. Or if you want it client side you can just write your client in C# (pretty common for games) and then link in the engine separately (you don't need a Zig compiler, just grab the release). > while your program also has the dependencies (a Zig compiler, which must be older than a specific version, and also JavaScript code). This is a misconception, hopefully careful reading of the documentation would reveal this to not be the case? The engine itself does not require JS (it is a development dependency - you don't need to be able to run the integration tests to use the engine) and works perfectly on every version of Zig since 0.11.0 (which is no small feat), it just is faster on older versions, thus those are recommended. > 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). Pedantically, PP, not the number of PP Ups impacts whether or not Struggle is a legal selection (or even more pedantically, PP plus things like whether a move is Disabled/Imprisoned etc impact whether or not the Pokémon will Struggle). > For some later generations, it might be significant if PP can be recovered during battle in some circumstances. Yeah, in Generation III and onward I believe it will become relevant to store the number of PP Ups applied (due to the introduction of the Leppa Berry) whereas in Generation I and II only the total PP is required (MysteryBerry exists in Generation II but since it always restores 5 PP when PP reaches 0 and no move that can have its PP restored has less than 5 PP this is still safe). > although I would have the battle engine to specify by the API that some things are exposed This additional bookkeeping slows down the engine. A design principle of the engine is that if something can be pushed to the client it will be. This makes using the engine much more tedious, but means the engine will be as fast as possible which ultimately makes it viable for a wider array of use cases.