How I built
Captain Copilot

It started at an away day

All of my customers know that I like a fun demo. Sometimes a silly one. So when I went to an away day and saw a physical escape room that WM Reply had built, it got me thinking.

Could I do something like this virtually? And could I use it to teach people how to use Copilot?

I started brainstorming with Copilot Chat. There wasn't much of a plan at this point. I had an idea, and we started working through what it could look like.

We ended up with Captain Copilot. A world-famous spy who is a bit lazy and not nearly as useful as he thinks he is. You're the Analyst. You help him investigate Admiral Analogue's plan by solving puzzles in Word, Excel, Outlook, PowerPoint and Teams.

It's inspired by escape rooms, but it isn't really an escape room. I think interactive Copilot detective game describes it better.

Originally, I was going to host it

The first plan was to host the game myself and give everyone a link. Simple. Except I was worried about someone accidentally giving me work data.

The game only needs its fictional evidence. I didn't want a player copying something from their real job into it. I thought about asking people to disable Work IQ, but that felt like a confusing first instruction for someone who was only just getting started with Copilot. It was an idea I considered, not a setting I wanted the game to rely on.

So I settled on a big warning not to upload work data, with an “I agree” tick box before you could play. Something along the lines of “I WILL NOT SEND WORK DATA TO THE GAME.” Not exactly the most welcoming start to a fun demo.

I showed it to a Copilot adoption lead at one of my customers. Their response was very straightforward:

“Could you give me a copy to host myself?”

My first thought was that this would be too much work. If installing a training game meant asking IT to spin up a hosting environment, there was a good chance it would never get installed.

Then I remembered a roadmap item I'd read: Microsoft 365 roadmap 569208, about rendering uploaded HTML pages in SharePoint. Could we use the SharePoint site they already had?

I started experimenting. I uploaded small test pages to find out what SharePoint would actually run. The answer was not “everything that works in a browser.” In the environment I tested, scripts and embedded images could work, but browser storage and ordinary audio and video playback were blocked. Navigation needed some attention too.

So we had to rebuild parts of the game. We carried the case pages inside a single HTML file, adapted the animation and narration, and worked around the restrictions we'd measured. The testing notes were worth keeping: they told us what we could rely on in that environment, rather than what we hoped would work.

Eventually, we got it running. A customer could host the game in their own SharePoint, without setting up a separate web server. That changed the whole deployment plan.

It didn't make it sensible to put real work data into the puzzles. The instructions still tell players to use the fictional evidence. But it meant I wasn't hosting their game, and the downloadable game doesn't send gameplay data back to me.

One problem we spotted quite early

Every customer's environment is different. Different files, different permissions, different information for Copilot to find. How could we make a puzzle work if everyone was getting a different answer?

We decided to give people the documents one by one, as they needed them. That way, everyone starts with the same evidence. Copilot won't necessarily use the same words, but the information needed to solve the puzzle is there.

It also meant we didn't need a Learning Manager or Comms Manager to set up and maintain an environment just for the game.

If it needs someone to keep fixing it, we've made it too complicated.

I wanted it to be really easy to install, and need no routine maintenance between runs. No updating files for the next group. No repairing the spreadsheet after each person has had a go.

The organiser downloads a ZIP, extracts it, uploads the eight game files to SharePoint and shares the link. The player opens the evidence in their own Office apps, so their work doesn't change the files everyone else needs. They still need a Microsoft 365 Copilot licence and the right access, of course.

It worked. It just didn't look right.

Once I had a very loose outline, I moved to GitHub Copilot. I was using the newly released GPT6 Astra. I was making progress with the game engine, but I wasn't getting the visual design I wanted.

So I asked Copilot Cowork to have a go. It had access to Fable 5.1, and I wanted to see what it would come up with.

It gave me twenty design ideas. Cartoon, retro TV, stickers, villain's lair, and quite a few others. This was much more useful than asking for another small tweak to the design I already had.

I liked bits of several of them. So we combined the lair camera from The Analogue Lair, the stickers from Sticker Bomb, and the stamps and ticker from Brutalist Cartoon.

That's where the bright colours, thick outlines and slightly silly cartoon look came from. We also tried a dark neon version. Too purple. That one didn't stay.

See the original 20 design ideasFrom Saturday Morning to Sticker Bomb. Open the gallery and explore the mockups.Historical concepts / contains story spoilers

The Captain had a few auditions too

It wasn't just the website design. We tried different looks for the Captain too. A female naval captain, a secret agent, a robot, an owl... even Supergran. These are some of the original Cowork character studies, before we landed on the Captain you meet in the game.

And then I did the wrong thing

I should have taken the design back to GitHub Copilot at this point.

I didn't.

Why? Because Cowork is really, really good. I could describe what I wanted, see it working, and ask for the next change. It was hard to put it down.

And here's the thing: I've spent years as a senior SysAdmin at NHS Choices and as a consultant at Telefonica building and supporting complex applications. I know better. I've had to argue for proper process, for testing, for not taking shortcuts. I know what happens when you don't. And I still did it. Because the immediate feedback from Cowork was too good to resist.

