Can you trade GBA Pokémon locally on Steam Deck?

Identify the emulator first

This page covers standalone mGBA configured through EmuDeck on SteamOS. It is not a guide for the RetroArch mGBA core, melonDS or an Android app. Open the Deck overview if you need the first GBA setup.

Before starting, check the creator's documentation for both games: does that exact release retain trading, and are these versions intended to communicate? A shared Emerald or FireRed base is not a compatibility guarantee.

Open the documented local multiplayer path

1. Back up each game and cartridge save, then open standalone mGBA in Desktop Mode.
2. Choose File → New multiplayer window.
3. In each window, open Tools → Settings → Controllers and select the intended controller. EmuDeck lists player-specific controller entries; verify them on your setup.
4. Load the appropriate game in each window and verify that inputs reach the intended player.

Follow EmuDeck's mGBA multiplayer section. Its note for trading with yourself calls for a second copy of the save with a .sa2 extension. Preserve the original and confirm which player save each window actually loads.

Check each player's progress before a trade

Inspect the team and location in both windows. If both unexpectedly show the same progress, stop and resolve the player-save selection first. Do not proceed merely because two game windows are visible.

For an initial check, use disposable save copies. Verify the game's own connection requirements and normal trading flow. After the test, use the game's Save command where appropriate, close normally and reopen each player to inspect the result.

This is a suggested verification procedure, not a completed trade by Pocket Deal Radar. Keep both original saves until each result reopens correctly.

What if a Pokémon hack cannot connect?

Separate three questions: did the second window open, did each player load the intended save, and does the game support this link interaction? A failure in the third question is not resolved simply by changing a filename.

Record the two releases, mGBA version and connection symptom. Consult the maker's trading limitations before replacing software or trying another build. The game catalog provides creator starting points; it is not a tested trading matrix.

Other multiplayer labels mean different things

A local multi-window session is not evidence of internet play or trading between a Steam Deck and a separate physical handheld. Libretro's mGBA core page lists netplay as unsupported; that is a separate software path from this standalone guide.

For Nintendo DS Pokémon, start with the DS handheld guide. Do not apply GBA save extensions or this multi-window procedure to a DS game.

Prepare a two-player record before opening the link menu

Write down which game and save belong to each player. If you are copying one playthrough for a self-trade experiment, both copies may initially have the same trainer and team. That is expected for a copy, so identical trainer names alone cannot tell you which file a window loaded. Record the actual files as well.

Do not assume that a copied save makes every interaction valid. The game's own restrictions still matter. If the creator replaces trade evolutions with another method, check that method before spending time setting up a link session solely for an evolution.

Work through a failed trade in order

1. Window: can both games run individually? A game that does not load by itself needs a first-launch investigation before multiplayer troubleshooting.
2. Input: can you move or open a menu in each intended window? If one controller operates an unexpected player, resolve that assignment before entering the trading room.
3. Progress: do both players have the intended cartridge saves? Stop if one window starts a new game or shows an unexpected team.
4. Game interaction: can each player reach the correct connection menu and satisfy its requirements? Record the exact message instead of interpreting every refusal as an emulator failure.
5. Persistence: after an apparently successful interaction, does each player's intended result appear when reopened through Continue?

For example, suppose both windows open but player two has no Continue option. The next task is identifying the second player's save, not repeatedly attempting the trade. Conversely, if both correct saves load and the game refuses a connection, collect the two releases and the refusal message for the creator's support route.

These are diagnostic examples. They do not establish that a particular hack, pair of releases or controller combination completes a trade on this hardware.

Retain both player results after a self-trade test

A self-trade starts with two working player files, possibly copied from one adventure. Once the interaction changes them, decide which result belongs to each player before reorganising or archiving files. Do not collapse them into a single “latest save” merely because the initial trainer names matched.

1. Record the Pokémon sent and received in each window, using an identifying detail where needed.
2. Follow the game’s normal save sequence and close the test normally.
3. Reopen each intended player file separately through Continue and inspect the resulting party or storage.
4. Keep the two result files, game/build information and original pre-test backups distinguishable.

Example: the exchange appeared successful, but reopening player two shows its original party. Retain both result files and the original backups. The question is now which file was written and loaded for that player, not whether the trade animation appeared in player one.

When exporting the test, use the two-adventure inventory and inspect the actual file contents rather than a shortcut to them. This is an editorial verification procedure, not evidence that a particular hack or evolution completed on a physical Deck.

Continue with your setup

Steam Deck OLED: full overview · All Pokémon handheld paths