@Delightex_Team I believe this is something that could genuinely change the platform in some way, shape or form for the better. I hope you read this post, I spent quite a while and put a lot of effort into it. from what I know, this has never been done before, so even though its a tedious process, I think this is both impactful, and a HUGE step forward in delightex coding. Thank you.
Have you ever wondered if you could save player data in Delightex EDU?
Maybe you have a game where players build things, unlock items, make progress, customise a world, or create their own levels. You may want a way for players to save what they have done and come back to it later.
I was thinking about this too, and instead of trying to save the entire world itself, I started thinking about something different:
What if the game could create its own save file?
Theoretically, the idea is pretty simple. Your game records the important information about what the player has done, turns that information into save data, and lets the player copy that data somewhere safe. Later, they can paste it back into the game, and the game reads the save file and rebuilds the saved data.
This isn’t the same as just clicking a button and boom, your data is saved. Its more like the player is essentially carrying their save file with them.
I’ve been working on this idea for my own projects, and I wanted to explain how it works and how YOU could use the same concept in your own Delightex games.
⸻
How the save system works
The first thing you need to decide is what your game actually needs to remember.
You don’t necessarily need to save everything that happens while the game is running. Instead, you can keep track of the important information that describes the player’s current state.
For example, if the player builds an object, you might record what type of object it is, where it is, how it is rotated, how big it is, and any other properties it needs. Or if they got to a checkpoint on an obby, it can record what level, the location, lives, etc
Then, when the player presses your SAVE button, your code takes all of that information and turns it into a save file.
The save file is basically a set of instructions for your game:
“This is what the player’s world looked like when they saved. Use this information to recreate it.”
The overall process looks something like this:
Player makes changes
↓
Game keeps track of the important data
↓
Player presses SAVE
↓
Game generates the save file
↓
Player copies the save data
↓
Player stores it somewhere
↓
Later, the player pastes it back
↓
Game reads the save file
↓
Game rebuilds the saved data
The important part is that you’re not saving the actual world.
You’re saving the information needed to add the changes the player made to the world.
⸻
A simple example
Imagine you make a building game.
A player places a chair, table and lamp.
Instead of somehow saving the entire scene, your game could record information such as:
Object 1
Type = Chair
Position = …
Rotation = …
Object 2
Type = Table
Position = …
Rotation = …
Object 3
Type = Lamp
Position = …
Rotation = …
When the player loads the save, the game reads those instructions and creates the three objects again in their saved positions and rotations.
You can do the same thing with almost anything that can be represented as data.
For example:
Coins = 250
Level = 7
SelectedCart = “Cart2”
TutorialCompleted = true
Or:
Objects
Positions
Rotations
Sizes
Properties
Settings
The exact format is completely up to you.
⸻
What YOU could save
This is where the system becomes really useful. And how you could add it to your own projects
If you’re making a normal progression-based game, you could save things like:
• Coins
• Levels
• Unlocked items
• Player settings
• Quest progress
• Tutorial progress
If you’re making a building game, you could save:
• Objects
• Positions
• Rotations
• Sizes
• Object properties
• Building settings
If you’re making a game where players create their own worlds, you could save:
• World objects
• Connections
• Positions
• Rotations
• Properties
• World settings
For example, in my Create a Cart Ride project, I can use this idea to save the information that makes up a player’s ride.
The save could contain things like track nodes, node positions, node connections, curve settings, track settings, objects the player added, and other information required to rebuild their creation.
The game doesn’t have to save every individual piece of track.
It can save the node information, then generate the track from those nodes again.
That’s one of the main reasons I want the track system to be node-based.
⸻—-
Creating the save file
Once your game knows what information needs to be saved, you need a way for the player to actually export it.
I would have a SAVE button that tells the game to collect the current data and generate the save file.
Ideally, the game can then use the clipboard function to copy the generated save data automatically.
So from the player’s point of view:
Press SAVE
↓
Game generates save data
↓
Save data is copied
↓
Player pastes it somewhere safe
However, I wouldn’t make the entire system depend on the clipboard working.
If clipboard copying doesn’t work, the game can put the generated save data into the TypeScript output instead.
The player can then manually copy it from there.
That gives you a fallback:
SAVE
↓
Clipboard
or
SAVE
↓
Output
↓
Manual copy
The save itself is still the same. You’re just giving the player different ways to get the data out of the game.
⸻
Where does the player store it?
This is one of the biggest differences between this system and how other games work when you press save (or save and quite).
The player is responsible for keeping their save file.
They could put it in a text document, notes, cloud storage, or anywhere else that can safely store text.
Your game doesn’t need to know where they keep it.
It only needs the save file again when they want to load it.
This also means the player could potentially send their save file to someone else.
And that leads to another interesting possibility: sharing creations.
⸻
Loading the save file
Your game needs somewhere for the player to paste their save.
For example:
(Inside the typescript code)
SAVE FILE
[ Paste your save here ]
And then a button in game that reads
[ LOAD ]
Or
[ SAVE SLOT 1 ]
When the player presses it, your game reads the data and checks that it is actually a valid save file.
It can check things like:
• Is the save formatted correctly?
• Is the save version supported?
• Is important data missing?
• Are the values valid?
• Are the objects allowed?
If everything checks out, the game can start rebuilding the saved state.
For a building game, that could mean creating every saved object and applying its position, rotation and properties.
For a progression game, it could restore the player’s level, inventory and unlocked items.
For (my game) Create a Cart Ride, it could read the saved nodes and connections, generate the track, create the saved objects and apply the saved settings.
The save file tells your game what needs to exist, and your game does the actual work of creating it.
⸻
Save file versions
One of the most important parts of this system is versioning.
Imagine you release your game with Save Version 1.
Someone creates a huge build and saves it.
Later, you update the game and change the way some of your data is stored. Your new game now expects Save Version 2.
If you simply try to load the old save as if it were Version 2, it could break.
So you can put a version number inside every save file.
For example:
Save Version = 1
When the game loads it, it first checks the version.
If it is an older version, you can have code that converts the old format into the new format before loading it.
For example:
Version 1 Save
↓
Convert to Version 2
↓
Load Version 2 data
Eventually, you could have:
Version 1
↓
Version 2
↓
Version 3
↓
Current Version
This is what I called migration.
It means that you can update your game without automatically making every old save file useless.
This is especially important if you expect players to keep their saves for a long time.
⸻———
What if the save is broken?
You also don’t want your game to blindly load whatever text the player pastes into it.
A save file could be incomplete, corrupted, from an unsupported version, or even manually edited.
So your loader should validate the save before trying to build anything.
For example:
Is this a valid save?
↓
Is the version supported?
↓
Is the required data there?
↓
Are the values valid?
↓
LOAD
If something is wrong, the game can simply tell the player that the save couldn’t be loaded instead of breaking the whole game.
Something like:
Invalid Save File
This save is corrupted or uses an unsupported version.
This becomes even more important if you allow people to submit their saves to other players or to a community system.
⸻
How YOU could use this for sharing builds
Because the save file is just data, you don’t necessarily have to keep it private.
A player could save their creation and send the save file to someone else.
The other person could paste it into the game and have the game rebuild the creation.
For example:
Player A
↓
Creates build
↓
Saves it
↓
Sends save file
↓
Player B
↓
Pastes save file
↓
Build is recreated
For my Create a Cart Ride project, this could eventually be used for community rides.
A player could create their own track, save it, and submit the save file through a form.
I could then review the save before adding it to the official game’s community builds.
So the process could be:
Build ride
↓
Save ride
↓
Copy save file
↓
Paste into submission form
↓
Review
↓
Approved
↓
Community Build
This means the save system could become more than just a way to protect your own progress. It could also become a way of transferring and sharing player-created content.
⸻
Mobile and PC limitations
There is a pretty important limitation with this approach.
The actual game can be made to work on mobile, but accessing and editing the TypeScript side of a Delightex project is much more limited on mobile.
Players need to remix the game on PC to properly access the code section.
And because the game is code-based, updates can make this more complicated.
If I update the original game, someone using an older remix will need to re-remix the updated game to get the newest code.
So the workflow isn’t necessarily:
Game gets updated
↓
Everyone automatically gets the new code
For someone working from their own remix, it can instead become:
Original game gets updated
↓
Player has an older remix
↓
Player may need to remix the updated game
That is a somewhat significant limitation for a game that’s dependent on changing/adding to the code manually for save files, however. With versions and migrating added**.** As long as the player has a valid save file, after re-remixing the game, they can simply paste that save file into the newly remixed project, and with save file migrating it can safely be updated to the newer version. And as a little bonus, players can always go back to old versions of the game
⸻
What about saving on mobile?
There is potentially a workaround, but I would consider it very limited and unreliable.
If the TypeScript output can be accessed on mobile, a player might be able to save their build, copy the generated save data from the output, and paste it into a form.
For example:
Mobile player
↓
Presses SAVE
↓
Save data appears in output
↓
Player copies it
↓
Player pastes it into a form
↓
Save can potentially be stored/reviewed
For example, with my project, a mobile player could potentially submit their Create a Cart Ride save this way and request that I save or review it for them.
But this depends on multiple things working correctly.
• Whether the output can actually be accessed on mobile
• Whether the player can select and copy it
• Whether clipboard functionality works
• How large the save file is
• Whether the submission form accepts that much data
• Whether the save is valid
• Whether the build can actually be reconstructed
So I wouldn’t call this a proper mobile saving system.
It’s more of a workaround that might work in certain situations.
⸻
Some of the biggest challenges
There are quite a few things you need to think about if you want to make your own save system.
Save file size
A huge player-created world could generate a very large save file.
You need to think about how efficiently you store the information so that players aren’t copying enormous amounts of text.
Corrupted saves
A player might accidentally copy only part of the save file, or the data could otherwise become invalid.
Your loader needs to handle that safely.
Version compatibility
As your game changes, old saves need to remain usable.
This is why save versions and migration are so important.
Validation
You need to make sure that the data you’re loading actually makes sense.
This becomes particularly important if players can submit save files to you or share them with other people.
Clipboard limitations
Clipboard access may not behave exactly the same everywhere, so having the output as a fallback is useful.
Mobile
Mobile is probably the biggest limitation.
The game itself can work on mobile, but accessing the code/output and moving large save files around is much more difficult.
Remixing
If players need to remix the game to access the TypeScript code, updating the project can become inconvenient.
Manual storage
Because the player is carrying the save file themselves, they can lose it.
There is no magic button that automatically puts it back onto their account.
⸻
How this fits into my project
I’m using this system as part of my Create a Cart Ride project, but the save system itself is designed to be much more general.
The game lets players create and modify rides using a node-based track system.
So a player’s normal workflow could eventually be:
BUILD
↓
TEST
↓
MODIFY
↓
TEST
↓
SAVE
↓
Keep the save file
↓
LOAD later
↓
Continue building
And then, if they want to share their creation:
SAVE
↓
SUBMIT
↓
REVIEW
↓
COMMUNITY BUILD
The save file is what connects all of these systems together.
⸻
Summary
The basic idea is:
-
Decide what information your game needs to remember.
-
Keep track of those changes while the player plays.
-
When the player presses SAVE, turn that information into a save file.
-
Copy it using the clipboard if possible, or let the player copy it from the output.
-
Let the player store that save file somewhere.
-
Give them a Save File section where they can paste it later.
-
Validate the save and check its version.
-
Convert older versions if necessary.
-
Use the data to rebuild the player’s world, progress or creation.
And because the save is just data, you can potentially use the same system for sharing builds, backups, community content, player-created levels and much more.
⸻
Final thoughts
I think this is a pretty interesting way of approaching saving in Delightex EDU.
Instead of asking:
“How do I save the entire player’s world?”
you can ask:
“What information would I need to recreate the player’s world?”
Once you can answer that, you can turn that information into a save file.
There are definitely some big limitations, especially around mobile, remixing, clipboard access, save size, validation and keeping old saves compatible with newer versions.
But I think the concept has a lot of potential.
For my Create a Cart Ride project, it could eventually mean players can build their own rides, save them, come back to them later, share them with other people, and even submit them to be considered for official community builds.
And you don’t have to use this idea for a cart game. If YOU are making a game where you want some kind of saving sytem, you could potentially build your own system around the same concept.
If you have ideas for improving this, have found a better way of handling saves, or know of something that could make this easier, I’d really like to hear about it.
And if you think this could be useful to other Delightex creators, please spread the word about this post. The more people thinking about this kind of system, the more possibilities there are for what we can build with it.
Thank you for reading this (very) long post! Have a good day (or night depends).
Any questions/ideas? Reply to the post and I’ll be sure to answer to the best of my ability!