State of the Union — 2024

With so many repositories and packages falling under the pkmn umbrella its sometimes difficult to determine how everything fits together, what the big picture is, and when the various timelines will converge. The following is an account of how things stand at the beginning on 2024 — note that since this is the first update of its kind it’s significantly more in-depth than should be expected in future years…


PocketMon’s development is (mostly) blocked on the completion of several foundational packages, primarily @pkmn/stats and the updated @pkmn/img package, though also the pkmn engine / EPOké / 0 ERROR. There are several potential workstreams for PocketMon UI at this time:

Finally, work on EPOké / 0 ERROR and other pkmn projects may necessitate development on the actual PocketMon battle UI as the need for richer debugging tools begin to present themselves.


Despite marginal activity on the main 0 ERROR repository, artificial intelligence has been the main focus over the last few years of pkmn development. pkmn/engine has been a massive investment that was motivated by exploratory work on 0 ERROR and also helped shift the pkmn ecosystem away from a solely TypeScript and pkmn/ps foundation to one which also relies on low-level components written in Zig. Furthermore, work on 0 ERROR has led to the creation of, effectively splitting out the research component from 0 ERROR into a standalone community resource with broader ambitions.

While it’s possible that a initial version of the 0 ERROR agent (“N ERROR”) may be released sometime later this year after v0.1 of libpkmn is released, the arena is set up, and EPOké achieves parity with @pkmn/client, serious work on 0 ERROR is still a long ways out as it requires most of the other projects discussed here to ship.


Once the initial release of the engine ships the next focus of the pkmn project will be on publishing a minimally viable v0.0.1 release for EPOké that supports optimally parsing Pokémon Showdown’s protocol into a basic client representation of the battle. Originally (like with all other pkmn libraries), EPOké was intended to be written in TypeScript, but to be broadly useful to the maximum amount of downstream projects (and due to performance concerns), EPOké will now be written in Zig and expose a C API just like libpkmn (and similarly will provide TypeScript bindings to WASM and Node addons).

It’s unclear if the original package divisions will continue to make sense after this shift (or if they ever made sense) — it’s much more convenient to produce an überbinary which provides all of the functionality and allows for tight integration. The likely prospect of having to create a @pkmn/dex-types-esque interface package or similar for EPOké to break circular dependencies seems undesirable enough to make clean divisions infeasible.

One very consequential result of EPOké building on the engine as opposed to pkmn/ps is that EPOké will only support generations supported by the engine. This decision helps ensure EPOké’s quality will be as high as possible, but unfortunately has large implications for PocketMon. PocketMon could decide to follow suit and only support the old generations as well, however, the plan is instead to have two tiers of support and simply gracefully degrade the features PocketMon offers for newer generations. This certainly adds complexity and is less satisfying than being able to produce one cohesive experience but ultimately is a pragmatic choice — PocketMon still plans to provide a superior UX for existing Pokémon Showdown users regardless of the generation being played.


Instead of wrapping @pkmn/client as was originally planned, @pkmn/epoke will now need to subsume the TypeScript package’s feature set. This change isn’t as consequential as it might seem as one of the sticking points for getting @pkmn/epoke off the ground was that it was difficult to figure out how to actually compose with @pkmn/client.

One other large change is that designs have shifted towards figuring out a way for @pkmn/epoke to be useful without any heuristics whatsoever (i.e., without being backed by usage statistics) — while this will by no means he the primary or best way for @pkmn/epoke to be used, supporting this use case helps the package align with the pkmn goal of being reusable by a wide range of projects.

The key milestone for this package that will be required before the initial release is the wire up of a continuous integration test to verify at each decision point that the tracked client state is always a subset of the true server state.


@pkmn/predictor is responsible for the “heuristics” component of EPOké which predicts likely instances of an opponent’s team based on usage statistics. While not hard-blocked on pkmn/stats, delivering @pkmn/logs will allow for much greater flexibility with the experimentation that will be required to determine how best to accomplish the package’s goals. @pkmn/predictor is also perhaps at the greatest risk of being combined with @pkmn/epoke as it seems like it will be very difficult to work around what’s expected to be a circular package dependency between the two.


