An exhibition is, for most indie developers, an exciting event — a chance to meet other developers, interact with a wide variety of players, and show the world what you’ve been building. But for the developer who approaches it with the limited strategy of “this is just an opportunity to promote my game” and shows up with essentially the same build every time, the conclusion at the end is almost always the same: “This exhibition, like the last, produced no meaningful business or promotional results.”
IndieCade, BitSummit, Digital Dragons, Gamescom and PAX. These events differ in name, scale, and character. What they can all provide to indie developers — more valuably than media exposure or publisher meetings — is the authentic response of a player encountering your game for the first time. And only the team that has prepared thoroughly can harvest that response.
The Distance Between Your Game and the Player Who Doesn’t Know It
In the exhibition hall, how prepared is your game for a player who has never heard of it? How much does it consider it?
They have no context, no learned patterns, no understanding of your intentions. All they have is the pixels on the screen and their own pure instincts. They click in unexpected places. They can’t find the obvious button. They stop and deliberate in front of things you assumed anyone would understand. This is the reality.
Some developers watch this happen and feel disappointment or indignation. “My game isn’t that hard.” “How can someone not understand what I designed?”
The developer with wisdom sees something else in that moment: a gold mine. Before your commercial release, this is the most honest and necessary feedback you can receive from a real player — and it’s free.
Exhibition visitors don’t tell you, “This part is difficult.” They just leave your game and move to the next one. They don’t criticize your game. But their expressions and behavior are already delivering your game’s evaluation.
The Five-Minute Rule
Most visitors spend between five and fifteen minutes at any given game. They have multiple booths to visit, people to meet, and they’re hungry. The dedicated enthusiast who plays for thirty minutes is a tiny minority of the total. And the players you’ll encounter after your actual commercial launch will be far harsher and faster about leaving than even that.
Average session length at first play in a live market is often under five minutes.
This is why you need a dedicated exhibition build. Bringing your full build and designing a version specifically tuned for the opening experience are completely different things that produce completely different results.
The first thing you need to validate at an exhibition is not your rich mid-game content, not your moving ending — it’s those five minutes. If you haven’t mastered the opening five minutes and the player leaves, everything after is irrelevant. The core of an offline exhibition is to create an experience where players understand your game on their own, feel the fun, and want to keep playing within the first five minutes — and then confirm with players that you’ve achieved it.
You Don’t Need a Tutorial — With Conditions
Many indie developers ask: “Do I have to build a tutorial?” The answer is: not necessarily. The tutorial needs to be embedded in the game itself — and ideally, the game needs to speak for itself without explicit instruction.
An icon, a color choice, a button’s position — all of these must guide or prevent the player toward or away from action. This is called affordance. Following the UI conventions already validated by the genre is the fastest path. If you’re building a roguelite deckbuilder with a completely original card-selection system, players will feel like they’re learning a new language. No player — even of an indie game — will endure inconvenience to continue.
UI/UX Is Familiarity, Not Originality
One of the most common misconceptions among indie developers is about UI/UX. It’s easy to think that a unique UI creates a distinctive game. The reality is the opposite. Players arrive with expectations built from dozens or hundreds of hours in the genre. UI that deviates from those expectations isn’t experienced as personality — it’s experienced as inconvenience.
Analyze reference games frame by frame. Where is the HP bar? How is skill cooldown displayed? How many layers does the menu require to open? Following these conventions isn’t surrender — it’s consideration for the player. Differentiation is something you can do through mechanics, art, story, and narrative. That’s enough.
Define What You Want to Confirm Before You Arrive
A good test objective at an exhibition must be observable and measurable through behavior. “Is it fun?” is not a test objective. “Does the player start the first combat within three minutes without a tutorial?” “After the first death, do they choose to restart on their own?” “Do they understand the shop UI within five minutes?” — these are test objectives.
Keep it to three or fewer. More than that, and you’ll confirm nothing properly. Track those three things relentlessly throughout the event. The moment players get stuck, the moment they express something verbally, the moment they restart spontaneously — record all of these without exception.
Watching silently from behind is sometimes more meaningful than talking with the player. Recorded observation travels farther and lasts longer than impressions.
Which Exhibition You Go To Is Also Strategy
Not every exhibition attracts the same players. Your selection needs to match your objectives. I recommend participating in a smaller event — like Illustar Fest — before a major event. Get comfortable with the flow of on-site operations and experience your mistakes under lower stakes. Real conditions are always rougher than practice.
Don’t Fear Fixing Code On-Site
There are developers who, on the first evening of an exhibition, open their laptops in the hotel room and spread out their observation records. If every player that afternoon got stuck at the same point — that night is the fastest time to make the fix. Move a button. Add a hint effect. Clarify some text. The next morning, the improved version goes up at the booth.
This is indie development’s most powerful weapon. A large studio cannot do this. But the precondition is essential: maintain a rollback point you can always return to. The build from three days before the exhibition opens is a sacred artifact — never touch it. Apply hotfixes only on top of it.
After the Exhibition Ends
On the way home after the exhibition, your feet will ache, and your voice will be gone. But in your bag there are dozens of observation records — players’ expressions, their utterances, the moments they got stuck.
Organize the records within 72 hours. Memory fades quickly. Which stuck point appeared most frequently? Which moment generated the most positive reactions? From that, set the sprint objectives for your next milestone. Don’t compose the next version’s destination from impressions — compose it from data.
And above all, remember the expression on someone’s face as they sat at your game’s booth and concentrated. A stranger, absorbed in the world you made. That memory alone gives a team a reason to keep developing.
The moment the exhibition ends is the moment your team’s next development target is born.
By Professor Jung Musik
Department of Game and Visual Studies, Gachon University / Doctor of Game Engineering
Founder of Indiegame.com
Professor Jung Musik is an Associate Professor in the Department of Game and Visual Studies at Gachon University and holds a doctorate in engineering. He was a founding member of Trigger Soft in 1994 and has since served as Director at NCSoft, outside director at NASDAQ-listed Gravity, and Vice President of Lunosoft. He organized Korea’s first indie game contest in 2003 and has supported the domestic indie game ecosystem for more than two decades. He currently serves as a member of the Korea Game Rating and Administration Committee under the Ministry of Culture, Sports and Tourism, and as chair of the Content/Digital/Space division of Seongnam City’s Fourth Industrial Revolution Special Committee.
