![The New York Times Crossplay: Building the First Two-Player Game [2025]](https://tryrunable.com/blog/the-new-york-times-crossplay-building-the-first-two-player-g/image-1-1769116206049.jpg)
The New York Times Just Changed the Game. Here's How They Built It.
Last year, The New York Times did something they'd never done before. After years of dominating the digital word game space with single-player titles like Wordle and the classic daily crossword, they launched Crossplay. It's deceptively simple: two players compete in real-time on the same puzzle.
But here's the thing. Building a multiplayer word game isn't just about copying what gaming companies figured out decades ago. The New York Times operates at a different scale. Millions of people play their games daily. The infrastructure had to be bulletproof.
When you dig into what happened behind the scenes, you find something genuinely interesting. The team didn't have a blueprint. They had to invent solutions for problems that multiplayer gaming solved years ago, but in a completely different context. Real-time synchronization across millions of concurrent players. Preventing cheating and collusion. Handling network failures gracefully. Making the experience feel instant rather than laggy.
The story of Crossplay is really about technical ambition meeting product constraint. The New York Times doesn't just want to build games that work. They want to build games that feel right, that preserve the experience that made Wordle a cultural phenomenon. Adding multiplayer could have ruined that. Instead, it doubled down on what makes their games special.
Let's break down what actually happened. Why it mattered. And what it tells us about building modern multiplayer experiences at scale.
The Strategic Why: Why The New York Times Needed Multiplayer
The New York Times games ecosystem wasn't broken. Wordle became a household name. Their crossword app generates hundreds of millions in subscription revenue. The daily mini-crossword, letter boxed, and spelling bee all have devoted audiences.
So why add multiplayer? The answer reveals something important about product strategy in mature markets.
First, there's the engagement angle. Single-player games have a natural ceiling. You complete the puzzle, you're done. Maybe you come back tomorrow. With multiplayer, there's social friction that keeps people in the game longer. You're competing against someone. You want to beat them. That's engagement architecture 101, and it works.
Second, and more important, there's the cultural moment. Social gaming exploded during the pandemic. Games like Among Us and Fall Guys proved that accessible, asynchronous multiplayer could reach mainstream audiences. The New York Times wasn't trying to build a hardcore esports title. They wanted to capture the same audience that plays their crosswords with a friend over coffee.
Third, multiplayer games generate different monetization opportunities. You can charge for competitive rankings, leaderboards, cosmetics, or premium multiplayer-only puzzles. Single-player games are limited to subscription models or advertising. Multiplayer opens doors.
But here's what's interesting. The New York Times didn't just chase engagement metrics. They built multiplayer on their own terms. Crossplay isn't a free-to-play game drowning in ads. It's an extension of their subscription service. It respects the same audience sensibilities. No dark patterns. No fake urgency. Just two players, one puzzle, straightforward competition.
That philosophy fundamentally shaped the technology they needed to build.
Understanding the Technical Scope: What Makes Multiplayer Hard?
Before diving into what The New York Times built, you need to understand what they were actually building. Multiplayer games sound simple until you start implementing them.
Let's say two players start the same Crossplay puzzle at exactly the same time. They're filling in letters. One player types their first guess. The other player types theirs. Now, their local game states need to agree. If they both filled in the same letter in the same position, they see it immediately. If they filled in different letters, their game needs to show both versions and figure out whose guess is "winning."
Now multiply that by 50,000 concurrent players, each potentially in multiplayer matches simultaneously. Your server has to:
- Track the state of every active game session in memory
- Process updates from both players with sub-100ms latency
- Ensure neither player sees stale data
- Detect when someone disconnects and handle that gracefully
- Prevent cheating (nobody should be able to see the other player's puzzle or manipulate answers)
- Log game history for leaderboards
- Handle network failures without losing data
That's not a new problem. Gaming companies solved it years ago. But The New York Times operates in a different constraint environment. They can't rely on players having gaming-grade internet. Their audience spans grandmothers in rural areas to office workers on spotty Wi Fi. The experience needs to degrade gracefully.
Also, Wordle's success came partly from its simplicity. Users expect Crossplay to feel as instant and responsive as Wordle, without lag or weird network delays. That's actually harder to achieve in multiplayer than single-player.
The Core Architecture: How The New York Times Solved Real-Time Sync
The production team had to make fundamental architectural choices early. These decisions would determine whether Crossplay felt responsive or sluggish.
They settled on what's sometimes called a "client-server" model, but with a twist. Here's roughly how it works:
When you make a move in Crossplay, your client (the app on your phone) doesn't wait for the server to confirm before showing the move. Instead, it displays your input immediately. Simultaneously, it sends that move to the server. The server processes it, broadcasts it to the opponent, and both clients reconcile their states. If there's a conflict (you both guessed different letters), the server is the source of truth.
This approach has a name: optimistic UI. The philosophy is simple: assume your move will succeed and show it instantly. If the server rejects it or conflicts with the opponent's move, backtrack smoothly.
For Crossplay, this meant building robust conflict resolution. The puzzle rules are deterministic. If both players fill in the same square with different letters, the game needs to decide which one counts. The New York Times approach was to give both moves weight—it's not about who typed first, but about the puzzle's rules. If the puzzle structure requires a specific letter, that letter wins.
The backend infrastructure had to be distributed. A single server in Manhattan wouldn't cut it. Instead, The New York Times likely used multiple regional servers (or a serverless architecture running on cloud infrastructure) to minimize latency. Players in California shouldn't experience noticeably worse latency than players in New York.
They also had to choose a synchronization protocol. Rather than traditional HTTP requests (which add overhead), they probably used Web Sockets or similar persistent connections. This keeps a continuous tunnel open between the client and server, allowing instant bidirectional communication without the overhead of repeated connection handshakes.
For data persistence, they needed something that handles millions of concurrent writes. A traditional SQL database would struggle. They likely used a combination of in-memory stores (like Redis) for active game state and a more robust database for historical records and leaderboards.
Anti-Cheating: The Invisible Watchdog
Here's something that sounds easy but gets absurdly complicated: preventing cheating in a real-time multiplayer word game.
For single-player games, cheating is isolated. You cheat, you get a better score, life goes on. For multiplayer, cheating affects someone else's experience. If you're competing against an opponent and they're cheating, you're both wasting time.
The New York Times had to implement multiple layers of anti-cheating:
First, information asymmetry. Each player only sees the puzzle squares they've filled in and the opponent's filled-in squares. Neither player can see the full answer key. This is baked into the client—there's literally no way to request the full puzzle answer from the legitimate app.
Second, behavior analysis. The server watches for suspicious patterns. Someone who completes a 15-minute puzzle in 30 seconds is flagged. Someone who always guesses correctly on ambiguous words is flagged. The system builds a behavioral profile.
Third, move validation. Every move gets checked against the puzzle rules. If you try to input a sequence that violates the puzzle structure, the server rejects it before synchronizing with the opponent.
Fourth, time-based signals. Legitimate players make mistakes, hesitate, backtrack. Cheaters tend to make moves in mechanical patterns. The system can detect this.
They probably also implemented rate limiting. A player can't submit 1,000 moves per second. They can't request puzzle solutions. They can't parallelize guesses across multiple accounts. These constraints are invisible to legitimate players but kill automated cheating bots.
Network Resilience: Expecting Failure
One of the hardest parts of multiplayer games is assuming everything will break. Players will disconnect. Servers will hiccup. Networks will fail. The experience should survive all of it.
The New York Times had to implement what's called a reconnection protocol. If your connection drops mid-game, the app needs to detect it, hold your game state locally, and attempt to reconnect transparently. When connection resumes, it should reconcile your moves with the server state without you losing progress or needing to restart.
This is harder than it sounds. What if you made 5 moves locally, then connected, and the server says your opponent made 8 moves? Which moves get priority? The system needs a deterministic way to handle this.
They probably implemented sequence numbering. Each move gets a unique number. When reconnecting, the client says "I have moves 1-5, what's my current state?" The server responds with moves 6-8 from the opponent, and both states merge cleanly.
They also needed to handle partial failures. What if the server receives your move but the response gets lost? From your perspective, the move never registered. From the server's perspective, it did. The system needs to be idempotent—if the same move is processed twice, it produces the same result. This prevents duplicate moves from breaking the game state.
Timeout handling is another layer. If a player disconnects and doesn't reconnect for 5 minutes, what happens? Do we end the game? Do we wait indefinitely? The New York Times probably set automatic timeouts, with warnings. This prevents games from being "stuck" with one player MIA.
Latency: The Invisible Enemy
In competitive multiplayer, latency is everything. A 200ms delay is barely perceptible. A 2-second delay feels broken.
The New York Times had to optimize for latency across their entire infrastructure. This meant:
Geographic distribution. Rather than routing all traffic through a single data center, they distributed servers globally. A player in London connects to a nearby server, not one in the US. This cuts latency roughly in half.
Protocol optimization. Web Socket connections are faster than HTTP, but they still have overhead. Crossplay probably uses a custom protocol optimized for word games. Send only what's necessary: the move (which square, which letter), the player ID, and the timestamp. Don't send unnecessary metadata.
Client-side prediction. When you type a letter, the app immediately displays it. This is "client-side prediction." The server synchronizes in the background. If there's a conflict, the UI corrects itself, but by then you've already moved on to the next move. The latency becomes invisible.
Connection pooling. Rather than creating new connections for each request, the app maintains a persistent connection pool. Requests reuse existing connections, eliminating handshake overhead.
They probably monitored latency obsessively. Tools like Datadog or New Relic would show them percentile latencies—not just averages, but the 99th percentile. If the 99th percentile latency exceeds some threshold, they optimize further.
Leaderboards and Competitive State: Complexity Hiding in Plain Sight
Crossplay needed leaderboards. Players want to see how they rank, globally and among friends. Sounds simple. It gets complicated fast.
At scale, updating leaderboards constantly is expensive. If you update the leaderboard after every single game, you're doing millions of database writes per day. The database becomes the bottleneck.
The New York Times probably implemented eventual consistency. When you finish a game, your score updates in a fast in-memory store (Redis). The app shows you your new rank instantly. Behind the scenes, that data percolates to the persistent database, usually within seconds. The leaderboard you see is usually fresh, but might be seconds old.
For ranking, they needed to choose a system. Simple win/loss records don't capture skill. A player who wins 10 games and loses 100 is different from a player who wins 10 games and loses 2. Most multiplayer games use rating systems, usually variants of Elo or Glicko-2.
These algorithms are mathematically sophisticated. They account for opponent strength, rating uncertainty, and prior performance. A win against a highly-ranked player increases your rating more than a win against a low-ranked player. Losses decrease your rating less as you improve.
The New York Times probably uses a simplified Elo variant. Each player has a base rating (maybe 1600). Win a game, your rating increases by some amount based on your opponent's rating. Lose, it decreases. The system converges to a true skill estimate over time.
They also had to prevent rating abuse. Smurfs (new accounts created by experienced players) could game the system. Players could deliberately lose to lower their rating. The system needed safeguards. Minimum rating requirements for leaderboards. Account trust scores. Win-rate anomaly detection.
Data Privacy and Competitive Integrity
When two players compete, what data should be visible? Full puzzle state? Just what they've filled in? This sounds like a UI decision, but it's actually security-critical.
The New York Times design philosophy was probably: show as little as possible. You see your puzzle, your opponent's filled-in squares (so you know what they've guessed), but not the full puzzle answer. The server has the full answer, but that's never transmitted to the client.
This prevents a whole class of attacks. Reverse-engineering network traffic to extract answers becomes impossible if the answers are never sent. Man-in-the-middle attacks can't intercept answer keys. Client-side hacking (memory inspection) can't find answers that were never loaded.
For competitive integrity, they probably log everything. Every move, every timestamp, every network event. If someone reports a suspicious game, the team can replay it and determine what happened. This creates accountability and allows them to identify cheating patterns.
They also had to comply with privacy regulations. GDPR in Europe, CCPA in California. Player data is sensitive. Where it's stored, who can access it, how long it's retained—all regulated. Games probably includes data retention policies, automatic deletion of old game records, and audit logs for who accessed what.
Testing at Scale: The Invisible Nightmares
The New York Times couldn't just launch Crossplay and hope it worked. They needed to validate it could handle real-world scale.
Testing multiplayer games is genuinely hard. You can't just run unit tests on game logic. You need to simulate thousands of concurrent players, network failures, latency variations, and edge cases.
They probably used load testing tools like JMeter or Gatling. You define player behavior patterns (connect, play for 5 minutes, disconnect) and spawn thousands of virtual players. The system records response times, failure rates, and resource consumption. You identify bottlenecks before they hurt real players.
They also ran chaos engineering tests. Deliberately break things to see how the system fails. Kill a server mid-game. Introduce 5-second latency spikes. Corrupt some database records. Does the system handle it gracefully?
For competitive games, they needed to test fairness. Does one player ever get an advantage due to network conditions? Is the timing system consistent? They probably created test games with known outcomes and verified results matched expectations.
Canary deployments were essential. Rather than rolling out new code to all servers at once, they updated a small percentage first. If something breaks, it only affects a few players. They monitor closely, then roll out to everyone once confident.
The Development Team's Approach: Unprecedented Challenges
In interviews, the Crossplay production team emphasized something important: they had to invent solutions that already existed elsewhere, but in an unfamiliar domain for them.
The New York Times is known for elegant, focused products. Their games are carefully designed. They don't copy industry trends. So when they built multiplayer, they couldn't just license an off-the-shelf game engine like Unity or Unreal.
They built it from first principles. They studied how other multiplayer games worked, but reimplemented everything for their specific constraints. Their infrastructure, their audience, their standards for quality.
This is why the team described it as "unprecedented." It wasn't unprecedented in gaming broadly. But for the New York Times, it was completely new. They'd never shipped multiplayer infrastructure. They'd never managed millions of concurrent game sessions. They'd never implemented competitive ranking systems.
The technical scope was genuinely challenging. Not "we invented something nobody's ever done" challenging. But "we solved every problem from scratch in a new context" challenging.
The team probably included backend engineers experienced with distributed systems, frontend engineers who understood real-time networking, infrastructure engineers who could deploy and monitor at scale, and product managers who kept the experience grounded in what Crossplay players actually wanted.
They likely worked in short iteration cycles. Build something, test it, gather feedback, improve it. This is especially important for competitive games, where balance and fairness matter enormously.
User Experience: Making Multiplayer Feel Natural
All of this technical complexity had to disappear. Players shouldn't see infrastructure. They should see a puzzle and an opponent.
The UX design for Crossplay involved some interesting choices:
Finding an opponent. Crossplay probably offers multiple ways. Play against a friend (send an invite, they join). Play a ranked match (system matches you with someone similar skill). Play casual (unranked, just for fun). Each path needs different infrastructure. Ranked requires leaderboards and rating systems. Casual matches can be more forgiving about timing.
Puzzle visibility. Both players see the same puzzle, but in their own state. Your filled-in squares are yours. Opponent's filled-in squares show as a different color. This creates visual feedback—you're competing on the same stage.
Time pressure. Competitive games often have timers. Crossplay might have a round timer (everyone has 15 minutes to solve). Or unlimited (first to solve wins). Different mechanics suit different players. The New York Times probably offers both.
Results and analysis. After the game, players see results, stats, maybe a replay. The replay shows who solved what first, how many mistakes each player made, where the puzzle was hardest. This creates narrative. It's not just "you lost." It's "you lost because you misspelled this word and opponent didn't."
Mobile optimization. The New York Times games are primarily mobile. Crossplay had to work on small screens, with touch controls, on variable networks. This is more constrained than desktop. The UI needed to fit in a phone screen while remaining playable during real-time competition.
Scaling Decisions: From Hundreds to Millions
Launching a game is one thing. Scaling it is another.
When Crossplay launched, they probably had infrastructure to handle maybe 100,000 concurrent players. As it grew popular, they needed to scale. This isn't just about adding more servers. It's about rethinking architecture.
They faced classic scaling questions:
Stateless vs. stateful servers. Game state has to live somewhere. If one server holds the game state and that server crashes, the game is lost. Better to distribute state across multiple servers using something like Redis or Dynamo DB. This is more complex but more resilient.
Database scaling. The leaderboard database might handle 100 queries per second normally. During peak times (when everyone plays simultaneously), it might need 10,000 queries per second. You can't just add more queries to a single database. You need sharding (dividing data across multiple databases based on player ID) or caching layers that reduce database load.
Queue systems. Finding opponents takes time. Rather than matching players instantly (which is complex), games often queue players and match them when good matches are available. This requires a queue system that handles millions of queued players globally.
Cost management. Cloud infrastructure isn't free. At Crossplay's scale, the monthly bill could reach millions of dollars. The team had to optimize every request, every database query, every server. Unnecessary logging? Disable it. Redundant API calls? Merge them. This is constant optimization work.
The New York Times probably uses a combination of AWS, Google Cloud, or similar. Not because they need exotic services, but because these platforms scale reliably. They have built-in tools for monitoring, logging, auto-scaling. The team spends time building features, not managing infrastructure.
Lessons Learned: What Crossplay Revealed
Multiplayer games reveal things about yourself as a company. The New York Times learned several lessons from building Crossplay:
First, product focus matters. Crossplay isn't trying to be World of Warcraft or Call of Duty. It's a focused, constrained experience. Two players, one puzzle, 15 minutes. This clarity made it possible to execute well. Trying to build everything (guilds, clans, chat, cosmetics) would have derailed the project.
Second, infrastructure investment pays dividends. Building robust multiplayer infrastructure is expensive. But once built, it enables faster iterations on new features. The next multiplayer game they build will be faster to ship.
Third, real-time systems are genuinely hard. Even with all the experience in the industry, building reliable multiplayer systems requires obsessive attention to detail. Latency matters. Consistency matters. Every edge case that gets shipped becomes a support burden.
Fourth, monitoring and observability are non-negotiable. You can't fix what you can't see. The team probably invested heavily in logging, metrics, and alerting. When something breaks, they know within seconds. When latency degrades, they know why. This visibility is what separates good systems from broken ones.
Fifth, players are unforgiving. Single-player games can be slower or buggier because there's no competitive element. Someone else's experience isn't affected. Multiplayer games have zero tolerance for bugs. A broken leaderboard affects thousands of people. Everyone notices latency because they're competing. The team learned this the hard way.
The Competitive Landscape: How This Compares
Multiplayer word games aren't new. Words With Friends (launched 2009) pioneered this space. Quordle and other variants exist. But most operate at smaller scale.
The New York Times brought their own standards to the category. They didn't just copy Words With Friends. They built something that felt like Wordle with someone else. Instant feedback. No confusing UI. Straightforward competition.
This is actually harder than it sounds. Words With Friends works fine with latency and delays. Crossplay needed to feel responsive. This required fundamentally different technical choices.
Other major publishers (Apple, Google, Amazon) have multiplayer games, but they operate in different genres. Crossplay competes in a unique space: real-time word games for mainstream audiences.
Future Evolution: What Comes Next
Crossplay will evolve. Features will be added. The technical foundation will mature.
Potential additions might include:
Seasonal events. Limited-time competitive modes or special puzzle rules. These create urgency and keep players engaged.
Social features. Tournaments against friends. Leaderboards by country or network. Challenges (beat your friend's time). These leverage the competitive mechanics further.
AI opponents. Sometimes you can't find a live opponent. An AI that approximates skill-appropriate opponents would fill gaps. This requires training models on historical game data.
Asynchronous modes. Play against someone who played yesterday. You see their moves, they see yours, turn-based. Different mechanics but potentially broader appeal.
Premium features. Exclusive puzzles, advanced statistics, custom rules. These monetize engaged players without alienating casual players.
The infrastructure will also evolve. Machine learning could optimize matchmaking, detect cheating more accurately, predict churn. As they accumulate more data, the system gets smarter.
Building Blocks of Multiplayer: Technical Takeaways
For anyone building multiplayer systems, Crossplay offers several lessons:
Choose your synchronization model carefully. Optimistic updates feel better than pessimistic ones. But they're riskier. Get this wrong and your game feels laggy or broken.
Invest in monitoring and observability early. You can't troubleshoot what you can't see. Logging, metrics, distributed tracing—these aren't optional.
Test at scale. Your laptop has one player. Real systems have millions. Test in a production-like environment. Use load testing. Break things deliberately.
Design for resilience. Assume things will fail. Networks drop. Servers crash. Database queries timeout. Build systems that degrade gracefully rather than catastrophically.
Keep it simple. The best multiplayer games have simple rule sets and clear mechanics. Complexity often comes from poor design, not necessary features.
Focus on latency percentiles. Don't just measure average latency. Measure the 95th and 99th percentiles. These represent the worst-case experience and matter most to users.
The Competitive Development Imperative
Building Crossplay wasn't just a product decision. It was a statement about where The New York Times sees itself.
Word games might seem niche, but they're a multi-billion dollar category. Maintaining leadership requires innovation. Adding multiplayer kept Wordle fresh while respecting its simplicity. It demonstrated capability in an entirely new space.
For the team, shipping Crossplay probably felt like a rite of passage. They went from "we build excellent single-player games" to "we can build multiplayer systems at global scale." That capability opens doors for future products.
The technical challenges were real. But they were solvable. The team solved them by borrowing ideas from gaming, applying rigor from system design, and maintaining focus on user experience. The result is a game that feels simple but runs on sophisticated infrastructure.
Conclusion: What This Means for Digital Products
The New York Times' Crossplay is interesting not because it's a game, but because it represents how thoughtful companies approach new technical domains.
They didn't reinvent multiplayer gaming. But they reimagined it for their specific context. They built systems that prioritize responsiveness and fairness over flashiness. They maintained the design philosophy that made Wordle special: simplicity, elegance, respect for the player's time.
The technical work was "unprecedented" for The New York Times not because nobody had done multiplayer before, but because they did it their way. They made architectural decisions based on their values and constraints, not industry defaults. They tested relentlessly. They prioritized quality over speed.
If you're building multiplayer products, or any real-time systems, Crossplay offers a template. Start with clear product vision. Make technical decisions that serve that vision. Invest in infrastructure and monitoring. Test at scale. Keep it simple. Iterate based on data.
The team's description of the work as "challenging and exciting" captures something real. Building at this scale, solving problems with no local precedent, shipping something millions use simultaneously—that's genuinely difficult work. It requires deep technical knowledge, careful design, and relentless focus on quality.
But it's also the work that defines modern product development. The companies that do this well—that bring genuine innovation while maintaining quality—are the ones that shape how we interact with technology. The New York Times did this with Crossplay. They built something that feels effortless, backed by infrastructure that's anything but.
