How to Write the Credits and Version Notes at the End of an Interactive Story So Feedback Reaches the Right Person

Writing the ending information in three layers is enough: the deliverable name and version number, the division of creative contributions and tool usage, and the three pieces of information to include when giving feedback. Readers who spot a problem can locate the specific file, and when you receive feedback you can tell which layer to change, without going back and forth in emails asking "which version are you talking about?"

Below, a fictional teaching example runs throughout: a short interactive story co-created by two people, Letters from Fog Harbor, with author A-Lan responsible for the script and interactive nodes, author Xiao Ke responsible for storyboards and character assets, and the production process using AI-assisted generation for some scene descriptions. The numbers, dialogue, and version summaries in the text are made up for explanation, not actual test records.

The credits should hang on "something that can be pointed to." What readers give feedback on is often not "your story," but "the option at the dock in Act Three doesn't respond when clicked." So the ending should first state the deliverable name clearly, then the version number.

It is recommended to use two segments for the version number: major version.minor version. The major version increments when the story structure, number of endings, or key nodes change; the minor version increments when text polishing, asset replacement, or typo fixes occur. Write out the rules, and both readers and you yourself can check against them.

The ending of Letters from Fog Harbor could be written like this:

Letters from Fog Harbor interactive short · v1.2 Updates in this version: fixed the option jump in the lighthouse dialogue in Act Two; replaced the character "Lighthouse Keeper"'s sprite; minor adjustments to the ending text. If this work provides save or progress features, the compatibility of old-version progress should be listed separately as a verification result.

The last sentence is a check requirement in the production notes. If the work has no save or progress feature, do not include a notice that makes readers think saving is possible; if it does, test the actual compatibility range and publicly state the result. The version number itself cannot prove that old progress can continue.

There are two common ways to write the credits section: writing only "Authors: A-Lan, Xiao Ke," or writing only "This work was made with AI assistance." The former leaves readers not knowing who is responsible for which part, while the latter erases people's work. Writing them separately is more practical.

You can arrange it by "person—responsibility—scope":

Script and interactive nodes: A-Lan Storyboards and character assets: Xiao Ke Scene description assistance: AI used to generate first drafts, rewritten and finalized by A-Lan Test feedback: all readers welcome

The key here is that "assistance" must be followed by a specific action. Writing "AI-assisted" without saying what was assisted makes it impossible for readers to judge who to contact about a problem. Writing "AI used to generate first drafts, rewritten and finalized by A-Lan" at least shows that the final text went through human processing.

Before collaborating, verify the contribution records first: who provided the original draft, who completed the revisions, who reviewed the current version. The sources and usage permissions of external assets should be stored separately in production records; the credits section should only truthfully list actual contributions, not write people who provided references as having completed all production, nor list people who have not yet participated in testing as testers. In this way, when a problem about a certain line of dialogue or a certain asset is received, the responsible person can find the corresponding record.

Readers being willing to give feedback is a good thing, but a description like "there's a problem in Act Three" cannot be handled directly. Give a template at the end to lower the cost of feedback.

It is recommended to require three items:

1. Version number: which version you played, the string written at the end.
2. Location: which act, which scene, which option, or which line of dialogue. If you cannot remember clearly, describe what happened before and after.
3. Symptom: what you saw and what you expected. For example, "after clicking 'follow,' the screen freezes" is more useful than "it got stuck."

It can be written as a copyable template:

For feedback, please include: version number + location (act/scene/option) + symptom (what you saw, what you expected). Example: v1.2, Act Two dock, after choosing "follow," the screen stays on a black screen; expected to enter the next dialogue.

The advantage of this template is that readers do not need to understand your production process; they only need to fill it in accordingly. After receiving it, you can also directly determine whether it is a text problem, a node problem, or an asset problem.

The version summary is not a changelog. Readers do not need to know that you fixed three typos today and adjusted a color tomorrow. One line clearly stating "what is different between this version and the previous version" is enough.

The version summary of Letters from Fog Harbor can be arranged like this:

A table at the end takes up space, so it can also be compressed into one line: "v1.2: fixed Act Two jump, replaced Lighthouse Keeper sprite, minor adjustments to ending text." Readers can glance at it and know whether the version in their hands is the latest.

If a change affects the expression of old assets, for example, after changing a character setting, previously recorded dialogue no longer sounds consistent, the summary can add a line: "This version has adjustments to character settings; not all old-version dialogue assets have been re-recorded." This is a note after manual verification, not the result of automatic diffing. AI-assisted generated content is not guaranteed to meet expectations every time; for changes involving key plot points, it is recommended to listen and look through it yourself again.

Putting the above pieces together, the ending of Letters from Fog Harbor could look like this:

Letters from Fog Harbor interactive short · v1.2 Updates in this version: fixed the option jump in the lighthouse dialogue in Act Two; replaced the character "Lighthouse Keeper"'s sprite; minor adjustments to the ending text.

Script and interactive nodes: A-Lan Storyboards and character assets: Xiao Ke Scene description assistance: AI used to generate first drafts, rewritten and finalized by A-Lan Feedback reception: A-Lan, collected uniformly through the feedback form provided with the work

For feedback, please include: version number + location (act/scene/option) + symptom (what you saw, what you expected). Example: v1.2, Act Two dock, after choosing "follow," the screen stays on a black screen; expected to enter the next dialogue.

Thank you for playing. Please indicate the version you actually opened in your feedback.

This example assumes the author separately provided a feedback form, so the credits point to that actual entry point. If your work uses a comment section or public contact channel, write the corresponding entry point and confirm that readers can find it. Listing only the responsible person's name is still not enough to complete feedback; the recipient, entry point, and version information must be connected together.

After writing the ending, go through it with these four items:

• Are the deliverable name and version number written in the most prominent position?
• Is each person's responsibility specific to "what they did," rather than just listing names?
• Does the tool usage explain the scope of assistance and the manual processing step?
• Does the feedback template include the three items of version number, location, and symptom, and give an example that can be copied directly?

Once all four are passed, open the feedback entry point and check it once more. Next, you can copy this ending into your project description file, change the version summary to the current actual changes, and after verification, attach it to the end of the work or in the description file.