Most game development blogs show you the wins. This one shows you everything — the milestone we hit, the developer we let go, the networking framework decision that saved two days, and the Saturday-morning breakthrough that cracked the single hardest technical system in our entire game of My Life as a Spy. Follow week one of rebuilding My Life as a Spy, a 25-year-old multiplayer espionage RPG being recreated from scratch in Unity.
My name is Frank Salas. I’m a game producer and the founder of Rather Clever, a small indie studio. I lead production without writing a single line of code. Earlier this year, our team documented how we shipped our first indie game under intense time pressure, lessons that continue to shape our approach today. This is our Week 1 devlog for Rebuilding My Life as a Spy — a Unity multiplayer espionage RPG we’re rebuilding from the ground up — and this is everything that happened.ned.
Watch the full Devlog: Rebuilding My Life as a Spy
What Is “My Life as a Spy”?
My Life as a Spy is a persistent online multiplayer espionage RPG that has been running for over 25 years. The version we’re building is a complete Unity rebuild from scratch — new engine, modern multiplayer infrastructure, same core gameplay DNA.
The distinction that matters most: this is not a combat game with spy mechanics bolted on. The entire economy of the game is structured to make espionage unavoidable. You run documents, earn training points and money. You purchase bugs, traps, and disguises. The game’s tension is built on information — who knows where you are, what you’re carrying, and what you’ve set up while waiting. The gameplay loop is unlike anything else on the market.
How did Frank acquire the IP for a 25-year-old active game that never left Alpha? That story is coming in a future episode. Subscribe so you don’t miss it.
The Plan: A Controlled Foundation Build of My Life as a Spy
The game’s design document runs over 250 pages and 100,000 words — longer than most published novels. It covers 33 core systems, all of which communicate with each other: combat, economy, death mechanics, espionage layers, trapping systems, faction logic, and more.
Rather than building a vertical slice or rushing toward a prototype with duct-tape code, the approach is a controlled foundation build. Each layer gets implemented correctly before the next one is added. No shortcuts that need to be refactored when the game scales.
Production runs on Trello. Every task carries a time estimate, a named owner, and a clearly defined “done” state. That structure is what makes everything else possible.
These systems didn’t appear overnight. Many of them were shaped by the lessons we learned while shipping our first indie game, where clear scope and disciplined production proved essential when unexpected challenges hit the team.
Gate Zero: The Milestone Framework Every Indie Studio Should Use
Before any real game development begins, every project at Rather Clever has to clear what Frank calls Gate Zero — a set of non-negotiable requirements the team must prove before moving into full production. Think of it as a toll booth: you cannot pass until you demonstrate the foundation actually works.
For a Unity multiplayer game development project, Gate Zero looked like this:
- ✅ The networking framework connects two clients over the internet (not just LAN)
- ✅ The server runs headless — no monitor, no GUI, just the process running in the background
- ✅ The entire team has agreed on how the codebase is organized before a single game system is built
- ✅ Remote connectivity is verified, not assumed
The value of a Gate Zero milestone is that it prevents the most common indie studio failure mode: teams that build features for weeks only to discover the underlying architecture can’t support them. Prove the foundation first. Build everything else on top.
Applying This to Your Studio: Before starting any new game project, define your own Gate Zero. Write down the 3–5 technical and organizational questions whose answers must be “yes” before feature development begins. Put them in your project board. Treat it as a ceremony, not a checkbox.
The Week 1 Team
Tech Lead — Seven years of experience, shipped titles on Android and Steam. Owns code review, enforces architecture standards, and keeps technical debt from accumulating.
Systems Engineer — Previously built an entire multiplayer networking library from scratch (UDP, binary serialization, encryption — the full stack). Never used a production networking framework before, and had never deployed multiplayer over the internet — only local area network. Week 1 changed both of those things.
Game Systems Architect (Week 1 Evaluation) — Brought in as a third developer with Week 1 designated as his evaluation period. More on this below.
Frank Salas (Producer) — Sets scope, owns the production plan, removes blockers, and makes the calls nobody else can make.
Mirror vs FishNet: How We Chose Our Unity Networking Framework in 5 Minutes
One of the most common questions in Unity multiplayer game development is which networking solution to build on. The plan coming into Week 1 was to spend the entire week evaluating two open-source options: Mirror and FishNet.
Here is the short version of that evaluation:
| Factor | Mirror | FishNet |
|---|---|---|
| Cost | Free, open source (MIT) | Free, open source |
| Community | Larger, longer-standing | Growing, modern community |
| Documentation | Extensive, years of tutorials | Strong but newer |
| Production track record | Used in shipped games (Population: ONE) | Newer but well-regarded |
| Decision made | ✅ Chosen | Passed |
The decision took five minutes on Monday morning. Both frameworks were viable. Continuing to evaluate two good options past the point where the data is clear is a production problem, not a technical one. The call was made: Mirror. Stop evaluating, start building.
By end of day Monday — one day into Week 1 — the systems engineer had two clients connected on a dedicated server, moving around a test space and seeing each other’s positions in real time.
See the first multiplayer connection moment in the video above of My Life as a Spy.
Why We Played the Game Before We Built My Life as a Spy
No game design document — regardless of how thorough — can replace the experience of actually playing the game. Before the team wrote another line of backend code, three structured play sessions were scheduled across the week. Each one had a specific objective. Each developer was required to document observations and bring design questions to the debrief.
Session one was a cold-start — developers went in with no briefing, experiencing the game the way a new player would. Session two introduced a significant change in dynamic. And session three? The team finally started to feel the real sting of the game’s core mechanics.
Watch the video to see what happened when Frank logged in with his highest-rank character and what “sharks versus snorkelers” actually looks like in a 25-year-old spy game. The play session sequences are genuinely something you have to see to understand why the team’s entire perspective on the game shifted.
By the end of roughly seven hours of structured gameplay across the week, the developers understood the game at a level that 250 pages of documentation never could have delivered. They felt the economy, felt the tension. They understood, from inside the experience, why the espionage loop is built the way it is.
The Hard Call: Managing a Remote Game Development Team of My Life as a Spy Means Protecting It
The third developer — the game systems architect hired for Week 1 evaluation — was not a poor developer in technical terms. His written analysis of the game after the play sessions was genuinely impressive. His game design instincts were sharp.
The problem was scope discipline. Every project at Rather Clever maintains a strict in-list and out-list for every system at every phase. Features on the out-list exist for a reason — they either belong in a later phase or they compromise the structural integrity of the foundation layer. This developer kept building out-of-scope features, acknowledged they were out of scope while doing so, and could not provide consistent ETAs on assigned tasks after being asked directly, three times.
By day two, the signal was clear. By day three, the developer himself acknowledged it wasn’t the right fit and the relationship was ended cleanly, professionally, with full payment for time worked.
Producer principle: Building evaluation periods into your hiring plan isn’t a way to be harsh — it’s a way to be honest. Acting on a clear misalignment at day three instead of day thirty protects the project, the existing team’s momentum, and the departing developer’s time. The biggest team management mistake in indie studios isn’t hiring wrong; it’s waiting too long after you know.
What happened next made the decision even clearer in hindsight.
Two Developers Shipped More Than Three in My Life as a Spy
After the team dropped from three to two, something notable happened: output accelerated.
On Wednesday morning, the systems engineer achieved remote internet connectivity — the single highest technical risk item on the entire Week 1 plan, solved ahead of schedule. The camera controller was built. An interactable framework was in place. Players could enter headquarters buildings, trigger secondary interactions, and move across a greybox map. The sprint mechanic was implemented.
The back half of the week, with two developers, produced more functional game systems than the front half with three. Team composition matters more than team size. Alignment and focus are what actually drive output.
Friday: Gate Zero Passed
Friday morning, 10:00 AM. Gate Zero ceremony on Google Meet.
The systems engineer demonstrated the headless server live — remote connections established, server console logging connections, disconnections, timestamps, and player identifiers in real time. The tech lead walked the team through the character controller and the interactable framework inside the early district greybox.
Every Gate Zero requirement: met. Most of them: met ahead of schedule. Achieved with two developers instead of three.
The project is now cleared for full game development to begin.
Saturday Free Exploration: The Rule That Already Paid for Itself in Week 1
Every Saturday at Rather Clever, the development schedule opens into free exploration time. The only rule: whatever you build must be relevant to the game at its current phase, and nothing gets merged until it’s reviewed on Monday. No polish features, no out-of-scope experiments — but within that boundary, complete creative freedom.
The practice is modeled after Google’s 20% time policy — the internal program credited with producing Gmail and Google Maps. The core insight is that genuine creative energy cannot be scheduled into a task card. You can only set up conditions where it has room to emerge.
What happened on the first Saturday free exploration session:
The tech lead decided to investigate fog of war — the single most technically demanding system in the entire game. In My Life as a Spy, visibility works through a 120-degree vision cone, walls fully block line of sight, and corners provide only a narrow sliver of visibility past their edge. Nobody assigned this. He was just curious.
Within three hours, a working vision cone with ray casting and wall occlusion was running. Zero to functional prototype in one Saturday morning — on the hardest system in the game.
Meanwhile, the systems engineer explored a different fog of war approach, hit a dead end, reverted his changes cleanly, and pivoted to expanding the server console’s admin capabilities. One developer found a breakthrough. The other failed fast, cleaned up, and redirected. Both behaviors are exactly right.
Saturday free exploration is now a permanent fixture of the Rather Clever production schedule.
The Character Models : Building Agent Identity
The character model is the one visual element every player will always associate with their in-game identity. Getting it right matters. Frank spent two weeks moving from initial concept sketches to mockups, then used an AI-assisted production workflow to generate all five agent color variants personally — red, green, black, purple, and ivory.
The animations are rough. The models need a professional 3D artist’s polish pass. This is pre-alpha work from the end of Week 1. But the color language, silhouette direction, and visual identity are locked.
If you’re a 3D character artist who wants to be part of building this game, reach out via the Discord link below.
5 Game Producer Lessons From Week 1 (My Life as a Spy-Expanded)
1. Team Alignment Outperforms Team Size
Two developers who share a clear scope and architectural agreement will consistently outproduce three developers navigating ambiguity. Before adding headcount to a game development team, ask whether the current team is fully aligned — on scope, on architecture, on communication expectations. If the answer is no, adding more people adds more friction, not more output.
2. The Producer’s Job Is to Remove Ambiguity, Not Assign Work
One Slack message redirecting the systems engineer from researching hosting providers back to building the actual prototype likely saved two full days. The producer role in indie game studio management isn’t about telling engineers what to code. It’s about protecting their time and focus from everything that isn’t the next most important task. Every hour of decision overhead is an hour of building time lost.
3. Structured Play Sessions Are a Development Tool, Not a Perk
Game design documents communicate intent. Play sessions build intuition. When developers experience the economy, the tension, and the failure states of a game firsthand — especially when they lose — they internalize design principles that written documentation can only describe from the outside. Schedule structured play time as a production task, not as optional team bonding.
4. Build Evaluation Periods Into Every New Hire
The evaluation period is not a trial — it’s a structured window for both sides to answer a real question: is this the right fit for this project at this phase? Build it into the production plan explicitly. Define what success looks like in week one before week one begins. Act on the signal when it appears instead of waiting for it to become a larger problem.
5. Scheduled Freedom Produces Unscheduled Breakthroughs
The fog of war prototype that came out of Saturday free exploration was not on the development roadmap for weeks. It happened because one developer had protected time to follow his own curiosity without it being assigned, evaluated, or turned into a task card. In indie game development, some of the most valuable technical progress comes from giving your team explicit permission to explore — with clear boundaries about what “explore” means in the current phase.
Frequently Asked Questions for “My Life as a Spy”
What is Mirror networking in Unity?
Mirror is a free, open-source networking library for Unity game development. It handles the client-server architecture for multiplayer games, including player synchronization, remote procedure calls, and server-authoritative gameplay logic. It is one of the most widely used solutions for Unity multiplayer game development and has shipped in production titles including Population: ONE.
Mirror vs FishNet — which should you choose for Unity multiplayer?
Both are free, open-source, and production-viable. Mirror has a longer track record, a larger existing community, and more available tutorials — which matters significantly for teams without prior production multiplayer experience. FishNet is more modern in its architecture and well-regarded in the Unity community. For a team going into internet-deployed multiplayer for the first time, Mirror’s documentation depth is a meaningful advantage. See the comparison table above for more details.
How do you implement fog of war in Unity?
A common approach for top-down or isometric games involves ray casting from the player’s position within a vision cone (commonly 90–120 degrees), with rays checked against wall colliders to determine occlusion. The result is a visibility mesh that updates each frame. The Rather Clever tech lead implemented a working version of this system — 120-degree vision cone, ray casting, and wall occlusion — in a single three-hour free exploration session. For a deep technical breakdown, watch the devlog video above.
What does a non-technical game producer actually do?
A non-technical game producer does not write or review code. The role is to define scope, set priorities, remove blockers, manage team dynamics, enforce deadlines, and protect the team’s focus from things that would slow development down. Frank Salas leads Rather Clever as producer without touching the codebase — all technical decisions are owned by the development team within the scope and constraints the producer defines.
What is a Gate Zero milestone in game development?
Gate Zero is a structured pre-production milestone that requires a team to prove a defined set of foundational requirements before entering full feature development. For a multiplayer game, this typically includes verifying internet connectivity, headless server operation, and codebase organization. It functions as a technical and organizational checkpoint that prevents teams from building features on an unstable or unverified foundation.
How do you manage a remote game development team across time zones?
The Rather Clever approach relies on four elements: structure (Trello-based production with every task carrying a time estimate, owner, and definition of done), clear communication channels (Slack for async updates, scheduled calls for milestones and reviews), accountability (evaluation periods built into hiring, clear scope documents), and trust (Saturday free exploration gives developers ownership over part of their week). Communication overlaps are scheduled around time zone differences, and async-first communication is the default.
What’s Coming Next
Week 2 involved a significant number of developer interviews and screening sessions. The team is actively being rebuilt after Week 1’s transition, and there are developments in the pipeline that will show up in the next devlog.
And the story that’s still coming: how Frank acquired the full IP for a 25-year-old online game that never left its alpha phase — a creator he had been tracking down for 25 years, and a conversation he had been thinking about since he was 13 years old. Subscribe to the channel. That story is worth waiting for.
Follow the Build — Join the Community of My Life as a Spy
This channel documents everything: the wins, the hard calls, the technical milestones, and the decisions most devlogs skip. If you’re a game developer, a producer, or someone who cares about how games actually get made — subscribe and follow along.
For daily development updates, behind-the-scenes posts, and the chance to follow the build in real time, join the Rather Clever Discord — link below.
If you have a game concept and you’re ready to invest in bringing it to market, visit SalasGames.com. Rather Clever takes on contract development partnerships. If it’s the right fit, we build it together.
My name is Frank Salas. See you in Week 2.