The @pkmn/spreads package’s main purpose is to be able to display EPOké’s inferred stat ranges as spreads for human consumption. Originally this package was also intended to be used to build the PokemonSet objects each side needs to be able to initialize a Pokémon Showdown Battle during MCTS instantiations, but with the pkmn engine this isn’t always necessary and this additional work can be skipped.

Despite being complete and stable, the library ends up being in an awkward state given it’s a package written solely in TypeScript code that lives in a repository that’s migrating to Zig. Whether the source will be moved to a different repository or rewritten in Zig is currently unclear — for the time being it does its job well and provides a feature that PocketMon will need at some point.


The reverse damage calculator is probably the last piece that will be added to EPOké and depends on @pkmn/dmg being solved first. While somewhat foolish to elaborate on the plans for something which is several years away from being actively developed, the high-level plan continues to be that the package will use iterative applications of the (forward) damage calculator to narrow down stat ranges and various other variables such as items or abilities. It’s possible that this package could leverage closed-form solutions which reverse the damage formula itself as an optimization in certain cases, though it seems unlikely this will generalize and the heart of the algorithm is expected to always require binary search. The decision to care only about possible stat ranges as opposed to tracking the probability distribution of each possible stat value is a pragmatic one, though as with everything else related to this package it may change in the future. is the newest pkmn project, spun out from work on 0 ERROR and still under heavy development. One facet of is the documentation and resources it provides to researchers and developers and the other is a leaderboard and AI arena — both should hopefully ship sometime in 2024 to help align the competitive Pokémon AI research community.

The top priority for is to finalize the design document detailing the plans for the project. Furthermore, on the writing front there are several large pieces that still need to be completed:

The “arena” side of requires some infrastructure development (to be covered in the pending design document — infrastructure includes a sim server, a controller process, containers, and storage) and the main goal is to get at least two agents competing on the leaderboard before the end of the year (Technical Machine and pmariglia/showdown) — being able to provide a way to measure AI performance against other agents and against past versions is critical for advancing the field.

After these pieces have been completed, outreach will be done to notify existing competitive Pokémon AI developers of the project and the community to hopefully improve communication and allow for cross-pollination of ideas. Strategically, should hopefully draw in more users to the pkmn/engine and EPOké projects via the increased visibility, though the editorial decision is to remain impartial and objective and to not attempt to cross-promote or bless any pkmn solutions on the site.


Perhaps the most inevitable project out of the bunch, the engine ended up ushering forth a new era of pkmn development. Most of the last 2 years have been dedicated to libpkmn and its as yet unreleased status is best attributed to the high bar set for the project. Shipping something is a top priority to unblock developers currently building around it - the blockers for a usable v0.1-alpha.0 release are a reworked C API, solidified protocol, and removal of in-progress features such as -Dchance/-Dcalc support. Said support is a requirement for the eventual v0.1 release proper which is slated for release in 2024, hopefully with support for Generation II, WASM, überbinaries, and everything else outlined on the (somewhat out-of-date but still relevant) roadmap.

While writing an engine is a difficult task in and of itself, having to figure out how to get all of the other pieces of pkmn to fit together with it’s a whole other challenge. Actually shipping v0.1 will be blocked on demonstrating PocketMon, EPOké, 0 ERROR, @pkmn/dmg, etc can successfully integrate the package. This may delay @pkmn/engine from being released but will serve as a forcing function to get more of the pkmn ecosystem off the ground which is probably desirable. Similary, work on stage 2 (Generation III & IV) of the engine should be on hold until all other pkmn projects have caught up, though this is less likely to be as firm a committment.

The v0.1 release will also require quite a bit of work around documentation (most importantly an updated featuring discussions of design details, tradeoffs, damage calculators from first principles, and the engine’s novel transitions function — content which is also relevant to the pending Engines explainer), articles, and outreach to potential customers. The engine has already received a sizeable amount of attention without any coordinated marketing push but actually doing the due diligence to broadcast the project is a necessary evil to further adoption.


