3 ms·

The C API provided here is unquestionably anemic, though perhaps makes more sense when understood to exist more to facilitate bindings written in other language

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
  > 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.

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
> 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.