Version Control and Backups for No-Code Game Dev

A no-code game project is a folder of files, and files can be versioned and backed up like any other. The whole practice fits in two habits: save the project in a file-friendly mode your engine already has, and put it somewhere that keeps every version and survives your laptop. GDevelop and Construct both ship the mode, Godot is friendly to it by default, GitHub Desktop covers the storage without a terminal, and a weekly zip covers what both of them miss.

The reason this article exists showed up twice in the community reads we ran in September. A developer on r/gdevelop lost their source and rebuilt from an exported build, then found that "assets made after the build are basically lost." Another watched a project break "suddenly and without any reason" and had no earlier state to return to. Source-file loss has now appeared in our reads two weeks running, across engines, and in every case the missing thing was not skill. It was a setting and a habit, both set up in an afternoon.

This article covers what you are actually protecting, the one setting that makes no-code projects work with Git, the cloud features your engine already includes, and the backup rule that covers fire, theft and ransomware. A disclosure before we start: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha, and what we plan to do about this problem is near the end.

Quick answer#

What you are actually protecting#

Three things sit on your disk, and only one of them is irreplaceable.

1. The source project. The file or folder your editor opens: scenes, events, objects, layouts. This is the months of work. It cannot be reconstructed from anything else you have.
2. The assets. Sprites, audio, fonts, tilemaps. Often imported into the project but living outside it. Replacing them means redoing the art or paying for it again.
3. The documents. Your game design document, notes, spreadsheets. Cheaper to redo than art, dearer than nothing.

What is not on the list: exported builds. An export answers what the game does; the project answers what the game is made of. The r/gdevelop developer rebuilt from an export because it was the only surviving artifact, and everything created after that export was gone. Treat every export as disposable output, because it is.

Version control and backups solve different failures#

The two terms get used interchangeably and shouldn't be.

Version control is history. It answers: what changed, when, and what did the project look like before this edit broke it. The failure it protects against is you, last Tuesday.

Backup is survival. It answers: if this machine, this disk, this building goes away, does the game survive? The failure it protects against is the world: disk death, theft, the ransomware that Construct's own best-practices page lists alongside fire and flood.

Each fails without the other. A repository you never push is a folder on the same dying laptop. A cloud sync with no history is a machine for copying today's corrupted file over yesterday's good one, everywhere, instantly. The rest of this article sets up both.

The one setting that makes no-code projects work with Git#

Git was built for text, because text is what lets it store a change as a difference instead of a whole new copy. No-code engines have noticed, and each has a mode for it.

Why the mode matters so much: in single-file mode, moving one sprite rewrites the entire project file, so every saved version is an opaque full copy, differences are invisible, and two people editing means one overwrites the other. In folder mode, that same edit touches one small file, history becomes readable per scene, and the size of each stored change shrinks to what actually changed. If you are still choosing a tool rather than configuring one, the overview of no-code 2D engines places these three and their workflows side by side.

A practical note for single-file holdouts: a .c3p is not locked. Rename it to .zip, extract it, and you have a folder project; zip a folder back up, rename, and you have a .c3p again. The conversion is lossless in both directions, which tells you how little the format itself was the obstacle.

Route 1: Git without a terminal#

GDevelop's official tutorial walks the full sequence, and it generalizes to every engine:

1. Make the repository first. In GitHub Desktop: File, New Repository, create, then Publish repository with Keep this code private checked.
2. Save the project into it. New project: choose the repository folder as its location. Existing project: Save As into the repository folder and abandon the old location.
3. Commit after every work session. Write a one-line summary of what changed, commit, push. The tutorial's illustration shows multiple commits per day; its stated rule is that commits should be completed frequently.
4. Branch for experiments. New branch for a risky rework, commit there, merge when it works. This is the whole feature: trying something destructive without risking the working game.
5. Restore when needed. When something breaks quietly, open the history in GitHub Desktop, pick the last known-good commit, and the project returns to that state.

