Playtesting for game studios

The problem this removes

Most small and mid-sized teams can eventually get a multiplayer playtest to happen. What it costs them is a producer’s week: posting in Discord, chasing confirmations, re-running the same message when four people go quiet, discovering at start time that two players never installed the build, and then running the session shorthanded anyway because rescheduling twelve people is worse.

That work is real, it is repetitive, and it is not design work. It is also where multiplayer studies quietly fail: not because the session was badly designed, but because the cohort that turned up was not the cohort the design assumed.

Playtest Live takes the recruitment, selection, confirmation, readiness checking and standby recovery, and returns the session and its evidence.

When live multiplayer research is the right instrument

It is worth the coordination cost when the behaviour you need to see only exists when players are together: whether a team coordinates without being told how, whether a moment reads correctly to the people it happens to, what the first fifteen minutes of a new player’s match actually look like, or whether a rules change survives contact with a real group.

It is the wrong instrument for retention, population balance, rare-crash hunting or load testing. Multiplayer playtesting covers that boundary in more detail, including where an unmoderated platform or your own beta will do the job better and cheaper.

How the cohort is built

A study starts from the decision, not from a headcount. The cohort specification is derived from what the decision needs to be true, and it is versioned: if it changes, the previous version is still on the record with the reason.

You specify, and we recruit and select against:

Experience

Four bands: new to the genre, genre-familiar, experienced, and competitive expert. A cohort is a mix of bands with counts, not a single skill level, because most multiplayer questions are really about the difference between those groups.

Role and format

The multiplayer format (duel, co-op, four-player squad, 5v5 or large lobby) and any in-game roles the session needs filled.

Hardware

Low, mid or high tier, so your test is not run entirely on machines better than your players’.

Region and route

Which region the session is played from, and against which named server route, measured rather than assumed.

Availability

A specific start time in a specific IANA time zone, shown to every participant in their own local time before they accept.

Evidence policy

How strict you want the qualification evidence to be: verified only, browser-measured or verified, or self-reported allowed. Stricter costs you fill rate; looser costs you certainty. This is your call, made explicitly, before the roster is built.

Seat allocation applies those in a fixed order: required session shape first, then verified regional and hardware coverage, then experience and reliability history. The reward amount is never a ranking input. It is only checked against the budget once a seat is filled. Every assignment records the reasons it was made, so “why was this person in the session” is answerable afterwards rather than during the argument.

Readiness, scheduling and standbys

A confirmed participant is not a ready participant. Before the session, every seat has to clear the same five checks: confidentiality accepted, build installed, build launched, connection checked, voice checked. Readiness is all-or-nothing; there is no state where four out of five counts as ready.

Standby seats are booked as part of the roster and paid whether or not they are called in, because a standby who is not paid is a standby who does not show up. When a primary drops, promoting a standby keeps the higher of the two rewards, never the lower, and the swap is written to the session record with its timestamp and reason.

You see aggregate readiness and active risks, not individual player records. Rejected applicant identities, private notes and personal data never reach the studio view.

The session and what comes back

Sessions are moderated: a researcher runs the lobby, records timestamped observations and session events as they happen, and follows up with structured post-session questions and interviews where the moment needs a reason attached to it.

The output is a decision pack, not a transcript dump. It contains:

• the decision the study was run to inform, as it was stated at the start;
• findings, each linked to the specific evidence behind it;
• an explicit assessment per finding: confidence, whether the evidence was consistent or contradicted, and the scope it holds at: one session, one cohort, one build or one region;
• the recommended next test, including “replicate this before acting on it” when that is the honest answer;
• the session conditions and any deviations from the protocol.

A finding that cannot be traced to evidence is refused by the assembly step rather than published with a caveat.

Evidence provenance, and its limits

Everything in a participant profile carries where it came from and how fresh it is: self-reported, browser-measured, operator-verified, or observed during a session. Measured hardware and route evidence expires on its own schedule. Route measurements go stale after 30 days and GPU and display evidence after 180, so a stale capture cannot stand in as current proof of a cohort’s technical conditions.

The honest limits: a single moderated session produces observations and reasons, not measurements. Cohorts at the sizes teams can realistically schedule do not support statistical claims. Any finding is scoped to the build, cohort and region it was tested on until it is replicated.

Free community sessions are not paid research

Playtest Live also coordinates free community sessions. They are genuinely useful: a real scheduled lobby, a named host, teams, readiness and standbys. Participation evidence from them stays labelled as coming from a community session.

They are not a research study. There is no protocol, no moderator, no evidence plan and no decision pack. Community participation can help a player qualify for study work, but a paid study is a separate engagement with its own written terms.

What it costs

The unit is the Seat: one participant in one synchronized session. Pricing is by roster size, in AUD, and the operator is not currently registered for GST, so no GST is added.

• A$149 per seat under 12 billable seats
• A$139 per seat from 12
• A$129 per seat from 24

A standby counts fully towards the volume band but is charged at half a seat, because a standby costs less to run unless it is promoted. Booking inside 7 days loads the service fee by 25%. Re-running the same protocol on a new build within 30 days discounts it by 20%. Both of those change the cost of operating the session, and neither ever changes what a participant is owed.

Participant rewards are separate and pass through at cost: a fixed A$36 base reward per seat, with any scarcity premium itemised. No margin is taken out of what players are paid. Fewer than 8 billable seats is quoted as a tailored focused study rather than priced by the calculator, and the instant estimate on the homepage covers 8 to 24 primaries with up to 12 standbys. Anything outside that is welcome; it just needs a conversation instead of a widget.

What is available right now

Concretely, that means: the intake, contract, cohort, readiness, session timeline, evidence and decision-pack workflows are built and can be walked end to end. No paid study has been delivered, so there are no customer references, no case studies, no delivered-session statistics and no reliability record to show you. Participant payouts are manually controlled and have not been through legal, accounting and provider review, which is why paid delivery is gated rather than open.

If you want a session in the next few weeks, say so in the brief. The reply will be honest about whether the lab can deliver it, including when the answer is no.