Backing Up a Game Project Before a Crash Costs You a Week

Every beginner I have taught has, at some point, lost work. A browser tab closed before the Scratch editor finished saving. A laptop update restarted the machine overnight. A "quick experiment" in Godot broke the main scene, and there was no earlier version to go back to. The loss is usually somewhere between an afternoon and a week, and it hurts far more than the time suggests, because it often lands just as the project was starting to feel real.

The fix is not complicated, and it does not cost anything. It is a small habit plus one or two free tools, set up once. This guide covers what to use for Scratch projects and for projects in a desktop engine, and how to check that your backups actually work.

Why game projects get lost so easily

Game projects are fragile in a way that a school essay is not. A single project is often dozens or hundreds of files: sprites, sounds, scenes, scripts and settings that refer to each other by name. Delete or overwrite one and the rest may stop loading. An essay with a missing paragraph still opens. A game with a missing scene file often does not.

Beginners also change things fast. When you are learning, you try an idea, it fails, you try another, and twenty minutes later you have no idea what the working version looked like. That is normal, and it is exactly the situation where a saved snapshot from an hour ago is worth more than any amount of careful undoing.

Finally, most first projects live in one place only. One laptop, one browser account, one folder. Anything that happens to that place happens to the whole project.

Cloud sync is not a backup

The most common thing students tell me is that their work is safe because the folder is inside OneDrive, Google Drive or Dropbox. Sync services are useful, and I use them, but they do something different from a backup.

A sync service copies your folder exactly as it is right now to every device. If you delete a scene by mistake, the deletion is copied. If a crash corrupts a file, the broken file is copied. These services do keep some version history, and it has rescued people, but how long it lasts and how easy it is to restore a whole project depends on the service and on your plan. It is a safety net with holes in it, not a plan.

A backup is a copy you can go back to after you have made a mistake. A sync is your mistake, delivered everywhere.

Keep your sync if you like it. Just add one of the methods below as well.

Scratch projects: three habits that cover most losses

Scratch is forgiving about many things, but saving is not one of them. If you work in the online editor, it saves to your account while you are signed in, and you can press "Save now" from the File menu. If you are not signed in, or the connection drops, changes may only exist in the open tab.

Download a copy at the end of every session

Use File, then "Save to your computer". This creates an .sb3 file that contains the whole project, sprites and sounds included. Name it with the date, for example jumper-2026-10-22.sb3, so you build a row of dated versions in a folder. A single .sb3 for a small game is usually a few megabytes at most, so keeping weeks of them costs nothing worth worrying about.

Use "Save as a copy" before big changes

Before you rebuild your movement code or replace your art, use "Save as a copy" in the online editor. You get a second project in your account and the original stays untouched. Students often skip this because it feels slow. It takes five seconds.

Keep one copy off the laptop

Once a week, put the newest .sb3 somewhere else: a USB stick, an email to yourself, or a folder in a cloud drive. That covers the case where the laptop itself is lost or broken.

Desktop engines: learn just enough Git

For Godot, Unity, GameMaker or any engine that stores projects as folders, version control is the right tool. Git is free, every engine works with it, and you do not need the command line to start. GitHub Desktop gives you a window with two buttons that matter: commit, which saves a snapshot on your computer, and push, which sends it to a private repository online. Our list of the free tools a small studio actually uses includes the rest of what we run alongside it.

Two things trip up beginners. First, add a .gitignore file so you are not saving the engine's cache folders. For Godot 4 that is the hidden .godot folder; for Unity it is folders such as Library and Temp. GitHub Desktop offers ready-made templates for common engines when you create a repository. Second, commit small and often, with a message that says what changed, such as "player can double jump" rather than "update".

Large audio and image files can make a repository slow over time. For a first or second project that is rarely a real problem, and I would not let it stop you from starting.

Which setup fits your project

If you have not picked an engine yet, the way each one stores files is worth a thought; we touch on it in choosing a game engine for your first solo project.

Test the restore, not just the backup

A backup you have never opened is a hope. The first time I asked a class to restore a project from their own backups, several found their "backup" was a shortcut to the original file rather than a copy, or a download that had never finished. Nobody had checked.

So, this week: pick your current project and make a backup with whichever method above fits. Then close everything, open that backup on a different computer or in a fresh folder, and play the game for one minute. If it loads and runs, you are covered. If it does not, you have found out on a quiet afternoon rather than the night before a jam deadline. And if something does break later, our notes on fixing bugs without losing your mind are a good companion to a project you can roll back.