Numbers worth knowing, all from GitHub's own documentation: free personal accounts include unlimited private repositories with unlimited collaborators; Git warns about files from 50 MiB and blocks pushes above 100 MiB; Git LFS on the free tier includes 10 GiB of storage and 10 GiB of monthly bandwidth, with individual LFS files capped at 2 GiB, and additional data packs cost 5 dollars a month for 50 GB of storage and bandwidth. A 2D project's scenes and events are tiny text files; art and audio are what consume the LFS quota, and a hobby project fits inside the free allowance for years.

Two exclusions keep the repository healthy. Exports do not belong in it, since they are large, reproducible, and useless to the editor. Godot's .godot cache folder and binary .translation imports do not belong in it, and the project manager's generated .gitignore handles both without you reading a line of it.

Route 2: The cloud your engine already has#

If Git today is a step too far, the engines' own services cover part of the risk, and it is worth knowing exactly which part.

GDevelop Cloud stores projects online and shares them with view or edit access. Sharing requires the Pro subscription on collaborators, with one guest per project, and the docs are candid that real-time collaboration is not yet ready. The conflict behavior is the telling detail: when two people have edited, saving offers overwrite the other person's changes or cancel your own. No merge, no history. The cloud is durability, not version control.

Construct Cloud Save writes the project directly to Google Drive, Microsoft OneDrive or Dropbox. Construct's manual points out that these services provide built-in backups and file histories of their own, which is a genuine second line of defense, bounded by each provider's retention policy rather than by anything you control.

Construct's automatic backups deserve a switch-flip regardless of where you save. In Settings, under Save & backup, check Periodically back up active project, choose an interval such as 10 minutes, and choose a location. The manual's own warning about location is the important part: a backup folder on the same machine as the project is not a backup, because one disaster takes both. It recommends the feature alongside Cloud Save, or with a folder that syncs itself to a cloud, such as a local Dropbox folder.

The browser-storage trap. Where local file access is unavailable, Construct can keep projects in browser storage, and the manual is blunt about the risk: the storage belongs to one browser on one device, and clearing browser data the wrong way erases every project in it. It recommends a different save option wherever possible. If your only copy of anything has ever lived in a browser, that copy does not exist. The same trap runs on the player side of your game: a browser build that keeps progress in local storage loses it to the same clear-data click, and the cloud saves without a backend guide covers that half of the problem.

The 3-2-1 habit#

The rule the backup world converged on, usually credited to photographer Peter Krogh: keep three copies of anything you cannot lose, on two different kinds of storage, with one of them off-site. Construct's best-practices page arrives at the same place from the game side: off-site backups are essential, because fire, flood, theft, hardware failure and ransomware all take the copies that live together.

For a no-code project, the cheap version:

1. Copy 1: the working project on your machine, where the editor reads it.
2. Copy 2: the pushed repository, or a Cloud Save project. Off-site by definition, versioned if it is a repo.
3. Copy 3: a dated zip on a different service or disk. Once a week: zip the project folder plus your asset sources, name it after the date, drop it on the external drive or the cloud account you do not use for the repo.

Five minutes, Friday, done. The zip is deliberately dumb: it survives even if you lose the GitHub account, the cloud has an outage, or ransomware encrypts everything the machine can reach, which is exactly the scenario an always-on sync folder cannot save you from.

Shipping it this week#

1. Switch the save mode. GDevelop: Properties, multiple files. Construct: save as project folder. Godot: nothing to do, generate the metadata anyway.
2. Create the private repo and move the project into it. Repository first, then Save As, as in the GDevelop tutorial sequence.
3. Commit and push today. One initial commit is the whole difference between protected and not.
4. Turn on automatic backups in your engine where the option exists, at an interval short enough that losing the work since the last backup would not hurt.
5. Exclude generated files before the first commit if you can, after it if you must; history tolerates cleanup.
6. Tag or note the commit for every build you hand out. When your game reaches Steam publishing or a playtest, you want to know precisely which project version produced the build players saw.
7. Friday zip, weekly. Calendar reminder, five minutes, three-two-one done.

Common mistakes#

