3 ms·

I like that it has a C API (although it uses opaque data without any real way to initialize it other than just storing it in the program, which doesn't seems li

I like that it has a C API (although it uses opaque data without any real way to initialize it other than just storing it in the program, which doesn't seems like very good to me), and had wanted that before, although I would have preferred one that is written fully in C rather than Zig. (Actually, I did start to write some ideas (including some parts of a .h file) about the structures and functions that the C API should use (although they can be changed if at any time during the design, they are found to be not good). My design is different from that one in many ways.) I would also want support for some variants (including custom rules) as well as for standard rules, and for team validation (including custom team validation). (I did have ideas also about the rule sets formats, with many options; for some kind of custom rules, it would be necessary to modify the program, but that is OK; some kinds will not require such a modification.) I also wanted to support Unown's letter in generation II only, and Spinda's spots in some generations (probably III, IV, and V; they would result in some of the data being revealed to the opponent), and the ability to change the number of PP Up (as far as I know, Pokemon Showdown always has the number of PP Up set to 3 and it cannot be changed; it is probably uncommon that you would want to change it anyways but it does have some uses). Another consideration to be made is: In a double battle, if your second pokemon is prohibited from switching out due to an opponent's ability that you are unaware of (e.g. since it is a pokemon that can have multiple possible abilities, or if it is actually Zoroark), but your first pokemon is immune to that effect (e.g. due to being Ghost type), then it is possible, if the commands are selected for the first pokemon and then for the second pokemon in that order, that you will not be aware of this right away. If your second pokemon tries to switch out, then you will receive an error message and both of your pokemons can reselect their commands, but if your second pokemon tries to switch out and it is actually allowed, then you cannot reselect your commands for either pokemon. (I don't know if this rule is specific to some generations.)

scheibo 1y ago
The C API provided here is unquestionably anemic, though perhaps makes more sense when understood to exist more to facilitate bindings written in other languages (Python, C++, Rust, etc) and not as an API intended to be used by developers setting out to write an application in C. The two main reasons the C API kind of sucks is that (1) C does not support namespaces/modularization (2) C does not have convenient standardized bitfield support that works cross platform. Finally, I can't really imagine someone wanting to leverage this engine from C and balking at spending an afternoon writing a friendlier wrapper API specific to their use case. That being said, if you have suggestions for improvements please open an issue on GitHub to discuss it. Team validation is an an orthogonal problem, and is almost completely solved by PKHeX (https://github.com/kwsch/PKHeX https://github.com/kwsch/PKHeX) which already does a better job at it than the original game developers. Pokémon Showdown's custom rules are almost all enforced at team validation time, and the standard clauses/rules which require modifications to the engine (e.g., EBC, Sleep/Freeze Mod, Desync Mod) are all supported already by this engine when -Dshowdown compatibility mode is enabled. Your other requests (Unown/Spinda/PP UPs) are all client concerns and thus would be implemented at a higher level than the engine shared here. Your 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, though if not I'm sure they would appreciate being made aware of any bugs that might exist.
- zzo38computer 1y ago
  While there are problems with the C programming language, in my opinion the other programming languages that they tried to make it better, often has their own problems instead, so I still find C to be better anyways. 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.

scheibo 1y ago

The C API provided here is unquestionably anemic, though perhaps makes more sense when understood to exist more to facilitate bindings written in other languages (Python, C++, Rust, etc) and not as an API intended to be used by developers setting out to write an application in C. The two main reasons the C API kind of sucks is that (1) C does not support namespaces/modularization (2) C does not have convenient standardized bitfield support that works cross platform. Finally, I can't really imagine someone wanting to leverage this engine from C and balking at spending an afternoon writing a friendlier wrapper API specific to their use case. That being said, if you have suggestions for improvements please open an issue on GitHub to discuss it. Team validation is an an orthogonal problem, and is almost completely solved by PKHeX (https://github.com/kwsch/PKHeX https://github.com/kwsch/PKHeX) which already does a better job at it than the original game developers. Pokémon Showdown's custom rules are almost all enforced at team validation time, and the standard clauses/rules which require modifications to the engine (e.g., EBC, Sleep/Freeze Mod, Desync Mod) are all supported already by this engine when -Dshowdown compatibility mode is enabled. Your other requests (Unown/Spinda/PP UPs) are all client concerns and thus would be implemented at a higher level than the engine shared here. Your 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, though if not I'm sure they would appreciate being made aware of any bugs that might exist.

zzo38computer 1y ago
While there are problems with the C programming language, in my opinion the other programming languages that they tried to make it better, often has their own problems instead, so I still find C to be better anyways. 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.