Grey-Box First: How to Playtest Mobile Game Prototypes Before Art

Art cannot rescue a boring verb. On mobile, that truth is expensive, because store screenshots and trailer polish can hide a weak loop until reviews arrive - and by then you have spent the budget that should have been spent on finding fun earlier.

At Pexel Grafix we have a house rule that sounds blunt because it has to be: a game should be fun in grey-box before it is allowed to be beautiful. This article explains what that means in practice for mobile teams - how to structure prototypes, who to put in the room, what to measure, and how to make "kill the idea" a professional act instead of a moral failure.

What grey-box actually is

Grey-box (or graybox) means the playable uses temporary geometry, placeholder characters, blocks for enemies, debug text for rewards, and the simplest possible UI needed to exercise the core loop. It is not a style choice. It is a filter.

You are testing:

• Is the main verb satisfying to repeat?
• Is the difficulty readable?
• Do players understand goals without a lecture?
• Does the session structure fit how people play on phones?
• Are controls comfortable for thumbs?

You are not testing:

• Whether the lighting mood is on-brand
• Whether the character design trends well on social
• Whether the soundtrack slaps in a trailer edit

Those matter later. They are also incredible at lying to stakeholders if the loop underneath is soft.

Why mobile teams skip this (and regret it)

Mobile production has pressures that push teams toward polish too early:

• Store pages need images.
• Soft launch plans want "finished looking" builds.
• Investors ask for vertical slices that look like marketing.
• Artists want to contribute before mechanics settle.

Those pressures are real. Yielding to them too early creates pretty prototypes that cannot answer the only question that matters: would anyone play this if it looked like a tech test?

A grey-box that survives contact with players is more valuable than a gorgeous build that players abandon after ninety seconds.

Define the smallest playable that can fail honestly

Every prototype needs a single primary question. Examples:

• "Does tap-to-aim feel fair against moving targets?"
• "Can players read bullet patterns on a six-inch screen?"
• "Does a three-minute run feel complete?"
• "Do new players place towers correctly without a wall of text?"

If your prototype tries to answer twelve questions, it will answer none.

Write the question on a sticky note. If a feature does not serve that question, it does not enter this build.

Scope rules that keep prototypes honest

• One camera language
• One core verb (two maximum)
• One environment language (blocks are fine)
• Debug HUD instead of real UI chrome when possible
• No meta-progression until the minute-to-minute loop works
• No monetization hooks in the first fun tests

Monetization prototypes are a different experiment. Do not contaminate "is it fun?" with "will they watch an ad?" until fun exists.

Build for thumbs even when the art is cubes

Grey-box is not an excuse to use mouse-only controls "because it's faster." If the product is mobile, the prototype should be touchable on a device.

Use:

• Real phones in the room
• Airplane mode or stable builds sideloaded quickly
• Identical control schemes to the intended product direction
• Bright outdoor and dim indoor lighting if readability is in question

Emulators help engineers. They do not replace a human thumb on glass.

How to run an early playtest without theater

Recruit the right mix

You need at least two audiences:

1. Target-ish players (people who play similar mobile games)
2. Cold players (people who do not)

Cold players reveal onboarding lies. Target players reveal genre expectation misses. Only testing with your Discord friends produces false confidence.

Keep sessions short and structured

For early mobile prototypes:

• 10-20 minutes of play
• Think-aloud encouraged
• Facilitator talks less than they want to
• One note-taker who is not also explaining the game

If you have to narrate constantly for players to proceed, the prototype already failed the comprehension test - write that down instead of "helping."

Capture what matters

Quantitative (light):

• Completion of first goal
• Time to first success
• Rage quits / silent quits
• Deaths that felt unfair vs earned (ask)

Qualitative:

• Where eyes go
• Where thumbs struggle
• What players think the goal is
• What they say they would do "next time"

Video of hands + face (with permission) is often more useful than a survey.

Interpreting results without comforting yourself

Teams are very good at explaining away failure:

• "They would have liked it with better art."
• "They are not our audience."
• "The tutorial wasn't in yet."
• "It was a bad build."

Sometimes those are true. Often they are coping.

Translate feedback into design statements:

• "Players cannot distinguish telegraphs" → readability system work
• "Players ignore the side objective" → objective hierarchy failure
• "Players say it's random" → feedback/clarity failure even if RNG is fair
• "Players stop after one run" → reward timing / session shape failure

Art is rarely the first patch for those.

Kill criteria: decide before the test

Before playtests, agree what would cause a pivot. Examples:

• Fewer than half of cold players understand the verb in one minute
• Median session ends before first reward
• Majority call the same moment "unfair" across skill levels
• Controls cause physical discomfort within five minutes

Pre-commit to action. Otherwise every test becomes a meeting where the loudest person protects their favorite feature.

Killing an idea early is not anti-creative. It is how creative teams protect energy for ideas that deserve art.

Grey-box milestones we use on client and internal projects

Milestone A - Verb test (days, not weeks)

Can a player do the main thing and want to do it again?

Milestone B - Readability & fairness test

Can they understand why they failed?

Milestone C - Session shape test

Does a short session feel like a unit with a beginning and end?

Milestone D - Content extension test

Do additional encounters still feel like the same game, or like a pile of exceptions?

Only after C (sometimes D) do we unlock serious production art beyond placeholders needed for clarity.

What placeholder quality is "good enough"

Placeholders should not confuse the test:

• Enemy types need distinct silhouettes even as blocks (color/shape coding)
• Hazards need readable contrast
• UI text must be large enough to read mid-motion
• Audio can be temp beeps if timing feedback matters

Ugly is fine. Ambiguous is not.

Bridging from grey-box to production without losing the lesson

When you finally add art:

• Re-test the same scenarios that previously passed
• Watch for readability regressions (VFX, post-process, camera shake)
• Lock control feel before cosmetic animation flourishes
• Keep a "grey-box build" branch or package for regression comparisons

Many mobile games quietly worsen when juiced: too many particles, too much screen shake, too much HUD. Beauty introduced a new readability budget problem. Keep the grey-box as a reference for what fairness felt like.

Stakeholder communication tips

Founders and marketers often fear grey-box optics. Help them by framing the output:

• "This build answers whether the loop retains."
• "Screenshots come after the loop survives strangers."
• "We can make a trailer later; we cannot unspend a year of wrong production."

Offer a dated plan: grey-box test → go/no-go → art vertical → soft marketing assets. Certainty of process reduces panic about temporary ugliness.

A note on "vertical slices"

A vertical slice that is all art and no proven loop is a horizontal illusion. If your slice cannot explain why players return, it is a trailer kit, not a production proof.

Our preference: an ugly loop that people replay beats a gorgeous corridor they walk once for the camera.

Closing checklist

Before you greenlight production art budgets, confirm:

1. The prototype question was written down and actually tested.
2. Cold players touched a device build.
3. You know the main failure reasons in players' words.
4. Kill/pivot criteria were set in advance and honored.
5. Session shape fits mobile reality.
6. The team can describe the fun without referring to future art.

If you cannot check those boxes, you are not "behind on art." You are early on truth - and that is the cheaper place to be.

Grey-box playtesting is how small studios compete with bigger ones: not by rendering harder, but by learning faster. On mobile, where attention is scarce and reviews are public, learning faster is not a process luxury. It is survival.

When you are ready to put a prototype in front of real thumbs, bring the build and the question. We will help you read the room - and if the idea deserves to die, we will help you kill it while the funeral is still cheap.