Not open for further replies.


Always more to find
is a Site Content Manageris a Battle Simulator Administratoris a Programmeris a Member of Senior Staffis a Community Contributoris a Top Researcheris a Top Tiering Contributor
Research Leader
Welcome to the Suggestions forum for Pokémon Showdown! This is the place for developers to find popular suggestions from the community to be implemented and for aspiring developers to get into contributing to the site.

Check out the current suggestions, sorted by popularity, to see if your idea has been suggested before. If it hasn't, feel free to create your own thread with as detailed an explanation of your idea as possible so the community can visualize it. Suggestions deemed to be duplicates will be merged into an existing thread.

If you like a suggestion you've read, make sure to give it a positive reaction!

Note: Suggestions for new battle formats, new public/private rooms, or things Pokémon Showdown otherwise has no control over do not belong here. If you'd like to suggest a format or a change to an existing one, read the format suggestions guidelines and rules.
Last edited by a moderator:


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.


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


Not a Yuyuko fan
is a Site Content Manageris a Battle Simulator Administratoris a Programmeris a Pokemon Researcheris an Administrator
Creator of PS
Remember, we built this forum so suggestions can be easily sorted by popularity, to help me and other developers decide what to prioritize.

And popularity is determined by reaction count – so give the first post in a suggestion's thread the Like (Luvdisc) reaction, if you want that suggestion implemented.
Last edited:


Some clarification on the tags used in this forum:
  • Pending: All new threads get the 'Pending' tag assigned by default - staff may or may not have seen/evaluated the suggestion for feasibility and desirability.
  • Approved: 'Approved' threads do not mean 'Planned', 'Guaranteed', or that someone wants to implement it, it purely indicates that at least one member of staff thinks that the feature makes sense/is a reasonable request that someone could probably work on with the expectation that the feature is unlikely to be rejected during code review. However, this is not a terminal state - an 'Approved' feature may eventually be moved back to 'Pending' or even be later 'Rejected' after further discussion or due to changes in the codebase or project vision. 'Approved' features are generally good candidates for people looking to contribute to Pokémon Showdown to consider implementing.
  • Rejected: Suggestions which are not a good fit for Pokémon Showdown at this time will be tagged with 'Rejected', usually with an explanation of why they are not currently feasible/desirable. While its possible a 'Rejected' suggestion could eventually become 'Approved' (maybe something was overlooked/the code changes enough to make it more feasible/etc), continuing to post in a 'Rejected' thread or continuing to suggest similar features is unlikely to be productive and will more often than not make it less likely that such a feature would ever get implemented.
  • In Progress: An 'In Progress' suggestion is one that a developer has actively begun working on, however, there is no guarantee it will be finished or actually make it into Pokémon Showdown.
  • Done: Threads are tagged as 'Done' once the suggestion has been implemented and work is complete (though even 'Done' features could have bugs/require additional followup).
Not open for further replies.

Users Who Are Viewing This Thread (Users: 1, Guests: 0)