The “modular Pokémon Showdown” project is somewhat of an enigma, both for its longevity / consistent updates and for the fact that despite there being a clear demand for such a project Pokémon Showdown still hasn’t bothered to compete with it.

pkmn/ps project is also in an odd place within the pkmn ecosystem, as its packages are simultaneously used by every part of the ecosystem and yet pkmn is actively working to shift away from what pkmn/ps provides to a world centered around the pkmn/engine. In many ways, pkmn/ps is example of the “worse is better” / “New Jersey approach” contrasting the engine’s “MIT approach”. Nevertheless, Lindy’s Law suggests that as with Pokémon Showdown, pkmn/ps should be expected to continue to exist and provide value to the many users the depend on it today.


The @pkmn/client is effectively a rough mirror of Pokémon Showdown’s client and this probably contributes to it being one of the more substandard parts of the pkmn/ps project. With EPOké no longer needing to build on top of it one option considered was to simply deprecate the package or place it into maintenance mode, but given how EPOké is planned to only support the generations covered by @pkmn/engine, @pkmn/client still has a niche to fill in terms of providing client representations for the remaining generations.

It’s near certain that @pkmn/client will be rewritten completely from scratch based on the needs of the PocketMon UI and on insights gained from EPOké’s development. The @pkmn/client API should match the @pkmn/epoke API in generations both support, and in the modern generations @pkmn/client will be structured to more closely match projections of how EPOké and the @pkmn/engine are expected to look as opposed to on @pkmn/sim and Pokémon Showdown. In the meantime, @pkmn/client will continue to be maintained and the upgrade path for existing clients (e.g., a backwards-compatibility layer) will be carefully considered before any large changes are made to the package.


Given @pkmn/view being somewhat coupled to the existing @pkmn/client API via the Tracker interface there are expected to be changes to keep it aligned with whatever the client ends up looking like. This coupling is somewhat undesirable to begin with and mostly follows from the Pokémon Showdown client’s implementation upstream — it’s possible but unlikely that the view layer could get rewritten from scratch to address this.

PocketMon does not plan to animate the battle in the same way as Pokémon Showdown (instead it plans to implement something closer to how the cartridge works with animations turned “off”; i.e, basic shake/flash and HP bar animations) and as such the @pkmn/client and @pkmn/view packages currently do not provide a great solution for achieving the sorts of animation featured upsteam. Support for certain animation hooks may be added to @pkmn/view in the future, though chaining yet another protocol Handler after the client’s handler should allow downstream developers to accomplish much the same thing, albeit at the cost of potentially needing to duplicate some logic or reparse some messages.


In a certain sense the @pkmn/data package accomplished its goals after smogon/pokemon-showdown#8181 and smogon/pokemon-showdown#9951 landed and now simply exists for polish and to allow for flexibility in swapping between Dex data providers. Coming up with a perfectly optimal data API is no longer really relevant given the shift in the pkmn project space away from Pokémon Showdown and towards the engine, and as such the data package is likely to continue on in its existing state without large changes (though perhaps some work could be done to reconcile the differing Learnset APIs now that Pokémon Showdown provides them).


Like its sibling @pkmn/data package, the @pkmn/dex package feels like a compromise, as ideally it would be merged together with the data package and provide a singular data API that also gets used internally within @pkmn/sim. Instead, practical considerations force there to be a @pkmn/dex-types package implemented by 2 subtly incompatible Dex implementations that don’t result in a super satisfactory user-experience. While it’s great that many use cases can benefit from a simpler and cleaner standalone @pkmn/dex that doesn’t contain any of the unnecessary capabilities of @pkmn/sim, eventually PocketMon is going to need to rely on the latter anyway. Unlike some of the other pkmn/ps packages which somewhat suffer from not being used by pkmn projects and which only exist for downstream users, @pkmn/dex still gets attention due to pkmn using it whenever it can in testing to avoid the @pkmn/sim dependency.

