Pokémon Showdown is a
free and open source project that has
many contributors who
volunteer their time and skills to help make Pokémon Showdown the best and most complete online competitive Pokémon battling simulator. In their spare time, developers
choose to work on whichever features or bugs they are interested in/view as important, and there is no easy way to enforce a certain roadmap/set of priorities on the people who choose to contribute (as awesome and inspiring as Zarel is, he cannot command people to work for him for free, and neither can you).
As a result, the only way to you will be able to ensure a feature or suggestion gets implemented is to
fork the code and add it yourself, or somehow convince someone with the skills to do it for you (just like you can’t force an RU main to main DPP OU if they don’t want to - we’re all just playing Pokémon on the internet for fun at the end of the day). However, while nothing is stopping you from adding a feature to your own version of Pokémon Showdown, not every feature (or implementation of said feature) will necessarily be accepted into the main codebase used by most users of the simulator - in order for a project like Pokémon Showdown to succeed in the way that it has requires that features are first evaluated for how they might fit into a cohesive vision of the final product. Accepting and implementing any and all features would quickly result in a cluttered and unmaintainable mess that would likely collapse under its own weight.
Developers who contribute to Pokémon Showdown are often looking for inspiration and ideas, and are almost always going to be interested in working on high impact features that will benefit many users provided the features are a good match for their particular skill set/area of expertise. However, just because feature suggestion is popular/well received and
seems simple to implement does not mean anyone is obligated to work on it, or even that any given developer would be able to take it on. Trust that developers
do read this forum and
do evaluate the feasibility and appropriateness of everything suggested here.
Codebases
At a high level Pokémon Showdown consists of two main codebases, the
client (the code that runs on a user's computer, in their browser/standalone desktop client and which powers the user interface) and
server (the logic that runs on the server which the clients connect to and communicate with), as well as a very small amount of restricted-access private code which is not open source. Features may require changes to any or all of these codebases, and exactly which parts of Pokémon Showdown need to be changed impacts how ‘difficult’ a change is perceived to be and what subset of developers contributing to Pokémon Showdown may be able to make the change. In general, in order of difficulty:
- features which involve only server changes
- there are more developers familiar with the server code
- more of the codebase is typed and there are more tests, meaning developers can more confidently make changes and add features without causing regressions/breaking things.
- changes can usually be verified locally on the developer’s machine, unlike with client changes where bugs may exist on esoteric combinations of legacy browsers and systems that the developer may not have access to
- changes can often be 'hotpatched' and take effect instantaneously, without requiring a restart
- features which only involve client changes
- less contributors (partially due to the fact that anyone can host their own server, while hosting a custom client is currently significantly more difficult, though also because frontend development is more specific than backend work)
- testing is often slower because it must be done by poking around in the UI. Setting up automated tests for the client is significantly more work and substantially more brittle than the equivalent tests would be on the server (this is true for UI work in general, not just the Pokémon Showdown codebase)
- possibly conflicts with work on the Preact client (see below)
- features with involve both client and server changes
- may involve changes to protocol (how the client communicates with the server) and could affect other clients (like bots)
- often take longer to be deployed, as the client and server rollout occasionally must be coordinated (usually the client changes need to land and be pushed out to users first so that the new clients can understand what the server sends them)
- features which require persisting data in some way
- usually on the server, though data may be persisted on clients as well
- most Pokémon Showdown data is simply stored in flat files, which are often relatively straightforward to deal with, but which also doesn’t necessarily scale
- some data (information about users, replays, the ladder) is stored in a more traditional relational database, but making changes to the way this data is stored (schema changes) involves complicated planning and can only be performed by administrators with access to the server
- often requires more involved setup/are more difficult to test/involve multiple moving pieces and components
- these changes require the most upfront design and are almost always the most technically challenging, meriting thoughtful technical discussion and involvement from multiple (usually senior) developers
- features which involve private code
- some Pokémon Showdown code is not open source (eg. certain code dealing with filters and other sensitive features, previously aspects of the replay viewer which have since been made public), and can only be viewed and modified by admins (who also are most likely to have the least time for implementing new features, as they are usually concerned with bigger issues/keeping the lights on)
The
client codebase is currently undergoing a rewrite (the 'Preact client refactor’, named as such because the new client is being built on top of the
Preact framework). The old version of the client has a lot of
technical debt which limits the ability for developers to easily make changes and the rewritten client will hopefully fix existing issues and improve robustness and developer velocity going forward. This rewrite has been the main focus of Zarel for a number of months, and is the reason why many larger features have been put on hold (other developers making substantial client changes during the refactoring is akin to Zarel being in the middle of performing open heart surgery and other doctors dropping by and trying to add new organs in the middle of the process). The rewrite has been taking longer than expected because Zarel also has to continue to oversee other aspects of Pokémon Showdown and can't exclusively dedicate 100% of his time to the rewrite as he might like.
It should be noted that Zarel is
rewriting the new client with many of the popular and long standing feature suggestions in mind, such that these features will be designed in from the beginning as opposed to being bolted on/shoehorned into the old client. The rewrite also renders a lot of proposed changes moot - for example, tweaks to the current team builder at this point are mostly wasted effort as the team builder is completely changed in the Preact client (though ideas for improving team building in general are still encouraged - they may still be relevant to the new design as well!).
