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 far1 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:
It was a brilliant idea: You have no responsibility to live up to what other people think you ought to accomplish. I have no responsibility to be like they expect me to be. It’s their mistake, not my failing. […]
Then I had another thought: Physics disgusts me a little bit now, but I used to enjoy doing physics. Why did I enjoy it? I used to play with it. I used to do whatever I felt like doing — it didn’t have to do with whether it was important for the development of nuclear physics, but whether it was interesting and amusing for me to play with. […]
So I got this new attitude. Now that I am burned out and I’ll never accomplish anything, I’ve got this nice position at the university teaching classes which I rather enjoy, and just like I read the Arabian Nights for pleasure, I’m going to play with physics, whenever I want to, without worrying about any importance whatsoever.
Within a week I was in the cafeteria and some guy, fooling around, throws a plate in the air. As the plate went up in the air I saw it wobble, and I noticed the red medallion of Cornell on the plate going around. It was pretty obvious to me that the medallion went around faster than the wobbling. […]
I went on to work out equations of wobbles. Then I thought about how electron orbits start to move in relativity. Then there’s the Dirac Equation in electrodynamics. And then quantum electrodynamics. And before I knew it (it was a very short time) I was “playing” — working, really — with the same old problem that I loved so much, that I had stopped working on when I went to Los Alamos: my thesis-type problems; all those old-fashioned, wonderful things.
It was effortless. It was easy to play with these things. It was like uncorking a bottle: Everything flowed out effortlessly. I almost tried to resist it! There was no importance to what I was doing, but ultimately there was. The diagrams and the whole business that I got the Nobel Prize for came from that piddling around with the wobbling plate.
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 languish2.
In terms of planning, the main areas of focus (“the frontier”) this year are:
- shipping
v0.1of pkmn/engine - fleshing out pkmn.ai and building up the Pokémon AI community
- finishing PocketMon’s asset pipeline and data management layer
- beginning serious work on EPOké
- publishing monthly development logs here in addition to maybe 5-8 of the more fleshed out draft posts
- 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/protocolpackage 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