Write the Delivery Goal Before Exporting: A One-Page Brief for the Recipient's Device, Network, and Verification Route

Before exporting, write a one-page delivery brief that clearly states the recipient device, network conditions, how to run it, the target route, and acceptance criteria, then decide whether to use a local asset package or a remote link package. The order cannot be reversed: first define how the recipient opens it and how they judge success, then choose the delivery format. Below, a fictional teaching example walks through the entire process, with the project named "Tide Post Office" and the recipients being two reviewers from the partner "Shoreline Studio."

Recipient device: What kind of machine the other party uses to open it. Write it at the level of operating system category, screen size range, and whether there is a dedicated graphics card that affects playback; specific models are not necessary.

Network conditions: What network the other party verifies under. Whether they are online throughout, online only for the first time, or completely offline.

How to run it: What action the other party takes after receiving it. Whether they unzip and double-click a startup file, or open an address in a browser.

Target route: The story path the other party needs to take this time. Interactive story games often have branches; if this is not clearly written, the other party may think content is missing halfway through.

Acceptance criteria: On what basis the other party says "it's okay." Write them as checkable items, not as "looks normal."

Put these five items on paper first, then decide the delivery format. A local asset package suits scenarios that require preserving complete assets and verifying offline; a remote link package can let the other party first download a player package that does not include all videos, then go online to read assets. Both need to be opened according to the instructions in the package, and the basis for choosing is device, network, and retention conditions.

The following content is a fictional teaching example; the devices, network, and paths are all fabricated and do not correspond to any real partner or actual test results.

"Tide Post Office" Trial Delivery Brief (for Shoreline Studio review)

Recipient device: Two Windows laptops, screens 14 to 16 inches, integrated graphics. No external monitor needed.

Network conditions: Review machine A can be online throughout; review machine B is online only when copying files and is disconnected during verification.

How to run it: The two machines separately unzip the received package and start the player according to the instructions in the package. Review machine A uses the remote link package and stays online during playback; review machine B uses the local asset package and verifies offline after startup.

Target route: Enter the post office from the opening, choose "leave the letter," and go to the end of Chapter 2, "The Recipient of the Ebb Tide." This route covers about half of all nodes, enough to judge the narrative tone and visual continuity.

Acceptance criteria:

1. No interruption from the opening to the end of Chapter 2;
2. After choosing "leave the letter," the next narrative segment corresponds to the chosen branch;
3. Review machine B can reach the end of Chapter 2 while disconnected;
4. There is no obvious mismatch between visuals and text.

Known limitations: This package provides a player and does not promise editing or exporting back to other engines. Remote assets depend on the network and service; the asset address must not mistakenly use localhost on the creator's computer. Review machine B should read assets from the local package, and the actual offline result should be recorded separately.

Issue reporting format: When encountering a problem, please write four lines—where it happened (which chapter, after which choice), what you did, what you saw, and what you expected. For example: "At the beginning of Chapter 2, after choosing 'leave the letter,' the screen stayed blank for about two seconds; I expected the post office interior to appear immediately." Do not just write "it froze."

The key to this brief is that all acceptance criteria are checkable, the target route is written down to specific chapters, and the known limitations directly tell the other party what the player cannot do.

After writing the page above, the choice becomes clear. Review machine B needs to verify offline, and the remote link package does not satisfy that, so a local asset package must be provided. Review machine A can be online, so give it the remote link package as a fast channel. The two packages correspond to two verification routes, not an either-or choice.

If both machines require offline use, provide the local asset package. If the other party wants to reduce the initial download size and can be online, provide the remote link package. If they require no download at all and only opening a web page, separately confirm whether an accessible online experience entry already exists; a remote ZIP package cannot be directly treated as a hosted work page.

The basis for this step comes from the brief, not from an abstract comparison of the two modes.

Export completion does not equal passing playability verification. A successful ZIP only means the packaging action is complete; it does not mean the other party can open it or get through it. It is recommended to check in the following order. When there are no actual test conditions, write the checking method and expected results into the brief and let the other party verify for you.

1. After unzipping the local asset package, confirm that both the instruction file and the startup file are present, run it once according to the instructions, and go through the target route offline;
2. After unzipping and starting the remote link package, check that it loads assets through the expected application domain, then go through the target route;
3. Compare each choice point in the target route with the expected branch to confirm there is no mismatch;
4. Check whether the known limitations in the brief match reality, especially the two items that the player cannot edit and cannot export back to other engines;
5. Confirm that the issue reporting format has been written into the brief so the recipient knows how to describe problems.

Steps 1 and 2 are two independent routes, not substitutes for each other. If only one is done, the problems of the other will not be exposed.

What is easily missed is the endpoint of the target route. Writing only "go through it once" is not enough; the other party may stop at the first branch. Write it down to a specific chapter or after a specific choice.

Another omission is writing acceptance criteria as feeling words. "Smooth visuals" and "good experience" cannot be checked. Change them into judgeable items such as "no interruption," "branches correspond," and "can be completed offline."

Completion check: Are the five items in the brief complete; does the target route have a clear endpoint; can every acceptance criterion be checked; do the known limitations include the three items that the player is not an editor, remote links depend on the network, and localhost is not universally usable; does the issue reporting format have a four-line example. With the five items complete, the four criteria checkable, the three limitations stated, and the format exemplified, this page can be sent with the package.

Before sending, do one last thing: read this page of the brief aloud to someone who was not involved in the project, and have them repeat the target route and acceptance criteria. If they can repeat it, the recipient may be able to follow it.