It’s possible that additional work will be done to have @pkmn/sim depend on @pkmn/dex, though intrusive edits would be required to TeamValidator and changes would be needed to pull out the mechanics event handlers from Pokémon Showdown’s existing “data” files so that they could then be combined with the @pkmn/dex data on startup. The return on investment here feels pretty small — the end result would be likely actually be a net increase to the maintenance burden due to deviating more from the upstream codebase — and thus while theoretically “cleaner” its probably more logical to leave things be.


While relatively effective, @pkmn/img has several shortcomings that led to pkmn/img being created to supplant it. The package was intended to be useful to the upstream Pokémon Showdown client itself which led to its awkward data-loading architecture and support for an asynchronous data layer. While this was originally the vision for pkmn, instead of a fully asynchronous data-layer pkmn simply moved the heftier learnset data into an asynchronous chunk and left the rest of the API synchronous, rendering @pkmn/img’s support overkill. Sporting compatibility with the upstream Pokémon Showdown client Dex is also fully unnecessary given its no longer plausible that the package will be adopted. Finally, the dependence on Pokémon Showdown’s assets limits the sorts of things the package can do (and also means the correctness of the library depends heavily on the whims of the upstream Pokémon Showdown development).

Once a rewritten @pkmn/img package can be published from pkmn/img the original source will be removed from the pkmn/ps project, though care will be taken to ensure the transition between package versions won’t be overly jarring to existing users.


The authentication logic has remained relatively stable — the only recent change was updating to handle Pokémon Showdown’s changes to its API endpoints. It probably should be marked as v1.0, though given that it’s currently unused by other permanent pkmn projects means it will probably continue to languish in the meantime. With Pokémon Showdown now supporting OAuth, @pkmn/login should likely be enhanced to support this as well, but this will probably not happen until PocketMon needs it.


Modding needs to be reworked to support simulating battles as opposed to simply allowing for the data to be modded. While this in within scope for the pkmn/ps offering, the fact that pkmn doesn’t use mods itself means support for them will always be somewhat second-class.


The @pkmn/protocol package has been undergoing a number of changes, and ultimately its entirely possible the whole package will be rewritten from scratch.

The main goal of the package is to provide a strongly typed version of the Pokémon Showdown protocol and offer helpers for parsing the chunks and “plines” from the wire into useful datatypes, though with the introduction of the pkmn engine and the new plans for EPOké to also be native code pkmn’s applications will make more limited use of the protocol package. This shift in pkmn’s plans also corresponds with a shift in focus for @pkmn/protocol — verification of the existing Pokémon Showdown protocol is now all the more important as it helps guide the design of the engine’s binary protocol. Making the @pkmn/protocol verifier as strict as possible for use in integration tests is the current area of development at this time.

A further issue that a potential protocol package revamp would hope to be address would be the subtle differences between Pokémon Showdown’s actual protocol versus it’s logical “upgraded” protocol. Currently the protocol package performs the same massaging of the Pokémon Showdown protocol that the Pokémon Showdown client does to correct/improve the actual protocol as it exists over the wire, though this additional work isn’t required for all use cases and can occasionally result in confusion.

Finally, the @pkmn/protocol has half-baked “support” for parsing old versions of Pokémon Showdown’s protocol — old message types or some past versions of existing message types are all commingled resulting in a somewhat unsatisfactory experience — instead the package should default to strictly typing the most recent version of the protocol and allowing for opt-ing in to historical messages as well. Historical messages are only relevant when processing old battle logs — most use cases have no business dealing with legacy baggage. However, properly supporting legacy protocols is a fairly involved ordeal and would require integration testing across the historical Pokémon Showdown battle logs corpus. As such, this work is currently blocked on @pkmn/logs.


The randoms package mainly exists to achieve parity with Pokémon Showdown (and demonstrate a possible modularization that may be useful upstream) and for use in integration testing infrastructure. This is a simple package that doesn’t really fit into any wider pkmn vision, but its also easy enough to maintain in case someone downstream has a use for it.


