How a Duel is Born
Every story begins with a spark — and in our case, that spark is a player’s decision to start a duel.
Someone, somewhere, clicks “Play.”
That single action sets the system in motion.
Behind that innocent button, a few invisible steps happen — the kind that make the difference between a toy and a working system.
Step 1 — The Challenge
When a player hits “Play,” the frontend sends a simple request to the backend:
POST /duel/start
That endpoint doesn’t create a duel right away — it creates a challenge.
A challenge is like saying: “I’m ready. Find me an opponent.”
This step lets us separate intention from action.
In distributed systems, that’s gold — it means we can queue, match, or cancel safely without breaking the flow.
The backend stores this challenge in a lightweight structure:
{
playerID: "P001",
status: "waiting",
createdAt: "2025-10-31T18:00:00Z"
}
Simple, but scalable.
If no opponent arrives within a few seconds, we can even trigger an AI opponent — a fallback that keeps the experience smooth.
Step 2 — The Matchmaker
Somewhere in our cloud, a matchmaker process wakes up.
Its only job is to watch for lonely challengers and connect them.
When it finds two compatible players (or one human and one AI), it creates a new record:
{
duelID: "D123",
players: ["P001", "P002"],
state: "starting",
questions: [],
createdAt: ...
}
That’s the birth of a duel — a microcosm of logic, waiting to unfold.
Step 3 — The Arena
Once the duel is created, both players receive a notification:
“Opponent found. Get ready!”
Here we have a decision to make — should we use WebSockets for live interaction or keep it simple with request/response polling?
We’ll start simple.
A good architect doesn’t overcomplicate the first step — we’ll use stateless APIs and maybe a touch of in-memory state to simulate real-time behavior. Later, we can evolve to WebSockets, event streams, or even serverless functions triggered by updates.
This staged growth mirrors real projects: start with clarity, evolve with purpose.
Step 4 — The Game Loop
The duel begins.
Each round, the backend picks a question from a shared trivia bank (stored in a JSON or DynamoDB table), sends it to both players, and waits for their answers.
Players answer through:
POST /duel/{duelID}/answer
The backend checks correctness, updates the score, and sends feedback.
After a few rounds, the duel ends — not with fireworks, but with a neat, quiet line of JSON:
{
duelID: "D123",
winner: "P001",
score: { "P001": 4, "P002": 2 },
finishedAt: ...
}
And that’s it — a completed duel, ready for leaderboard recording or replay.
Step 5 — The Cycle Repeats
Every new duel feeds the system with experience:
-
How fast players answered
-
Which questions were too easy or too hard
-
How balanced matches were
That feedback loop is how the hub evolves — not through magic, but through data and iteration.
From Concept to Cloud
This is how ideas start breathing.
A click turns into an event.
An event turns into data.
Data turns into insight.
And insight becomes the next version of our system.
Every small piece we build will follow this philosophy:
-
Simple first.
-
Understand before optimizing.
-
Evolve from clarity, not from noise.
And just like that, our Game Hub starts to exist — not fully formed, but alive.