Hi, I wanted to suggest a possible addition to poke-env for local training and evaluation workloads.
Right now, even fully local runs go through a full Pokemon Showdown server over websockets. That works of course, but it also means we pay server startup / matchmaking / websocket overhead even when we just want to simulate battles locally.
In a small prototype on my side (still haven't solved all the issues or have full functionality), the main bottleneck was not per-turn decision logic, but battle startup/reset overhead. Using a local BattleStream / simulate-battle subprocess instead of the websocket server path made resets much faster and improved end-to-end throughput for training episodes.
More specifically, the Showdown side of this would use BattleStream / simulate-battle. The reason this seemed worth exploring is that it does not look like relying on a purely private internal detail: Showdown exports BattleStream, documents the simulator / stdio flow, and ships examples for using it directly. So this seems like a real interface for external tools, even if it is not the main path most bots use today.
The idea would be:
- keep the current websocket/server path exactly as it is
- add a second, optional local backend based on Showdown’s BattleStream / simulate-battle
- use that backend only for local battles where a full Showdown server is unnecessary
This would not mean moving simulator logic into poke-env. The simulator would still be Pokemon Showdown. The only thing that changes is how poke-env talks to it:
- current path: poke-env -> websocket/http -> Showdown server
- proposed path: poke-env -> local BattleStream subprocess via stdio
I think this can be added without radically changing poke-env internals if the transport layer is given a small abstraction. Roughly speaking:
- Player and the battle objects can stay mostly the same
- battle parsing and order generation can stay the same
- the main change would be introducing an optional backend/session layer under the current client
- the existing PSClient would remain the websocket implementation
- a new local client/backend could feed the same battle protocol messages from BattleStream
So the public API could stay mostly unchanged, with something like:
-websocket backend as the default
-optional local backend for local simulation / training
This seems especially useful for AI training setups, where battles are short, resets are frequent, and server overhead matters a lot.
I’m not suggesting replacing the current approach. Just adding a second path for local simulation that trades some backend complexity for better local throughput.
If this sounds reasonable, I’d be happy to try and implement it myself. Not sure if it will end working but I'd like first if you would be interested in adding something like in the codebase. If this is mainly used for ml/rl training purposes, I think this would end up quite useful as it would remove one major bottleneck.
Please tell me what you think about this
Hi, I wanted to suggest a possible addition to poke-env for local training and evaluation workloads.
Right now, even fully local runs go through a full Pokemon Showdown server over websockets. That works of course, but it also means we pay server startup / matchmaking / websocket overhead even when we just want to simulate battles locally.
In a small prototype on my side (still haven't solved all the issues or have full functionality), the main bottleneck was not per-turn decision logic, but battle startup/reset overhead. Using a local BattleStream / simulate-battle subprocess instead of the websocket server path made resets much faster and improved end-to-end throughput for training episodes.
More specifically, the Showdown side of this would use BattleStream / simulate-battle. The reason this seemed worth exploring is that it does not look like relying on a purely private internal detail: Showdown exports BattleStream, documents the simulator / stdio flow, and ships examples for using it directly. So this seems like a real interface for external tools, even if it is not the main path most bots use today.
The idea would be:
This would not mean moving simulator logic into poke-env. The simulator would still be Pokemon Showdown. The only thing that changes is how poke-env talks to it:
I think this can be added without radically changing poke-env internals if the transport layer is given a small abstraction. Roughly speaking:
So the public API could stay mostly unchanged, with something like:
-websocket backend as the default
-optional local backend for local simulation / training
This seems especially useful for AI training setups, where battles are short, resets are frequent, and server overhead matters a lot.
I’m not suggesting replacing the current approach. Just adding a second path for local simulation that trades some backend complexity for better local throughput.
If this sounds reasonable, I’d be happy to try and implement it myself. Not sure if it will end working but I'd like first if you would be interested in adding something like in the codebase. If this is mainly used for ml/rl training purposes, I think this would end up quite useful as it would remove one major bottleneck.
Please tell me what you think about this