PromptGolf: Winning a 24-Hour Hackathon With a Jackbox-Style AI Prompt Game

Key Takeaways

• Four of us, Akin, Sean, Anwar, and Daniel, built PromptGolf in a 24-hour hackathon and took 1st place.
• The game is Jackbox-style: players see a target image, write the shortest prompt they can, and an AI model regenerates it. Peers vote on whose recreation came closest.
• Stack: Next.js 15, Pusher Channels for realtime, Upstash Redis for room state, fal.ai FLUX schnell for image generation, ElevenLabs Scribe v2 for push-to-talk voice prompting.

A multiplayer game with live image generation, voting, presence, push-to-talk voice prompts, and a tiebreaker system sounds like a four-week project. We had 24 hours and four people who had never shipped together. This is how we did it, what broke, and the calls that saved us.

What is PromptGolf?

PromptGolf is a party game where the shortest prompt wins. Players join a room with a code, see a target image for a few seconds, and then race to write a prompt that recreates it through FLUX. After everyone submits, players vote on which generated image came closest to the original target, ignoring their own. Vote totals across N rounds decide the winner, and if the leaderboard is tied at the end, a tiebreaker round kicks in automatically.

The hook is that long, verbose prompts almost never win. You are not rewarded for describing every pixel. You are rewarded for finding the two or three words that point the model at the right concept. It is genuinely a different skill from "prompt engineering" the way most people use the term.

Try it live: prompt-golf-rho.vercel.app

Source: github.com/AKforCodes/PromptGolf

How did the team form?

The four of us, Akin, Sean, Anwar, and Daniel, came into the hackathon without a fixed idea. We had maybe an hour of group brainstorming before the clock started, and the only thing we agreed on early was that whatever we built had to be visibly multiplayer, because a static demo never wins these things. Jackbox came up as a reference point, and once someone said "what if the game is about prompting AI", the rest of the design fell out in about fifteen minutes.

Daniel and Anwar took the realtime layer and game state. Sean drove the image generation pipeline and voting flow. I picked up the voice-to-prompt feature using ElevenLabs and the room configuration UI. We agreed up front that integration would happen at hour 18, not hour 23, which turned out to be the most important decision of the night.

What was the technical plan?

We mapped out the architecture before writing any code. The constraint was that we had to be on Vercel by the deadline with a working live demo, so everything had to fit inside serverless plus managed infrastructure. No custom WebSocket server, no self-hosted anything.

Here is the breakdown of what we landed on:

Frontend: Next.js 15 with Turbopack for fast iteration, TypeScript everywhere, Tailwind v4 for styling, shadcn/ui for components we did not have time to design from scratch.

Realtime: Pusher Channels for presence detection, room events, and broadcast. Pusher gave us hosted WebSockets with a free tier large enough for a hackathon demo and an SDK that took roughly fifteen minutes to wire up.

State store: Upstash Redis with a one-hour TTL on every room key. The TTL was the cleanup mechanism, abandoned rooms just expire and disappear, which meant we did not have to write a cron job to garbage collect.

Image generation: fal.ai's hosted FLUX schnell. We picked schnell over dev because latency mattered more than fidelity, players cannot wait 30 seconds per round.

Voice STT: ElevenLabs Scribe v2 for push-to-talk. The hold-to-talk pattern beat a "tap to record" toggle because it gave players a natural sense of when the mic was open.

Deploy: Vercel, with environment variables for every API key. We pushed our first preview deploy in hour two so we had a known-working baseline.

What broke during the build?

Plenty. Realtime is where most of the pain lived.

The first version of room state had every client writing to Redis directly when game events fired. Two players submitting prompts at the same time corrupted the round's pending list because we were doing read-modify-write without a lock. Anwar fixed it by routing all state mutations through a single API route that used Redis atomic operations like SADD and INCR instead of GET then SET. The Pusher event was then triggered server-side after the write succeeded, so clients only ever read state from broadcast events, not directly from Redis.

