Demo or Free Weekend? Choose the playable experiment, not just the free label

For a released indie game, an ongoing demo and a temporary full-game trial can answer different business questions. A well-chosen slice can show whether a player understands and enjoys the central mechanic. A full-game window can expose the larger experience, including the actual multiplayer population and later systems. Neither automatically establishes willingness to pay.

Start with the uncertainty you need to reduce. Then choose a feasible route that lets the relevant players experience the relevant task. Calling both routes “free” hides the differences in build scope, time, support and the decision a player faces afterward.

Define the question a trial should answer

Write one concrete question before choosing a format. For a puzzle game it might be: can a new player understand the interaction without a narrated tutorial? For a multiplayer game: can a newcomer complete an ordinary session with the kinds of players they would encounter after purchase? For a replayable strategy game: does the player reach a meaningful second decision, rather than only finishing setup?

Separate those observations from the commercial question. Someone may understand the game, enjoy it and still decide not to buy. Someone may intend to buy but lack time during a fixed window. A route that cannot expose the relevant task will produce ambiguous evidence regardless of how many people download it.

A historical developer question about demos raised precisely the concern that trying a game and later purchasing it are not the same step. Its replies offer conflicting assertions about sales and refunds, not reliable benchmarks. Treat the question as context, not a rule that demos necessarily help or hurt revenue. Read the original discussion.

Compare the playable scope, not the name

Valve describes demos as a separate application associated with the full game. Their quality, length and representative content need deliberate decisions. An ongoing demo is therefore a maintained product surface, not a promise that the team can leave any old build online forever. Its descriptions should match what players actually encounter. Read Valve’s demo guidance.

Steam Free Weekends instead provide temporary access through the base-game application and its depots. They require Steam Team approval; Valve asks partners to discuss fit and timing at least a month ahead. The default promotion is on the game’s own store page, not a guaranteed store-wide campaign. After access ends, continued play requires purchase. Read Valve’s Free Weekend guidance.

Those differences create real feasibility gates. Do you have a representative demo build you can maintain? Is a full-game window approved and operationally supportable? If one route is unavailable, a calendar label cannot make it available.

A studio posting about ’83 announced a demo with an update, then explained in a reply that a desired Free Weekend was not within its control for that date. Players also questioned whether the demo would share the full game’s servers. This is a concrete reason to inspect scope and population rather than assuming one free route substitutes for another. It is not a claim about that game’s current availability. Read the studio’s announcement and reply.

Ask whether the participants experience the same game

For a fictional multiplayer project, the team wants to learn whether newcomers enjoy ordinary sessions with existing players. If its demo uses a separate queue, that queue may reveal tutorial problems but cannot directly answer the mixed-population question. If an approved full-game trial shares the relevant population, it may expose that interaction, but the team still needs enough support and actual session evidence.

Do not convert this into “all demos separate players” or “a Free Weekend fixes matchmaking.” Inspect your implementation. Record which modes, regions, account types and player groups each route actually includes. A queue’s population, the build, the event audience and concurrent marketing can all differ between observations.

For a fictional short narrative game, another issue matters: players could finish the complete experience during a temporary full-access window. The team should not assume the later purchase decision will resemble that of someone who tried a representative opening chapter. This does not prove that limiting content increases sales. It identifies a different experiment and a different reason a player might buy afterward.

Budget the player’s time as well as your own

A fixed window includes the time spent discovering the offer, downloading, installing and finding a suitable session. If the player’s available evening ends before meaningful play begins, an unused entitlement does not tell you that the game lacks appeal.

Valve specifically notes the download investment and varying connection speeds involved in a Free Weekend. Use your actual download and onboarding observations when planning. Do not invent a universal “enough time” target from another game’s promotional schedule.

The team also has a time budget. Assign someone to inspect access problems, someone to answer known scope questions and someone to capture observations without changing the rules midway through the experiment. For a very small team, one person may fill several roles, but the hours still compete. An ongoing demo spreads support over time; a fixed window concentrates it. Neither is free to operate simply because the player pays nothing initially.

Verify the handoff and the progress promise

Before promoting either route, inspect the actual account path you intend to offer. Does a former demo player enter the intended trial experience? Does a new participant receive the expected content? What happens at the end? Keep the intended behavior separate from what you observed.

A Sunderfolk discussion illustrates why that distinction matters: a developer reported a fix for trial-versus-full access, while later players still reported problems and others reported success. That thread does not establish a current defect or a universal remedy. It does show why an announcement alone is weaker evidence than checking the affected path. Do not copy account-removal or file-deletion suggestions from the replies. Read the support conversation.

Make any progress-retention statement build- and route-specific. Shared application access or an available cloud-storage option is not proof that every save, unlock or multiplayer state transfers correctly in your game. If the team has not verified the transition, do not promise automatic continuation. Avoid turning this planning exercise into an unreviewed migration or reset procedure.

Leave the paid decision visible and voluntary

At the relevant endpoint, explain what access ends, what remains available and what purchasing would provide. Keep the price and offer accurate to the approved destination. Do not imply that a download grants permanent ownership or that a purchase is required to submit useful feedback.

Record three outcomes separately: the intended task was actually experienced; the player’s explanation or feedback was useful; a paid purchase was observed through an appropriate report. A participant may stop after any one of these. Do not draw a funnel that quietly assumes everyone advances.

For the first preparation step, complete a one-page comparison: question, playable scope, included population, player time cost, approval status, support owner, progress promise and paid next step. Remove any route whose critical condition is unknown until the missing evidence is obtained.

Afterward, compare the observations with the original question. If the demo clarified the mechanic but used a different player pool, report that limited finding. If a full-game window produced sessions but purchase attribution is unavailable, leave conversion unknown. The useful outcome is a better-informed acquisition decision, not a fabricated winner between two free offers.