Office Hours Recap: How to Use XBOX PC Remote Tools to Help with Build Iteration

Game dev can be hard. There’s a lot to learn, social networks to build, and always new problems to solve. XBOX wants as many game developers to succeed as possible, and we want to help you on your journey. That’s why, every Friday morning at 11:00 AM Pacific, we invite the game development community to join us on our official Discord for Office Hours.

By creating an open and welcoming community space, one where you can make connections with real industry professionals and ask questions about the issues that are most important to you, we’re making more resources accessible to developers of all sizes from across the globe. Each week, we invite an experienced game developer to join us, tell their story, and answer any questions you might have about their work. If you’d like to keep up with who will be joining us and what topic we’ll be covering, join our Discord server and keep an eye on the #announcements channel for calendar updates!

On Friday, April 24, we welcomed a few of our friends from the XBOX platform team to talk about a piece of work a lot of you have been asking about: the XBOX PC Remote Tools. With the ROG XBOX Ally and Ally X handhelds announced last year, the question of “how do I actually iterate on a handheld” is suddenly very real for a lot of studios. That’s the gap these tools fill.

Our guests were:

• Ethan - leads the team building the XBOX PC Remote Tools and the broader gaming developer tools and platform at XBOX. He’s been at XBOX for a long time, has worked inside first-party studios as well as on the platform side, and frames his job around taking the pain out of everything that isn’t actually making the game.
• Steven - started at XBOX around 2011 working on developer tools, and he’s been building developer tooling for the 360 and every console since. (For the folks who lit up the chat at the mention of XNA, yes, that’s the Steven you’re thinking of.)
• Felipe - focuses on XBOX PC Remote Tools. Felipe joined XBOX a couple of years ago after a career in esports and event production, with software development experience earlier in his career. He’s based in Costa Rica.
• Bunmi - is a member of the team focused on the device provisioning and setup via the XBOX PC Toolbox application who jumped in to drive the demo from the original GDC presentation.
• And in the recorded demo we played: Jon - with the XBOX Advanced Technology Group, who specializes in Unity input and services including stats and achievements.

If you weren’t able to join us live, here’s what we covered.

What are the XBOX PC Remote Tools?

The first question of the session, from Williem in chat, was the right one to start with: are these tools for running test builds on remote platforms like handhelds, or are they for cloud-style remote development?

Ethan was quick to answer. “It is absolutely the former.” After XBOX announced the partnership with ASUS for the ROG XBOX Ally and Ally X, developers came to the team almost immediately and said: we want to iterate our games remotely on this handheld, but we’re not going to run Visual Studio on it. Can you make that easier?

That’s the whole point. The tools let you work on your dev PC, deploy your build to a handheld device, debug it, and verify functionality (including things like the API for detecting that you’re running on a handheld) is behaving the way you expect.

Or as Ethan put it: “These tools are really about being able to leverage remote devices that run Windows as part of your development workflow. A lot of the team comes from console, where remote iteration is the only option, and it turns out that running your build on the same device a player will use catches bugs you’d otherwise miss. Missing dependencies. Real-world performance. Things that don’t show up when you’re running everything on your dev box.”

So, this isn’t just about handhelds. It’s about giving Windows game developers a way to iterate that is closer to what gamers game on every day.

The Demo: Toolbox app, end-to-end

We played Jon’s demo from GDC.

Here’s what the flow looks like in the XBOX PC Toolbox app:

1. Install on both devices. The Toolbox app needs to be on your dev PC and on the remote device (the handheld, in this case). You can grab it from the Microsoft Store.

2. Designate each device. When you start the app for the first time, you tell it whether the device is a development device or a remote device.

3. Pair them. You pick Remote Managed Device (gives you SSH access) or Remote Iteration Only Device (no SSH, but you can still launch and deploy). Then on your PC fill in the username, device name or IP, then enter a short-lived PIN from the remote device. Give it a nickname and you’re paired.

4. Configure your project. In Visual Studio, with the XBOX PC Remote Debugger extension installed, open your project’s debug properties. There’s a new XBOX PC Remote Debugger option. Drop in the same device name you used for pairing.

5. Hit run. Your title launches on the remote device. From there you can drop breakpoints, inspect variables, and debug exactly the way you would locally.

6. Hot reload your fix. When Jon found the bug in his demo (a min that should have been a max), he edited the code, hit hot reload, and the change pushed to the remote device automatically.

If your workflow looks different, or you’ve got an automated build chain, the Remote Iteration API command-line tool covers the same ground. More on that below.

The thing Jon’s demo gets right is the rhythm. There’s no “transfer the build to a thumb stick, walk across the room, plug it in, launch it manually” step. You stay in Visual Studio, on your dev PC, with a keyboard, and the handheld behaves like an extension of your environment.

Pain Points the Tools Are Trying to Remove

Clint asked Ethan what other friction points the team is trying to take out of the workflow.