The image generation pipeline had its own pitfall. FLUX latency varies between 3 and 9 seconds, and we were originally awaiting each generation inline in the API handler. On Vercel's serverless runtime this meant the function held a connection for the full generation, and with four players generating at once we hit memory and concurrency limits. We refactored to fire-and-forget the generation call, store the request ID in Redis, and have Pusher broadcast the result URL when the webhook came back. This made the whole game feel snappier because the UI could show a "generating" state immediately instead of blocking.

The voting flow had a subtle bug where a player could vote for their own image if they refreshed mid-round and the client state was stale. Sean caught it during a playtest at hour 16, and the fix was to enforce the "no self-vote" rule server-side rather than just hiding the player's own option in the UI.

What did the room flow actually look like?

1. Host creates room. Server generates a four-character code and writes the room to Redis.
2. Players join via code. Server subscribes them to a Pusher channel for the room.
3. Host configures the game: rounds, prompt length cap, attempts per round, timer.
4. Host starts the game. A target image is picked from a preset pool.
5. Target is shown for a few seconds, then hidden.
6. Players type or hold-to-talk a prompt. The server forwards it to fal.ai FLUX schnell.
7. Generated images broadcast back via Pusher as soon as each one completes.
8. Players pick their best attempt to submit for voting.
9. Voting screen. Each player picks the closest match, excluding their own image.
10. Scores tally, leaderboard broadcasts, next round starts.
11. After N rounds, if the leaderboard is tied, an automatic tiebreaker round runs.

The thing that made the game feel like Jackbox rather than a tech demo was step 8. Letting players pick their best attempt out of multiple generations meant the round was not punishing a single unlucky output. It made the skill ceiling about choosing well as much as prompting well.

Why short prompts actually win

The scoring is pure peer voting, so the optimal strategy is whatever produces the most recognizably similar image. We expected the meta to be detailed descriptions, but in playtesting it consistently was not. Short prompts won most rounds for two reasons.

First, FLUX schnell trades fidelity for speed. Long prompts dilute the conditioning signal and the model wanders. A three-word prompt like "red corvette sunset" produces something coherent. A 30-word prompt trying to specify the exact car model, angle, lighting, and background often produces something that has more details but is structurally further from the target.

Second, players are voting on overall similarity in maybe two seconds of looking. A prompt that nails the dominant color and one recognizable subject beats a prompt that nails details a voter never has time to register.

This was not something we designed for, the game mechanic just happened to reward it. It is the kind of thing you only learn by actually playing the thing you built.

What did we take away from the hackathon?

The biggest lesson was reuse over rebuild. Pusher and Upstash and fal.ai and ElevenLabs are all managed services that exist because somebody else already solved the hard part. Trying to host our own WebSocket server or build our own image generation pipeline would have eaten the entire 24 hours. Picking boring, battle-tested infrastructure freed us to spend our time on the actual game design, which is the only part nobody else had built.

The second lesson was that integration is the long pole. We hit our hour-18 integration deadline by about 30 minutes, which sounds bad until you realize the alternative is most teams hit it at hour 23 and ship nothing. Forcing every component to be merged with two-plus hours of buffer meant we had time to playtest, fix the self-vote bug, and add small things like the shareable OG card that ended up being a big part of the demo.

The third was that constraints are features. The prompt length cap is configurable per room, and rooms with a short character limit produced consistently funnier games than rooms with unlimited length. The thing that felt like a UI restriction turned out to be the design principle behind the whole game.

We won 1st place. More importantly, we shipped something I would actually play with friends, which is the real test of a hackathon project.

Friends and teammates

This was a team effort and PromptGolf does not exist without the other three.

• Sean Iseosa Idisi: linkedin.com/in/sean-iseosa-idisi
• Anwar Rafiu: linkedin.com/in/anwar-rafiu
• Daniel Olusakin: linkedin.com/in/daniel-olusakin

Related

• Google Hackathon x Machine Talents, my last hackathon writeup, where a chain-of-agents architecture and scope discipline carried a 3-hour build.
• Staying Ahead: Why Learning Is the Core Skill for Software Engineers, hackathons compress a year of learning into one weekend.
• Clean Code Is Great Until It Isn't, on the tradeoffs of writing throwaway code under deadline pressure.