Bring one playable moment to the first conversation

You do not need to arrive with a finished design document. You do need a way to explain what the player does and why the next development stage matters. A specific moment gives the conversation something to examine: choosing a route, placing an object, surviving an encounter, or returning to saved progress.

Explain the experience before naming technology

Describe the player and setting. A visitor using a public tablet for a few minutes has different needs from a player returning to an adventure over several evenings. Say what input they use, what they are trying to achieve, and what would make the next action understandable.

If you have an existing build, choose one representative sequence rather than expecting someone to infer the project from a long recording. Identify the version and explain where behavior differs from your intention. If the idea is unbuilt, a sketch or paper example can still make the rule discussable.

Distinguish the design question from the production question

“Do players understand why these pieces move together?” calls for a different first step from “Can we reproduce this build and fix its checkpoint?” The former needs an experiment with appropriate players. The latter needs source access, dependencies, and a repeatable failure.

List what you know and what you suspect. Perhaps the mechanic works but touch controls remain untested. Perhaps a prototype feels promising but its asset pipeline is unclear. Those gaps are useful information, not reasons to invent certainty.

Bring an honest materials inventory

Identify source code, exported builds, editable artwork, audio, written content, rights records, and documentation. Say which materials you own or may share and which are still placeholders. Do not send signing keys, passwords, private player information, or confidential source through an ordinary inquiry.

Name the people who can approve design, content, and spending. If an educator or other specialist owns the subject matter, include their review role. A developer can implement feedback without being qualified to validate its underlying instruction.

Leave with a bounded next action

The discussion should establish the immediate question, necessary access, responsible people, and what a first stage could deliver. A source investigation, playable prototype, or defined feature may be the appropriate next step. An estimate should explain any assumption that still needs checking.

Use the project brief to organize these details, then contact Faith Forge Labs. The purpose is a more useful next conversation, not a document that pretends every production decision is already settled.