The APIs from the @pkmn/sets package are less ergonomic than one would desire, with most of the rough edges coming from Pokémon Showdown’s treatment of teams and sets:

  • Pokémon Showdown has several subtly different parsers of its various team formats which makes providing one definitive solution somewhat impossible.
  • Pokémon Showdown’s lax typing of PokemonSet is also problematic (i.e., usually PokemonSet is actually a Partial<PokemonSet<string>, but sometimes it can be a PokemonSet<ID>) and while @pkmn/sets has switched to providing a more accurate typing of what its API’s return it results in an awkward experience where types often need validation or casts to be used effectively. It’s hard to argue that type-safety should be traded off for readability, but the latter is certainly impacted.
  • Parsing Pokémon Showdown teams correctly is also cumbersome as it necessitates the introduction of a Team type not present in Pokémon Showdown to retain the format and team name. Unfortunately, this type comes at the cost of making the standard case of wanting a []PokemonSet more difficult as it requires peeling off this extra layer.

Despite all of this, its unlikely much can be done to the @pkmn/sets package to resolve any of this as the complications fall out of the formats themselves and interoperability with Pokémon Showdown.


In many ways the “crown jewel” of the pkmn/ps project, the simulator component still serves a purpose in the updated PocketMon vision to allow for play in generations not supported by the engine and for team validation. There are currently three lines of development being pursued:

  • mods currently have some issues and the existing Dex.mod implementation will need to be reworked to properly support custom formats
  • some version of the debug-rng branch’s features will likely be merged into the main branch. The ability to observe and force specific RNG results has been critical during the development of the libpkmn engine and would also be useful in driving the Pokémon Showdown simulator as a damage calculator.
  • a solution to the “formats issue” — the upstream config/formats.ts sees a ton of churn, causing @pkmn/sim releases to often be outdated within hours of being published. Additionally, the @pkmn/sim formats file gets pruned to only contain those formats that pkmn cares about for PocketMon, and this is sometimes at odds with what downstream developers want. Removing config/formats.ts from the package entirely and moving it into an auto-updating repository akin to pkmn/randbats or pkmn/smogon may be one option, as would making it easy for people to use the exact “live” upstream config/formats.ts definition in their project. The main concern with config/formats.ts is to avoid changes invalidating the @pkmn/sim bundle within PocketMon, though this should mostly already be solved by careful custom chunking logic at build time.


This was almost certainly a mistake to pull out from @pkmn/sim given its a pretty bad API to begin with, offers limited utility, and the original reason for doing so has been forgotten after proving to be unnecessary. However, the penalty for doing so simply being a slightly increased maintenance burden isn’t really that consequential. The package will continue to be updated to match Pokémon Showdown, but otherwise is justifiably going to be neglected.


In retrospect it was kind of a questionable decision to tag this as v1.0 — pretty much nothing related to Pokémon Showdown is actually stable, and with the whole package being types means pretty much any change is considered breaking. That being said, as some of the version bumps here were always going to be required to respond to Game Freak actually changing core mechanics the package being on v4.0 doesn’t necessarily reflect too many design failures.


The status of the pkmn/stats project is already well covered by its own FAQ, though the high-level takeaway should be that the project is ready for production use but expects to streamline things with the eventual release of the @pkmn/logs processing package. Additionally, exploratory work is being done into binary formats where both input and output formats are likely to use a dictionary-based ID format as opposed to a “stable”/“canonical” ID scheme.

The main goals for the stats project at this point are:


As mentioned in the preceding section, the published @pkmn/stats package currently closely adheres to the upstream Smogon Usage Stats code in an effort to provide confidence in the transition away from the legacy Python scripts. If and when Smogon adopts @pkmn/stats the first order of business will be correcting the bugs which have been replicated for parity and updating the package with support for modern mechanics. Moving to pkmn’s consolidated JSON output format would also be a large short-term win.

While simply migrating to a modern TypeScript codebase and adding some bug fixes/features is nice, rethinking Pokémon usage stats more fundamentally seems desirable. One important step towards enabling this will be switching to binary formats as the increased performance (primarily with respect to memory demands) will allow for much more advanced reporting. Future posts will detail how this can be accomplished in a robust way, after which this support should be added to the @pkmn/stats package.

