Checkpoint is a simple library for writing and reading data to and from files in a Defold game engine project.
There are many libraries available that more or less perform these ubiquitous file-related operations. Checkpoint differentiates itself by focusing on an extremely simple API, and perhaps more importantly, its ability to work with directory hierarchies rather than bloating one directory with multiple unrelated files.
Thanks, and happy Defolding.
Awesome! Very easy to use! Thank you! 
If you make a release in Github we will be able to include it in Game Project Dependencies easily, by just pasting the link to the release (you already added Checkpoint to Include Dirs 
). You can also submit it to the Defold Asset Portal
Thanks, appreciate it. Yeah, one of the two main goals was ease of use. Nothing fancy, just a straightforward and reliable utility.
Defold Asset Portal
Already being processed here.
release in GitHub
Frankly, I’m not entirely sold on the release feature. I might just be naive to its benefits since I don’t often do open source work. As for pasting a link into the game.project dependencies list, that can already easily be done with the /archive/main.zip link, as specified in the documentation.
Yes, this also works, if you keep the main branch clear and without breaking changes (or without any changes at all) then it’s totally fine, otherwise - using versioning allows users of you library to point to the specific version their code is using without breaking the game if there will be any such update to main branch provided. Users can as well fork the repo for safety too 
Well, if a user uses your code, and you suddenly decide to change your api, they may very well end up in trouble. Imagine getting strange issues in between two consecutive builds, they have to spend possibly a long time figuring out what went wrong.
Sure, they can also link to a specific commit, but for an api, using sha1 as the “version” number is not very clear.
So, we recommend users using the release feature of Github to make it clear to everyone using the library. Both you the developer, and the users.
I see, that clears it up. I’ll make a release and add it to the installation instructions then.
Edit: The main hesitation I’m running into is when to draft new releases in the future. If the API doesn’t break on future updates, then the /archive/main.zip is still valid. Meanwhile, the latest release would be outdated, so I’d be obligated to draft a new one. This would be true for every little change, which seems unnecessary and rather annoying. Am I missing something?
It’s up to the maintainer of the repository to release new versions. New version can be released any time whenever you decide. It doesn’t have to be after each small commit. For example, sometimes I update my libraries, prepare documentations update commits - only when I’m sure everything is working and is correct - I create a new release in repo. Sometimes I also make mistakes, so I need to add another commits and then after it I also make a release.
For example this library have 4 releases, but 9 commits:
Versions can be named however you like: 1,2,3,… or v1, v2, v3, or A,B,C,D or 1.0, 1.1, 1.2, or 1.0.1, 1.0.2, 1.0.3 etc. Good practice is usually SemVer (https://semver.org/), but I prefer ProudVer (you make a new release, when you are proud of your code xD).
Added function checkpoint.list(), which lists all files under the root save directory.
I’m currently working on a level editor and needed a way of displaying all downloaded levels to the player, such that they can be loaded, deleted, edited, etc.
