2024-01

New year, new site, new era.

After beginning work on the pkmn.ai project that I had been wanting to create for a while I ended up shifting gears from “coding” mode into “writing” and organization mode. The work done on the infrastructure and design of the pkmn.ai site (which itself borrows heavily from Alex Kladov’s site) could fairly easily be repurposed which motivated the overhaul the pkmn.cc site and introduction of a blog and devlog. Over time I’ve had a number of things I’ve wanted to share but procrastinated doing so (or just wrote a gist…) on account of not having a great outlet for publishing, but hopefully going forward the investment over the last few months in these sites will provide opportunities for better communication and visibility about the pkmn project.

Wrangling configs, styling web pages, and coding up a static site generator is one thing, but actually putting words on the page is another beast entirely. While I have ~20-30 different posts, articles, documentation pages, etc that I feel are important to publish, writing is significantly more daunting to me and requires a shift in mindset compared to coding — the final product is similarly rewarding, but the process requires a lot more motivation to get done. Writing demands something be “finished” unlike code which can exist in a perpetually 90% complete beta state and still be useful. This month I’ve mostly been trying to focus on getting out the bare minimum “time sensitive” pieces — one reflecting on the history of the pkmn project thus far¹ and another on the current state of the project as of 2024.

I have numerous other posts/pages here and on pkmn.ai that I plan to complete that I also feel are fairly high priority for the pkmn project as a whole to publish (for increased visibility, alignment, community and project growth, etc), but I find that focusing exclusively on high priority work as opposed to work which is most interesting/enjoyable at any given moment is a good way to burn out and end up with less output overall, so I need to trust that this work will get done eventually if it actually is high priority and that taking breaks and focusing on things which spark joy is the way to forward.

I’ve been rereading Richard Feynman’s autobiography and one passage really echoed this sentiment:

So, what’s next? Setting up this site motivated me to migrate many of my notes and scraps and ideas over the years into one place in the form of unpublished drafts, and the process of jotting down thoughts and outlining articles has really gotten the creative juices flowing leaving me with many interesting areas for research and experimentation. Playing around with scraping tournament data from the Smogon forums led me to actually return to my idea of aggregating the community’s sample teams data into one place. Ostensibly this is meant to be used at some point to preload the PocketMon team-builder with valid and viable teams to improve the new player experience, but as with everything on data.pkmn.cc I expect other projects might have a use for it so it’s nice to be able to offer it in one easy-to-consume location.

I think its very likely that I will return to @pkmn/logs and usage stats within the first half of the year — I want to repair the rating information missing from ~70% of all but the most recent logs, I want to produce an anonymized dataset of battle outcomes to allow researchers to be able to experiment with changes to the rating system, and I want to be able to efficiently perform certain queries over the historical logs corpus (e.g, related to player sessions and ladder queue times). While usage stats are critically important for many pkmn projects, having immediate use cases for improved logs processing is a much more motivating than only thinking of the indirect long-term benefits. I’d like to say I’ll also get around to sprite processing as historically its been one of the other “bogeyman” undelivered pkmn projects alongside stats but the lack of the immediate payoff means it might continue to languish².

In terms of planning, the main areas of focus (“the frontier”) this year are:

1. shipping v0.1 of pkmn/engine
2. fleshing out pkmn.ai and building up the Pokémon AI community
3. finishing PocketMon’s asset pipeline and data management layer
4. beginning serious work on EPOké
5. publishing monthly development logs here in addition to maybe 5-8 of the more fleshed out draft posts
6. writing play.pkmn.cc/introduction

The details here are covered in State of the Union — 2024 — e.g., logs processing and usage stats is relevant to 3–5 on this list. Timeline-wise, working on pkmn.ai will likely be a concurrent background task that’s expected to span much of the first half of the year, though after somewhat of a hiatus from “proper” coding getting stuck back into more meaty technical projects will likely take precedence.

In that regard, cleaning up the C API of the libpkmn and overhauling the engine’s protocol will likely be tackled early on, after which a v0.1-alpha.0 release of the engine without -Dchance/-Dcalc support can ship. Shipping a somewhat polished (though feature-incomplete) version of the engine is important to allow developers (potentially those brought in via pkmn.ai) to actually build against it, though ultimately the actual v0.1 will still require most of the engine roadmap to be addressed before being released.

In order to finalize the engine’s wire protocol the actual Pokémon Showdown protocol needs to be verified. Pokémon Showdown’s protocol documentation is lacking and a naive translation of it to code results in suboptimal performance as it’s far too general. A lot of work has gone into verifying the actual Pokémon Showdown protocol as strictly as possible via @pkmn/protocol, though the remaining ~50% of that work needs to be completed. After strict protocol verification is in place:

• the engine’s protocol can be updated and loosely finalized for every existing generation, resulting in substantially less churn for users and the authors of bindings going forward
• the pkmn.ai page documenting protocol can be written to allow AI developers to confidently write optimal parsers
• an optimal protocol parsing implementation can be written for the EPOké project
• the @pkmn/protocol package can be updated with improved types

Adding logic to EPOké to optimally parse a buffer of protocol lines from Pokémon Showdown (a “chunk”) and using them to fill in a basic client representation of the battle is also likely to be tackled early on, not because it actually matters in the slightest in the greater scheme of things (parsing protocol will never be a bottleneck for a competitive Pokémon AI), but because it promises to be fun (playing with minimal perfect hashes, SIMD tricks, DAFSA, HAMTs, and compile-time data structures)! Furthermore, protocol parsing and a basic client representation may be the bare minimum EPOké plans to offer but it should provide enough value that developers would be able to start building around EPOké (with the promise the more advanced features will follow).

I’m reluctant to get stuck in too much with pkmn/engine work as it has monopolized much of the last 2 years. Generation II, -Dchance, documentation, polish, and the eventual “official launch” are something I’d like to return to in the second half of the year after other pkmn projects have been attended to, but at the same time methodically working on the engine is quite cathartic and rewarding so there is always the possibility I return to it early after getting frustrated elsewhere. At least some concurrent exploratory work on EPOké and pkmn/dmg are going to be necessary to prove out the eventual engine APIs, though what if anything shippable will materialize from these explorations is unknown.

— pre