Decide what prerecorded media can carry
game-build’s media method applies when art direction has chosen cutscenes, environment loops or keyframe performance. A fixed-view short presentation can be prerecorded. Player-controlled perspective, movement, collision or tactical information requires appropriate real-time behavior.
Original game: the player chooses to light a ferry signal. Rules confirm the result before a short clip shows a boat responding; interaction then resumes. Game state decides whether the boat comes. Generated media presents that result rather than inventing it.
If the player must freely turn to inspect both channels, a fixed clip cannot carry that interaction. Choose the experience first instead of reshaping gameplay around an attractive generated asset.
Keep the actual file and its trigger
| Record | Example |
|---|---|
| Stable resource | ferry-response in the project media directory |
| Trigger | Signal lit, boat able to respond, not previously played |
| Locked facts | Same landing; boat across the water; signal on |
| Allowed motion | Boat answers with a light and approaches briefly |
| Boundaries | Starts across the water; ends before docking, returning to a waiting choice |
| Fallback | Same-state still and a short response event |
Also record duration, references, output path, provenance and status. Save actual files promptly; supplier task pages, caches and temporary download links do not serve as project assets.
Stable naming supports integration, but replacement media must still match accepted facts. A clip from another landing or showing premature docking is not equivalent merely because its filename matches.
Review facts before final production
Lock identity, location, props and temporary state, then test framing, motion and boundaries with a low-cost draft. Existing references support controlled changes; higher resolution does not repair boat-position or identity drift.
Inspect first, middle and last frames, then play normally. The boat starts where established, no extra vessel appears, and the ending cannot show docking while subsequent text still asks the player to wait. Connect adjacent media boundaries too.
Locate the failed fact before regenerating. A preferred visual style is an art decision, but visual appeal does not justify changing a gameplay result.
Define behavior when media fails
Specify preloading, playback, skip, focus loss, mute and resource release. Convert unsupported media during the build rather than requesting a supplier while the player is running the game.
Here video is optional presentation, with an accepted still and event-text fallback. Simulate a load failure and confirm the signal result, necessary information and waiting choice remain available, without issuing a second reward on return. A permanent loading error is not a usable fallback.
If the brief makes a media effect indispensable, do not silently replace it and claim completion. Show a clear error and resolve the relevant build issue. Walk both normal and failed-media paths to verify that the asset supports play.
FAQ
Can a generated clip replace player interaction?
A clip can carry a fixed presentation. Player-controlled perspective, position or rule outcomes need real interaction. Commit results through game rules, then present them in media.
Do it with the skill
Use $game-build to integrate accepted media with stable paths, triggers, locked facts and boundaries. Register fallbacks and verify legal states after playback, skipping and load failure.
Read the method: Media storage, continuity and failure handling