Change your game without losing the version that worked
Save a complete working project state before a meaningful change. Record what the change should improve, compare the result, and restore the whole relevant state if the experiment fails.
In this guide
A practical workflow for comparing changes, restoring a version, and keeping an editable copy of your game.
Save more than the script
A game version includes scenes, scripts, assets, settings, and sometimes generated resources. Keeping yesterday’s movement file is not enough if today’s scene expects different node names.
Use source control or your tool’s project history to capture a coherent state. Keep external assets and dependencies traceable. Name the version by what works, such as “three deliveries and restart,” rather than “final-final-2.”
Write what the change is for
Before changing parcel weight, write the expected result: players should sometimes choose an early delivery. That makes the next play session a comparison rather than a vague impression.
Keep the scope of the change visible. If the assistant also replaces the input system or reorganizes scenes, review whether that work is needed before accepting it.
Replay the old promise
- Run the ordinary path from start to finish.
- Try the new behavior.
- Try failure and restart with the new state active.
- Check a previously working edge case.
- Save the result only when you can explain what changed.
Restore cleanly when the experiment loses
Return to the complete checkpoint rather than copying random files back until the game runs. Check that the restored version actually behaves as expected. A restore operation is not evidence until you run the project.
Keep a note about why you rejected the change. Perhaps it reduced clarity, made a choice obvious, or cost too much complexity. That note prevents the same idea from returning next week wearing a different name.
Keep a copy you can open
Download source where your tool supports it and include the engine version and run instructions. Test opening the copy in an appropriate environment. A zip file is a backup only if it contains what you need.
In the Dashpop Editor, inspect your project in Code and keep its artwork and saved creative choices with the source. Use undo to compare a control edit, and ask your agent to preserve a working project version before a larger change.
Put your idea to work with the Dashpop Game Engine. Describe a game, play it quickly, and shape it yourself. Start with one change you can test.