So I stayed in Cowork and started building out the puzzles. Then the script. Then the animation. Several hours later, I was still there, running Fable 5.1 in maximum-thinking mode and asking for just one more change.

But just because I can do it in Cowork, doesn't mean I should. It could build what I was asking for. I still needed to manage the project properly.

I was also really pushing the Copilot app and my laptop. At one point, Task Manager showed Copilot using around 5.2 GB of memory. Overall memory was at 87%, and CPU at 82%. I had other apps open too, so that wasn't all Copilot. It wasn't a benchmark either. Just a fairly good indication that I was asking a lot of that session.

The problem wasn't asking Cowork for design ideas. It was staying there long after I should have moved back to a proper development workflow. I was getting the next thing working, but leaving myself a lot of tidying up to do later.

Don't copy that bit.

Eventually, back to GitHub

I asked Cowork to put together a handover package, and took that back to GitHub Copilot along with an example of the ZIP a customer would download.

Now we could sort out proper ALM: application lifecycle management. Less exciting than animating a ridiculous Admiral, but fairly important if I want to make changes without breaking the game.

We started with local Git and then moved into GitHub. GitHub Copilot helped set up the repo, the build process, the checks and the release packages:

• Source: the editable game, evidence generators, animation and voice tooling.
• Validation: checks for scripts, generated files and the behaviour we want to preserve.
• Releases: a versioned ZIP with a clearly identified set of files to upload to SharePoint.
• Handover: documentation explaining the design, build process and decisions behind it.

I wanted this to work for two sorts of people. A Comms Manager who just wants the ZIP and some simple instructions. And a technical team who might want to rebuild it, or turn Captain Copilot into a character that suits their company.

The first person shouldn't have to understand the repo. The second person shouldn't have to reverse-engineer a download.

GitHub Copilot also helped me set up this Azure site, write the installation guidance and work on the SEO. The website is where you find and download the game. The game itself runs on your SharePoint site.

Giving the characters a voice and a life

By the time I reached the first round of beta testing with colleagues, the game was taking shape. The feedback was strong, but one comment stuck with me: the Azure voices I had used sounded too robotic. The characters were on screen; they weren't yet coming across as characters when they spoke.

Luckily, my colleague Ryan Bowen had recently been experimenting with voice engines and had just published his findings in his AI Video Creation Guide. I gave this to GitHub Copilot's Researcher agent and used it as a starting point for finding voice engines that were powerful and licensed in a way that would allow me to use their output in the game.

We auditioned a lot. Qwen3-TTS emerged as the option I wanted to explore: its model and code are Apache 2.0 licensed, and its VoiceDesign model let us create original character voices from descriptions rather than imitate a real actor.

There was a hardware catch. My laptop is ARM-based, while the audio and machine-learning dependencies I needed were much happier in an x64 Python environment. GitHub Copilot helped me set up an isolated x64 environment running under Windows emulation. That let me run Qwen locally on the laptop's CPU, without sending the character recordings to a hosted voice service or bundling the model weights with the game.

The practical approach was to design an original voice, keep its sample and exact transcript as a reference, then use Qwen's smaller Base model to create more lines in that voice. The larger VoiceDesign model was useful for trying character directions; the smaller model made repeated line generation more manageable on this machine. It was not instant, and a convincing short audition did not guarantee every line would sound right in context. We had to listen, adjust, and try again.

The same principle applied to animation. Rather than make every character moment a pre-rendered film, we built reusable vector artwork and poses, then used the page's animation code to stage the scenes and calls. Speech, captions and character movement need to land together: change a line or its timing, and the mouth cues and pauses may need another pass too. Keeping much of that animation in the page also helped the game stay lightweight and work within the SharePoint delivery constraints.

The lesson was that a voice model is only one part of performance. The words, pauses, emphasis, animation and timing all have to work together. The Admiral now has a Qwen voice in the game; I'm still auditioning the right direction for the Captain before changing his production voice.

A technically impressive voice isn't automatically the right character. The test is whether the joke lands.

What I would do differently next time

I'd still start by thinking about the person playing it, and the person installing it. Making their lives easier was worth working out early.

I'd definitely ask for several design ideas again. Seeing what I liked and didn't like was much easier than trying to describe it all upfront.

But I'd get the repo in place earlier, and move the work back into it sooner. I can ask AI to build things quickly. I still need to check them, decide what to keep and make sure I can change them safely.

There will hopefully be more Captain Copilot games. Next time, I'll try to follow my own advice.

From an idea to a real game

While all of the above might sound complicated, Copilot was with me all the way. Even six months ago, I wouldn't have been able to build this game.

I have a background in getting applications into production. But I'm not a game designer, graphic designer, scriptwriter, tester or developer. Copilot filled all those roles, helping me turn an idea into something people can actually play.

I still had to decide what I wanted, listen to feedback and check the results. But I didn't have to know how to do every part before I could start.

Copilot helped me get the idea out of my head and into reality.