Living Museum of Learning
The Dinner Table Became a Game Server
Situation
For years, Donald had built multiplayer games around Apple’s Nearby MultipeerConnectivity.
It was elegant when it worked.
But there was a problem: “nearby” was not really enough.
At one point, two devices sitting next to each other at Vancouver’s waterfront airport could not play because there was no Wi-Fi. Back in Toronto, repeated tests confirmed something even stranger: the supposedly nearby multiplayer setup depended on Wi-Fi in his actual environment.
So the question became very practical:
Could the game simply cross the Internet instead?
Not with a giant cloud architecture.
Not with accounts, databases, matchmaking, friend lists, or some elaborate game backend.
Just a tiny bridge.
A room.
A four-letter code.
And messages waiting in a mailbox.
Turning Point
Late at night—actually early in the morning—Donald moved his entire programming operation out of his normal working room.
He chose the dinner table instead.
He likes the big open space.
It was deep into the night, so the room was almost completely dark.
On the table sat his MacBook.
Connected to it were an iPad and an iPhone, their white cables visibly stretching across the darkness.
And on both screens was Golden Xiangqi.
This was no longer an abstract networking experiment.
The two devices were actually playing the same game.
The photo Cindy took captured the moment.
The dinner table had become a tiny multiplayer laboratory.
Emergence
The architecture was deliberately small.
The MacBook was the workshop.
The iPhone and iPad became players.
And in the middle was a very modest Internet service running on muzhi.com.
The server did not know how to play Xiangqi.
It did not know what a cannon was.
It did not know what a horse was.
It did not even know what a game state meant.
It simply knew:
Who sent this message?
Who should receive it?
Which room does it belong to?
A player creates a room and receives a human-friendly code such as DWJP.
Another player enters that code.
The server puts the players into the same room.
From then on, game packets travel through the bridge.
A move goes out.
A move comes back.
A game state follows.
The server remains almost completely ignorant of the game itself.
That turned out to be the beautiful part.
The same bridge that carried a Xiangqi move could carry a Golden 24 move.
The bridge didn't need to understand either game.
The Little Mailbox
The Internet service is almost comically simple.
A room contains players.
Each player has a mailbox.
A message can be addressed to one player—or broadcast to everyone else.
The client polls its mailbox every half second.
There is no persistent connection.
No complicated multiplayer protocol.
No elaborate synchronization engine.
Just:
send → wait → receive → process.
For a tiny ecosystem of Donald's games and a tiny number of players, that is enough.
Sometimes engineering becomes clearer when you stop trying to make the infrastructure clever.
The Two Games
Golden Xiangqi was the first real proof.
A host created a room.
A guest joined with the four-letter code.
The guest appeared in the host's roster.
The host sent the game state.
The guest received it.
A move made on one device appeared on the other.
Then another.
And another.
Eventually the guest resigned.
The host's winning count increased.
The entire lifecycle worked.
Then came Golden 24.
It exposed a subtle problem.
The guest could join the room, but the host's local room membership still contained only the host. The server knew about the guest; the host's local model did not.
That meant the host had nobody to broadcast to.
The fix was tiny:
when a player arrives, add that player to the host's local room.
Then broadcast the roster.
Then broadcast the current game state.
And suddenly Golden 24 worked too.
The same bridge.
A different game.
The Cables
The white cables in the photograph are almost a perfect metaphor.
They look like ordinary physical connections.
But the games themselves no longer depend on being physically connected.
The iPhone and iPad can be separated.
The players can be separated.
The cities can be separated.
The bridge carries the messages.
And the game remains the game.
That is an important distinction in Donald's architecture:
The game does not need to know how its messages travel.
Nearby networking is one transport.
Internet Game Bridge is another.
The game logic stays above them.
Learning
This project became an unexpected lesson in abstraction.
At first, the problem looked like:
How do I make Golden Xiangqi work over the Internet?
But that question is already too specific.
The better question was:
What does a game actually need from a transport?
The answer turned out to be surprisingly small:
Send a packet to another player.
Once that became a protocol abstraction, the same session machinery could serve different games.
Xiangqi did not need an Internet Xiangqi engine.
Golden 24 did not need an Internet Golden 24 engine.
They needed a common bridge.
And the server did not need to understand the games at all.
That is the kind of abstraction that is worth discovering rather than designing in advance.
A Night at the Dinner Table
There is something almost funny about the final scene.
It was not a data center.
It was not a startup office.
It was not a networking laboratory.
It was a dinner table in Toronto, deep in the night.
A MacBook.
An iPad.
An iPhone.
Three screens/devices.
Two white cables.
Two games.
A tiny server somewhere on the Internet.
And one developer sitting there watching pieces move between machines.
I had to use Cindy's iPhone to take the photograph since my own was used for debugging.
The room was dark.
But the screens were alive.
And for a moment, the dinner table was the entire infrastructure of a little software company.
Theme
When a small idea becomes a real system
What Is Possible
A multiplayer game does not need a sophisticated backend to cross the Internet. A tiny, game-agnostic message bridge can be enough.
How Does It Happen
Separate game logic from transport. Give the transport a tiny packet interface. Let the server route messages without understanding the game.
Why Does It Matter
Good architecture can make a new capability feel almost boring to add. Once the bridge existed for Golden Xiangqi, Golden 24 could use the same idea.
And perhaps the most important part:
The photograph is not a picture of someone coding.
It is a picture of an idea becoming physical.
A dark dinner table.
White cables.
Two screens showing the same game.
And somewhere between them, a tiny invisible bridge.