Saving System v4

[FifthTundraG]

Welp, here we are. I said I wouldn't do it, but when it comes to saving it seems I will never be satisfied.

• So why am I doing this? The main issue I have with the 0.6 saving system is that it relies heavily on the usage of eval(). At the time, my logic behind this was that since Clicker Cookie is a static site, there was no harm in this situation to using it. Then I thought about it way more than I should've and now I don't like it. It's a s** system that uses obscure methods to find the names and values of both variables and object properties, and anyone who didn't write it (you) cannot understand it without looking super* closely. It even took ChatGPT about 5 tries to figure out what I was asking it to write. The system I've been brainstorming for the past few weeks is, to be honest, more primitive than the old version when you first look at it, but it's actually very similar to the way Cookie Clicker saves, and really for me that's excuse enough.

• So how does it work? The new saving system stores its data in JSON formatting, but is more organized than the last system. It looks like this:

  {
  "header": {
      "version":"0.6"
      "versionBranch":"main",
      "format":"4"
  },
  "data": [
      data in old formatting
  ]
  }

  
  So let's break this down. First and foremost is the introduction of the header, which is to store info about the save, such as the version it was saved in, the branch it was saved in, and the format of the file. The reason I thought to introduce this is that in the old system, it had no way of differentiating between constant variables and mutable variables, so when it got to versionBranch it would just fail to change its value. It had no notable effect on saving/loading speeds, but it always bugged me it existed at all, it was one of the many cheap workarounds Clicker Cookie was built on. The format section of the file is simply because I know this won't stick. This saving system will inevitably change and I need a way to easily detect it, all old detection ways relied on stuff like the existence of a bracket, so not good.

Now for the data section. Data is going to be stored in an array of values, each index will be a different variable value. A great example of this is the very early version of the saving system from 0.5, except for this time instead of basing it on newlines it will be stored as an array.

• Won't that make main.js one line bigger for each variable? Yes, it will make the file substantially bigger, but 0.7 is going to be a massive overhaul to the way ALL code is handled, and with it will come breaking main.js up into multiple files to find what you're looking for much easier. So to answer the question, there won't be a long main.js file, there will probably be a long saving.js file.
• When is it coming? This is a big change for being so late in the 0.6 development cycle, and to get 0.6 out in a timely manner, I plan to release this system in either 0.6.2 or 0.7. It's going to require another annoying conversion process, but 0.6 is already months off schedule, and having another thing to worry about on top of adding 0.6's content to the mobile version isn't going to help anyone.

Ultimately, for me, this was a necessary change, and even though I know it will take an extremely long time to implement, I feel its addition is integral for Clicker Cookie to have an actual easy-to-work-with codebase, which right now it certainly does not.

[FifthTundraG]

Here's my new idea for how it should be done to make it a little more user-friendly and (maybe) help with save data for modding.

{
    "header": {
        "version":"0.6"
        "versionBranch":"main",
        "format":"4"
    },
    "data": {
            "core.cookies": 1542332,
            "core.cookiesPerSecond": 4838,
            // so on, so forth
    },
    "modData" {
            // this can be figured out later down the line
    }
}

The new data's keys, like "core.cookies", will be manually inputted, for example: save.data["core.cookies"] = core.cookies, for every variable being saved.

modData may or may not be used in the final draft, it depends on how nicely it works without any workarounds.