Finally, while the @pkmn/stats package was originally created to produce reports for Smogon, pkmn also desires custom usage statistics that the @pkmn/stats package will be modified to additionally support. While pkmn’s processed output will certainly be written in a binary format, exactly what data it will contain is still unclear as it will depend on the needs of EPOké / 0 ERROR / PocketMon.


The anonymization package has been stable and feature complete for a while, with the main remaining work being to run the anonymization workflow over the historical Pokémon Showdown battle logs corpus to validate it and the @pkmn/protocol package after @pkmn/logs is completed. It’s expected that some legacy protocol formats will need to be added to @pkmn/protocol in which case @pkmn/anon will similarly require updates. While the Smogon Data Grant program appears to still be on indefinite hiatus and there are alternative anonymization tools, @pkmn/anon will continue be supported as at minimum it provides a good sample workflow for testing the @pkmn/logs package.


After 2-3 failed attempts it seems like eventually all possible design dead-ends will have been exhausted and @pkmn/logs will stumble upon the correct solution. While actually completing the is a hard requirement for shipping the project, the high-level overview of pkmn’s logs processing plan is that a central process will iterate over storage (which can be a compressed logs archive, a database, or via watching the filesystem to support continuous processing) and coordinate with various worker processes that will steal work off of a queue. These workers will execute one or more “workflow visitors” that produce checkpoints that allow for restarting a workflow without loss of progress and for other necessary bookkeeping tasks. Initially @pkmn/logs will be focused on supporting TypeScript workflows, though adding support for arbitrary workflow visitor binaries is within scope.

While part of the allure of the project comes from it’s ambitious goals, @pkmn/logs (and pkmn/stats as a whole) has been plagued by scope creep and the pursuit of perfection and hopefully a pragmatic middle ground can be reached in the near term to start offering immediate value.


The pkmn/dmg project is in an awkward state — substantial portions of the front-end API as well as the entirety of the surrounding project infrastructure has been completed, but ultimately work was stalled due to not having a clear vision for how results should be presented and a lack of confidence in writing the underlying backend mechanics. In particular, it seemed increasingly clear that to support the features outlined in the project’s documentation it would require the implementation of what’s effectively a full-blown simulator engine. With the advent of the pkmn/engine it also became evident that the plan of basing @pkmn/dmg off of Pokémon Showdown’s architecture was somewhat misguided.

Thankfully, @pkmn/engine provides a path forward for @pkmn/dmg in the form of its forthcoming -Dchance and -Dcalc support. The future damage calculator will backed by an implementation that leverages libpkmn and a well-written transitions function to power not only the features outlined in the project’s original documentation but also enable much more powerful computation than was previously imagined. However, like with all of the pkmn projects shifting to use the pkmn engine, the @pkmn/dmg package will be limited to supporting only the generations the engine supports.

This reality is disheartening, as delivering a full multi-generational solution is desirable to PocketMon and to third-party developers. It’s as yet undetermined how PocketMon will be supporting damage calculations in modern generations, though the following options are being considered:

The only thing that’s clear is that the PocketMon UI will provide an experience in current generations which is at least on par with Showdex, not whether the @pkmn/dmg package will provide this support in some way or another. In fact, it’s entirely possible that the pkmn/dmg repository will be merged with EPOké’s and/or that the damage calculator functionality will be merely built into the possible überbinary EPOké might ship. As with @pkmn/client, exactly what happens here will be dictated by the needs of PocketMon and 0 ERROR and much uncertainty is expected in the meantime.


The final (hopefully) result of a numerous attempts to provide programmatic access to Smogon’s data for PocketMon’s eventual use, the pkmn/smogon project mostly achieves what it sets out to do. Furthermore, many other developers are able to leverage this data to power their own applications which is makes for a great success story.

