Before Ubisoft Montreal, before Far Cry and Assassin’s Creed, I spent a year in Paris making robots behave.
Aldebaran Robotics (later acquired by SoftBank) was building humanoid robots for consumer and professional use. I worked mostly on Pepper: a 1m20 robot moving on three wheels, with a tablet on her chest as a second interface, designed to interact with people in homes, hotels, hospitals. The kind of robot that looks at you and makes you feel, instinctively, like something is home.
I had no idea at the time how much this year would shape the way I think about game AI.
Docking, planning, and the physical world
My main responsibility was the recharge station. Sounds simple. It wasn’t.
Getting Pepper to find her dock autonomously meant solving a chain of problems: detecting the station, navigating towards it, rotating precisely to present her connector, attempting the connection, handling failure gracefully, retrying. Each step had edge cases. Each edge case had consequences.
I also built a scheduling app, accessible via the chest tablet, that let users define when Pepper could go recharge on her own. At night, between shifts, whenever. The robot would plan around it.
The second big project was a “come here” app. You’d say “Pepper, come here” and the robot would try to locate you from the direction of your voice, scan for your face to confirm it had the right person, navigate towards you, and follow if you moved. Perception, confirmation, navigation, tracking, all chained together, all running on a robot that existed in the real world, with real consequences if something went wrong.
The physical world doesn’t forgive
In a video game, an NPC walking into a wall is ugly. Maybe a little embarrassing. You file a bug, fix it next sprint.
In real life, that same collision means knocking over your TV. Or your grandmother’s vase. Or, if the software crashes at the wrong moment, a robot falling near your cat.
The physical world has no respawn. No reload. Every edge case that slipped through wasn’t just a visual glitch, it was a liability. That pressure forced a kind of rigor I hadn’t needed before. You couldn’t just make the happy path work beautifully. You had to think about every failure mode, every degraded state, every “what if this goes wrong while someone is nearby”.
That instinct, thinking about failure before thinking about success, never left me.
Believable, not smart
Here’s the thing nobody tells you about AI: intelligence is overrated.
Users don’t need the robot to be smart. They need it to feel right. To react appropriately when something unexpected happens. To never just… stop and stare blankly at a wall.
Pepper could speak, but the TTS wasn’t that great at the time and it simply wasn’t enough. So we leaned into lights, sounds, animations: a vocabulary of non-verbal expression, not unlike what R2-D2 does in Star Wars. A series of tones and frequencies that convey emotion without words. Subtle movements. Reactions. The goal wasn’t to fool anyone into thinking they were talking to a person. It was to create enough of a signal, enough life, that people wanted to keep interacting.
That lesson hit differently a few years later when I was working on crowd AI in Assassin’s Creed Origins.
I was implementing NPC reactions: what happens when the player blocks a path, disrupts a routine, stands in the middle of a crowd. The naive solution is to wait: stand still, pathfind again, retry. But waiting looks dead. It breaks the illusion.
Instead, I built a cascade of fallbacks. If an NPC couldn’t reach their destination, they wouldn’t freeze. They’d react, visibly frustrated, muttering, glancing at the obstruction, and then move on, find something else to do, adapt. Not because the AI was smarter. Because it behaved like something with agency.
That’s the thing robotics taught me: you don’t always need to solve the hard problem. Sometimes, you need to solve the visible problem. Make the failure look intentional, and nobody notices the failure.
But it also taught me something even more valuable: take the time to try things, even the most absurd ones. That’s where you’ll find gold.
The day we found out a robot can tow five people
Every Friday afternoon at Aldebaran, I took the time to experiment. No tickets, no specs, just the robot and whatever I felt like building.
One week, I made a “Mario Kart” app (modestly named Pepper Kart). The idea was simple: sit on your office chair, legs around Pepper’s base, and let her pull you along. Grab her arms and move them left or right to turn, twist her wrist to accelerate. To add more flavor, hit the bumper covering the wheels or touch the tablet to force an emergency brake on your opponent. Fun, harmless, a bit absurd. Obviously, I passed it around, so that my colleagues could try it.
A few days later, QA came to find me.
“We now know,” they said, completely deadpan, “that a robot can drag five people.”
Apparently, five of my colleagues had decided to sit in office chairs, hold onto each other in a chain, and let Pepper pull the whole convoy. The robot obliged, determinedly, faithfully, for a few glorious minutes before the engine burned out completely under the load.
I never did find out whose idea it was to add the fourth person. Or the fifth.
One year in robotics. One burned engine. And a way of thinking about AI that I’ve carried into every game I’ve shipped since.
Make it believable. Plan for failure. And if you give an engineer carte blanche on a Friday afternoon, you might get a wonder.