A demo is the most honest advertisement a small game has. It cannot oversell, because the player decides within a few minutes whether the idea works for them.
Festivals exist to place that demo in front of the right people. Preparing both well matters more than being present at every event on the calendar.
Why a demo exists at all
A trailer shows what the game looks like. A demo shows what it feels like to play, which is the question that usually stops a purchase.
Its job is to answer one question: does this loop deserve more of my time? Everything inside the demo serves that single answer.
It is also a test for the developer. Reactions from strangers expose problems that months of internal playtesting never brought to the surface.
Decide before the event who the demo is for. A player, an editor and a publisher need different things from the same build.
Cut the demo to one hook
The demo should contain the core loop and nothing that dilutes it. One strong idea presented clearly beats three ideas shown briefly.
Start as close to the interesting moment as possible. Long introductions lose visitors before the hook has had a chance to appear.
Leave the player wanting one more run. An ending that arrives just after the loop becomes clear beats a generous slice that runs out of ideas.
Remove the systems the player will not meet for hours in the main game. A demo is a sample, not a summary of everything planned.
Onboard in the first minute
The first minute decides whether the demo gets finished. Controls, goal and feedback all have to land without a manual or a caption.
Teach through the space and the situation, exactly as in the main game. A demo is not a different design problem from the release.
Test it with someone who has never seen the project and watch where their hands hesitate, then fix that moment before anything else.
Show the controls on screen only if the room cannot teach them. Text at the start competes with the thing the player came to see.
Submitting to festivals
Events ask for a build, a description and supporting material well before the deadline. Preparing them early removes the scramble.
Read the requirements carefully. Format, length and content rules differ, and a rejected entry is usually a compliance problem rather than a quality one.
Apply to a range rather than one large target. A mix of bigger and smaller events produces a steadier stream of attention across the year.
Note which events welcomed the game and which did not. The pattern saves the next round of applications from guesswork. Prepare the build to run unattended. Many events open the demo without the developer present, and a broken start loses the place.
Build the press kit once
A press kit is a folder that answers every routine question: what the game is, who made it and what material is available.
Include a short description, a longer one, screenshots, a logo and a contact. Keeping that set current is the whole maintenance burden.
Write the short description first. The paragraph that explains the game in a sentence is reused in stores, posts and submissions.
Store the kit at a fixed address. A link that never changes keeps working in old posts and emails long after the original message.
What to do after the event
The value of a festival is not the day itself but the interest left behind: signups, messages and a list of people who played.
| Asset | Job it does | Common gap |
|---|---|---|
| Demo build | Shows how the game plays | A slow first minute |
| Short description | Explains the idea | Written last and rushed |
| Trailer | Shows the look and tone | Longer than it needs to be |
| Screenshots | Prove the quality | Captured from an old build |
| Contact page | Makes outreach possible | Hard to find at all |
Collect reactions while they are fresh. A note taken during the event is worth more than a memory reconstructed a week afterwards.
Turn the feedback into a short list of changes, then apply only the points that repeat. One opinion is a data point, not a direction.
Thank the people who played. A short message to a player or a host costs nothing and often turns one contact into a lasting one.
Demos and festivals: where a small game gets seen
Related guide on this topic.
The demo as a permanent asset
A demo does not expire when the festival is over. It keeps working on the store page, in videos and in private invitations.
Keep it updated with the current build. A stale demo that no longer represents the game costs more attention than it earns back.
Treat it as a product with its own polish pass. The demo is often the first and only version of the game a player will ever try.
Note the version beside every build. Half of all feedback problems come from people testing a demo that was replaced weeks ago.
- Put the core loop in the demo and cut everything else.
- Reach the hook inside the first minute.
- Prepare submission material before the deadline rather than during it.
- Write the short description before anything else.
- Apply feedback that repeats, not a single opinion.
A demo and a place at a festival solve one problem from two sides: one shows the game, the other finds the people willing to look at it.
Neither requires a large budget. Both require the loop to be clear and the material to be ready before the moment actually arrives.