• Treating an export as the backup. It is output, not source; rebuilding from one is the r/gdevelop story this article opened with.
• Committing monthly, pushing never. An unpushed repository is a single point of failure with extra steps.
• Staying in single-file mode. Every version is an opaque blob, diffs are meaningless, and nobody can work in parallel.
• Cloud sync as the only copy. Sync faithfully replicates corruption and, in GDevelop's sharing, resolving a conflict means someone's work is discarded wholesale.
• Projects living in browser storage. One clear-data click and they are gone; Construct's own manual recommends against relying on it.
• Backups on the same disk or in the same building. The manual's list of what takes them together is fire, flood, theft, failure, ransomware.
• Exported builds in the repository. They bloat every clone, and the 100 MiB block will eventually reject one mid-push.
• No record of which version shipped. A playtester's bug report about build 3 is archaeology without a tag; versioning the project only pays when builds map back to it.

How Egmatic fits#

We will be direct about the stage: Egmatic is a no-code 2D editor and engine, built on AI, currently pre-alpha. The reason this topic is on our blog is that we keep meeting it in the wild: lost sources, silent corruption, and rebuilds from exports have recurred in our community reads for weeks, and the people it happens to were busy making games, not neglecting obvious tools. The tools were not obvious. They were assembled for programmers.

Our position is that project safety is ship-layer work. An editor that carries a game from scene to shipped should carry its history with it, so that versioning, rollback and off-site copies are properties of the workflow rather than a self-taught weekend. You direct the game, the tooling executes the plumbing, and you own what ships, history included. We are not announcing dates; pre-alpha honesty means dates arrive when we can keep them. If that workflow is the one you are waiting for, it takes shape on the waitlist at egmatic.com, and the requests that arrive now, including yours about how your projects should be protected, are the ones that steer the build.

Never lose the version that worked.

Project history and safe backups belong in the editor, not in a weekend of tutorials. Egmatic is a no-code 2D editor with a ship layer, pre-alpha. Reply on the waitlist with what your project safety needs: requests sent now are the ones that steer the build. Build news goes to that list first.

you@example.comGet Build News

No spam. Unsubscribe anytime.

Conclusion#

Protect the source, not the export. Switch the save mode that turns the project into trackable files, put it in a private repository through GitHub Desktop, push after every session, and keep a third dated copy somewhere the machine cannot reach. GDevelop, Construct and Godot all meet you halfway by design, the engines' cloud features cover the hardware-failure half, and the Friday zip covers what nothing else does. The whole setup costs one afternoon, and unlike the game, it is the part that never crashes: it just quietly makes sure there is always a yesterday to go back to.

Sources#

1. GDevelop Wiki, Properties of the game: project file type, single file by default, multiple files so each scene, external layout and external event sheet is saved separately, recommended for version control systems
2. GDevelop Wiki, How to backup and maintain your project using GitHub and GitHub Desktop: repository-first sequence, multiple-file recommendation, per-feature branches, frequent commits, restore from history
3. GDevelop Wiki, Collaborate on a GDevelop project: cloud projects, view and edit sharing, Pro subscription requirement with one guest, real-time collaboration not yet ready, overwrite-or-cancel conflict resolution
4. Construct 3 Manual, Saving projects: Cloud Save to Google Drive, OneDrive and Dropbox; download-a-copy .c3p; project folders recommended for source control with text-based files; .c3p as a zipped folder project; browser-storage limits and the clear-data risk
5. Construct 3 Manual, Best practices: back up regularly, off-site backups essential against fire, flood, theft, failure and ransomware; Periodically back up active project setting with interval and location
6. Godot Docs, Version control systems: VCS-friendly readable and mergeable files, Git plugin, generated .gitignore and .gitattributes, .godot folder and .translation exclusions, Git LFS setup guidance
7. GitHub Docs, About large files on GitHub: warning at 50 MiB, blocked above 100 MiB, 25 MiB browser upload limit
8. GitHub Docs, About Git Large File Storage and GitHub's plans: 2 GiB per-file LFS cap, unlimited private repositories on free accounts; LFS inclusion and data pack pricing per the pricing page
9. Community reads, September 2026: r/gdevelop reports of source loss and silent project breakage, quoted from the Egmatic feedback digest; verbatim phrases used with context