Soulframe Feedback & Bug Report Guide

A useful report contains

Use these fields even when the official form is short; they make the issue easier to reproduce.

Why feedback changes during Preludes

Preludes is a public development process, so feedback is part of the product. A precise report can distinguish a player error, a balance issue, a network problem, and a reproducible defect. That distinction is exactly what a vague complaint removes.

Write steps a stranger can repeat

Pretend the reader has not seen your session. Replace "it broke" with the exact route, menu, input, enemy state, and observed result. Include the first moment you noticed the problem and whether repeating the sequence produces the same outcome.

Separate bug from preference

A bug has an observable mismatch between intended and actual behavior. A preference says a mechanic feels uncomfortable but still works. Both are valid feedback, but labeling them correctly helps developers route the report.

Avoid harmful shortcuts

Do not modify files, inject tools, use unofficial clients, or test exploits to confirm a theory. Report what you can observe through normal play and state where your observation stops. Unsafe reproduction can corrupt data and make the report unusable.

Write impact without exaggeration

Say how the issue affected one session: blocked progress, distorted a decision, interrupted installation, or only created visual noise. Avoid global claims such as "the game is broken" unless you can show the scope. Accurate impact helps a developer judge severity without turning one anomaly into a platform-wide conclusion.

What to do while waiting for a response

Do not keep changing multiple variables. Keep your report reference, note whether the issue survives each official update, and continue normal play. If it disappears, send a short update saying which patch resolved it; that information is also useful during Preludes.

Build a one-page reproduction record

A useful report can usually fit on one page if the fields are specific. Write the observed behavior first, then the exact steps in the order you performed them, and finish with the environment that could affect the result. Include the patch or build date, language interface, hardware class, driver family if relevant, connection type, and whether overlays or input software were active. For intermittent issues, record the number of attempts and the last successful attempt rather than writing "sometimes". For a visual issue, describe where it appeared on screen and what changed around it; for a progress issue, state the objective, the expected next step, and the point where progress stopped. Before submission, remove unrelated speculation and keep only facts you observed or clearly label the boundary of your knowledge. If another player reported the same behavior, link their report without copying their hardware details as your evidence. Leave a final line for uncertainty. Saying that you did not test another account, region, or hardware setting is more credible than pretending the report covers every case.

• Behavior: what happened, where, and when it started.
• Steps: the shortest sequence that still produced it.
• Environment: patch date, hardware class, connection, and relevant software.
• Expected and actual result: one sentence each.
• Boundary: what you did not test and why.
• Reference: a separate report link, if the same behavior already exists.
• Uncertainty: the one variable you could not control.
• Session length: enough to show whether the issue repeats.
• Recovery: what restored normal play, if anything.
• Attachment: one screenshot or short capture, not a folder.
• Language: the interface language used during the test.
• Client build: the current patch identifier.

FAQ