datastoreservice serialization
1x5x0x7x3
0:00 / 0:00
datastoreservice serialization
28 просмотров · 6 дн. назад
1x5x0x7x3
542 подписчика
28 просмотров · 6 дн. назад
We have 3 DataStores: Save_Slots, Player_Data, and Office_Data.
Player_Data and Office_Data are designed to be completely scalable. I can add, remove, or change folders, values, attributes, etc. inside PLAYER_DATA and GAME - DATA - SAVE without needing to edit the actual saving/loading scripts.
Save_Slots is different. Its only job is to store the hashes that point to saves, so it shouldn't really need to be expanded.
Basically:
Save_Slots = saves/loads save hashes
Player_Data = saves/loads everything inside PLAYER_DATA
Office_Data = saves/loads everything inside GAME - DATA - SAVE
How it works
Every 150 seconds, or when a player leaves, Player_Data saves the entire PLAYER_DATA folder.
Office_Data saves the entire GAME - DATA - SAVE folder whenever the day changes or the session ends.
It basically records the names, values, attributes, and hierarchy of everything inside those folders.
When a player joins, the game creates the normal PLAYER_DATA template, then compares it to their saved data and automatically changes it until it matches their save.
So it can automatically create, delete, rename, re-attribute, or re-value things without me having to manually tell the datastore what each individual thing is.
Office_Data works basically the same way, except it loads when an Office is started.
Save Slots / Hashes
Save Slots basically just point to an Office save using a hash.
When you load a save, that save is used to start your Office. Once the Office is running, it creates a new hash for that session and replaces the old hash in the owner's save slot.
Because hashes are session-based, you can't go backwards through every day you've played in one session.
For example, if you play from Day 1 → Day 5 and leave, your save starts at Day 5 when you come back. You don't keep separate hashes for Days 2, 3, and 4.
Memory Repository is what lets you go back to older MemRep days.
It works mostly like Lobotomy Corporation's Memory Repository, except:
You can MemRep to any available MemRep day.
If you MemRep and eventually complete another day, that new version overwrites the old save for that specific day.
So if you were on Day 30, MemRep'd to Day 1, and played back up to Day 6, your new Day 6 would replace the old Day 6.
It doesn't affect later MemRep days, though. Your Day 11 would still be there.
Hashes can also be shared.
If someone loads your hash, they can play from your save as a starting point, but they can't overwrite your save. Their game creates a new hash for themselves.
The project is still WIP. I'm mainly showing off the hopefully-finished DataStoreService handler, since the whole point is being able to change basically anything in my data without having to go through every script and manually tell it what needs to be saved.
And for anyone wondering what the actual game is supposed to be:
It's a rogue-lite dungeon crawler set in Project Moon's The City.
In this AU, L Corp accidentally causes a bunch of self-replicating Abnormalities to spread throughout the City.
You play as Fixers whose job is basically to clean up L Corp's giant mess.
You start as a nobody and work your way toward becoming a Grade 1 Fixer, potentially even a Color.
You'll take on:
Missions — the main story
Contracts — procedurally generated jobs with deadlines and big rewards
Quests — smaller objectives you find while actually exploring districts
The goal is to survive and get stronger all the way up to Day 50.
The basic gameplay loop is basically:
main menu → pick a district → go there → beat stuff up / do jobs → leave → get stronger → repeat
And some problems can spread throughout the City if you don't deal with them quickly, making them more dangerous over time.
YES, I USED CHATGPT TO GENERATE THE DESCRIPTION, MY ENGLISH ISN'T GOOD ENOUGH TO SIMPLIFY THE ENTIRE THING DOWN ENOUGH TO FIT IN THE 5000 CHARACTER LIMIT DESCRIPTION SO HOPEFULLY THIS EXPLAINS IT WELL ENOUGH. THANK YOU!!! basically a modular, scalable, serialized datastoreservice. the concept is relatively simple, but the execution... oh the execution, it's so complicated i could never explain it in a million years.
also, AI was used in the creation of this project to create the UI since I suck at making UI. Also it helped a bit with creating the actual datastoreservice stuff.
probably really unoptimized but oh well, it works.