The core of the pkmn/smogon project are the scripts which get run periodically to process information about resources: analysis and set information as well as usage stats are somewhat self-evident in what their intended use is, but formats and images are slightly more opaque. Format name mapping is required to enable a historical usage stats viewer (which PocketMon will contain) to actually determine the correct display name for various one-off formats that no longer exist. The imgs index was originally intended for use by PocketMon’s data management panel which allows users to determine what resources to download and store for offline use, though as PocketMon now plans to use its own image architecture its likely this endpoint will be removed once that has been completed.

There is some confusion around what sort of promises makes to downstream developers meaning that making any sort of change to these un-versioned APIs is somewhat problematic. There should eventually be documentation (“”) detailing what these endpoints offer and ways for developers to opt-in to announcements about pending changes, though things are unlikely to publicly change much as PocketMon has started actually copying this data as part of its build due to restrictions around GitHub Pages and Service Workers meaning it needs to be served under instead of

A stretch goal for the project is to add a endpoint with Smogon’s “Sample Teams” information, to be able to preload into player’s team-builders on PocketMon. While simple on its face, the teams data actually being fairly poorly curated and highly heterogeneous makes this feature interesting and potentially valuable. Like with many Smogon projects, a small amount of structure being imposed on the forum staff would make a large impact towards automation, though this will perhaps be easier to argue once the value from an automated solution has already been demonstrated.


Another ‘complete’ package, there are no expected changes here outside of those which are required by changes to the underlying Smogon APIs. The main unsatisfying piece of this project is the concept of the “latest” data for the “best” stats for each format — the presence of this API necessitates monthly updates after usage stats are published and somewhat bloats the package. This capability was originally desired by the @smogon/sets package and the Pokémon Showdown damage calculator, but now most of the purpose behind this has been supplanted by the existence of Given that PocketMon will be using that data and @pkmn/smogon instead of smogon its possible that this feature will be removed as vestigial.


While @pkmn/smogon may require changes as PocketMon’s data and asset architecture solidifies, the library is pretty stable (especially thanks to bug fixes identified by jetou through his work automating’s set import feature) and fairly simple, with most of the complexity offloaded to the periodic jobs which update the actual data. This simplicity almost works against it, as most consumers of tend to just grab the data directly through HTTP requests which is slightly problematic as it means they’re more liable to breakages if they aren’t using the latest @pkmn/smogon client.


The pkmn randbats logic is mostly considered to be complete — a refreshing state for any software project to reach. Seeing use in, Showdex, and in a first-party tooltip (among others) is great, and the existence of this project has been somewhat of a boon to the Random Battles community. While minor maintenance is required to address bugs or handle changes by Pokémon Showdown, ultimately the project has had a very low effort to impact ratio.

As with everything, improvements are still possible — really the project’s functionality makes the most sense to exist upstream, as this data could be computed on Pokémon Showdown’s CI and committed in lockstep with any Random Battle updates. Without upstreaming, the pkmn/randbats project could benefit from more frequently polling/webhooks to alert of changes (as opposed to a scheduled approach which reduces freshness) and/or logic to query whether certain changes have taken effect on Pokémon Showdown (i.e., when Random Battles format changes have been hotpatched into the simulator), though both of these issues are currently not high priority to address.

Finally, the performance of generating 100,000 teams for each format is quite poor (exacerbated greatly by the Random Battle development team’s new approach to team generation) and changes could be made to the pkmn/randbats CI workflow to shard the team generation across multiple machines (if the machines were larger then simply running in multiple workers or threads would also be sufficient, but GitHub’s runners only have fair sparse CPU resources). Improving performance would mean more timely updates (fresher results) or potentially increased accuracy (able to generate more teams).


One of the few (currently) private pkmn project repositories, pkmn/img is somewhat of a mashup between @pkmn/img, smogon/sprites,, and sprite sourcing logic. PocketMon will depend on these sprites instead of Pokémon Showdown’s and so resuming work on this project and eventually making it public is relatively high priority, but wrangling Pokémon sprites is one of the harder things to get right. The project currently consists of three components:

While no final decisions have be made yet, the current plan for pkmn’s sprites and models is that static assets will be used in every generation, images will feature zero unnecessary padding bytes, and most images will likely be combined into sprite sheets.