He went straight to the most embarrassing one: just getting your build onto the device. “The simple act of deployment, of getting the files across to the device in an easy and secure way, is something that isn’t easy to do with two Windows devices just out of the box.” He laughed about the drawer of USB-A to USB-C adapters and thumb sticks every dev who’s worked with handhelds has accumulated. (I’ve got a 3D-printed key chain holder for mine. We’ve all been there.)

Steven jumped in on the bigger picture. The team’s goal is to take XBOX’s 25 years of console development experience and bring it out to anyone building on Windows. Performance analysis was the example he flagged as a future opportunity. Making it easier for everyone, not just first-party studios with dev kits, to do the kind of profiling that makes a game run well on the hardware it actually ships on.

Or, as Ethan said: “We’ve been doing this for a long time, and that’s a privilege. It’s also given us a lot of opportunity to learn really what helps make game development easier.”

Debugging, Crash Dumps, and PIX

Manuel asked a great question in chat: he’s used to pulling mini dumps from the partner portal. How do remote tools fit into that flow? Is there anything local that brings the debugging experience closer?

Steven took it. The debugger support is “really just Visual Studio debugging.” It works against any Windows PC. You can attach to a running process, deploy and debug, and load a crash dump straight into Visual Studio. Nothing game-specific or special. All the standard X64 C debugger features are there.

I followed up: if the test machine has crashed and the dev PC needs the dump, do the remote tools fetch it, or is that a separate step?

Steven’s answer (with the standard “I’m not committing to a feature” caveat from me): the team is currently building functionality to copy files back from the remote device to the dev PC. It’s not in the public preview yet, but it’s on the list. Pulling log files. Pulling crash dumps. The kind of thing that today still involves “physically go touch your handheld.”

Same for PIX. Yes, PIX over the remote tools is supported, and the team has been working on making the provisioning and connection faster and easier based on internal feedback.

How to Give the Team Feedback (Please, Actually Do This)

This was the section I wanted to make sure we got to, because it’s the most actionable thing in the whole session.

There’s a feedback button in the Toolbox app. It opens the Windows Feedback Hub and the report comes directly to Steven’s team. Yes, Feedback Hub feels like a consumer thing. Trust me on this one: the XBOX tools team reads those reports. Steven gets weekly stats. The team triages them. I’ve filed issues myself just to test the loop, and they come back.

What makes Feedback Hub more useful than a manual bug report is the data it grabs automatically: memory contacts, logs, network state. Network state is a big one, because half the support stories Steven told today were “your company’s group policy has set a really aggressive firewall.” That’s not something you’d think to attach to a manual bug report.

Felipe doubled down on this. The team has visibility into the most generalized network and security setups (domain joined, not domain joined, admin rights, no admin rights, home networks, large corporate networks, shared spaces). What they don’t have is your weird specific setup. The thing you assume is too niche to bother reporting is exactly the thing they need, because if it’s hitting you it’s probably hitting other people too.

A few practical things:

• For bugs: use the Feedback Hub button in the Toolbox app. Copy the feedback ID and drop it in our Discord channel so we can correlate it.
• For feature requests: Let us know what you want and need! Please post the request in Discord and we’ll route it.
• For “I’m a Microsoft partner and I need this fixed yesterday”: you already know who to talk to. But please file in Feedback Hub anyway, because the data attached to that report is what makes the fix faster.

Steven put it bluntly: “If you have to physically go touch your handheld to finish some certain tasks, that’s something we’d like to hear about as well.”

The Public API and Command-Line Tools

One more thing that came up near the end, dropped in chat by Steven: everything we showed today is built on a public API, available on NuGet.org. There’s a C header file. There’s a Win MD file, so you can project into C#, Python, or whatever you’re using. There’s a C# WPF sample to get you started.

This matters because not everyone wants a GUI. Plenty of studios have automated build chains and want to script deployment to remote devices as part of CI. The team is shipping the GUI app, the WD Remote command-line tool, and the public APIs in parallel. Ethan called it the team’s promise to meet developers where they are. Whatever your workflow looks like, there’s a surface that fits it.

Closing Thoughts

The XBOX PC Remote Tools team isn’t building these tools because remote iteration is interesting in the abstract. They’re building them because making a game on a handheld today is harder than it should be.

If you missed the live session, the tools are in public preview now. Install them. Try the deploy-and-debug flow on your handheld. File feedback through the Toolbox app. Tell the team what worked and what made you want to throw your handheld across the room.

Thanks to Ethan, Steven, Felipe, and Boomi for joining us, to Jon for the GDC demo, and to Clint Woon for hosting. And thanks to all of you who showed up on a Friday morning (or evening, for the 60% of you joining from outside the US, which we very much see and appreciate).

If you want to keep up with what’s coming, join us on the Microsoft Game Dev Discord, watch the #announcements channel, and we’ll see you Friday at 11:00 AM Pacific.