Create a room. Send an invitation. Wait for a friend to arrive.
There is something familiar about that sequence. Browser multiplayer can still have the feeling of agreeing where to meet, finding the right room and seeing that the other person has made it in. A room code gives a small game a place for two people to share.
That became the shape of online play in the MFCMF Arcade. CHESS came first; FOOTBALL followed with the same invitation model. Neither needs an account, a chat system or a matchmaking queue. The room exists for the game the two people came to play.
The ritual can stay simple. Keeping the game shared takes more work.
An invitation is not a seat
One person creates a room and sends its link. The other opens it, sees what they are joining and chooses Join. Opening a page alone should leave that decision with the person receiving the invitation.
The link identifies the room. A separate credential, kept in the player's browser, identifies their seat. Sharing the invitation therefore gives a friend a way in without handing over control of the host's side.
Waiting needs to be readable too. A friend who has not arrived, a server still waking up and a lost connection require different responses. FOOTBALL gives the host Signal FC and the guest Static Utd; both choose Kick Off before the match begins. Arrival becomes visible before the action starts.
- 01CREATE ROOMA place for two
- 02SEND INVITEShare the room link
- 03JOINChoose to take a seat
- 04PLAYBoth people are here
One game needs one account of what happened
With CHESS, the shared object is a position and a sequence of moves. The server checks whose turn it is and whether a move is legal, then gives both browsers the same history. A move can arrive even when its acknowledgement is lost. Retrying must recover the accepted move without playing it twice.
FOOTBALL keeps changing between decisions. The server runs the match: players, ball, clock and score. The browsers send inputs and receive snapshots of that shared simulation. A guest cannot make a goal official by reporting a different score from their own screen.
The implementation uses frequent HTTP requests. CHESS can wait for the next move. FOOTBALL runs its simulation thirty times a second and sends snapshots roughly ten times a second while receiving movement and actions. That makes delay a much more immediate part of the experience.
The first online FOOTBALL review exposed a telling problem: a background read could hold up a new input. The match looked connected, yet the player felt late. Reads and input now have separate request paths; an input can interrupt a waiting read, and older responses cannot replace newer state. Joining successfully was only the beginning of the test.
Pause belongs to both people differently
On a single device, Pause feels like a private decision. A shared game needs an explicit answer about who it affects.
CHESS / HOLD MY VIEW
In online CHESS, Pause holds my view. My friend can continue, and returning shows the current board. The turn structure lets that distinction remain clear: the position waits whenever the next move belongs to me.
FOOTBALL / STOP THE MATCH
In FOOTBALL, the clock and ball would keep moving. Pause stops the shared match, and both players must be ready before it resumes. Half time also waits for both people. A lost connection pauses play; stale movement input is released so a missing player cannot keep running indefinitely.
A rematch needs agreement too. CHESS swaps colors when both players accept. FOOTBALL waits for both sides to request another match. The familiar label hides a social decision: neither person should restart the other's game alone.
A temporary room needs an honest ending
These rooms run on free services and live in server memory. An idle service can take about a minute to wake. Restarting or sleeping can remove the room. CHESS rooms have a maximum life of twenty-four hours; FOOTBALL rooms expire after an hour without activity.
Returning in the original browser can recover a seat while its room still exists. Clearing that browser's storage loses the credential. An invitation is useful for joining, but it cannot recreate a vanished match or prove ownership of a lost seat.
CHESS offers a PGN download as a separate record of the moves. That file has a different purpose from the room. The temporary meeting place and the thing someone chooses to keep need different promises.
The limits belong in the interface because they change what a person can reasonably expect when coming back.
The room is part of the game
The enjoyable part is still the move or the pass. Getting there depends on quieter details: a link that opens the right place, a seat that stays yours, an honest waiting state and controls that respond while the connection is busy.
Two browsers showing the same pitch is a useful start. Moving a player, reaching half time, reconnecting and agreeing to play again reveal whether the room works as a place to meet.
That is the part of the older room-based experience worth carrying forward: an easy way to find each other, a clear moment when both people are ready, and a game that belongs to them while they are there.
