Game options: advise me?

The game I’m writing has a number of options one might set. thrust, gravity, things like that. all are numeric.
Presently I have some parameters set up for adjusting these, and a save button that saves them to local storage when you like them. but that just saves the current ones.
It might be nice to have several sets, with names, and some way of selecting which set to use. That could be done with buttons, or a parameter 1 thru 5, whatever.
But what’s a good way to save several sets of parameters? I can serialize them and save them as strings in local data, and compile them in or json decode them.
Are there other good ways? What might you suggest I try? Thanks!

Create 5 buttons and depending on which button the player selects, use the values for that button. You can read and save the values based on that button. If button 1 is used, read/save thrust1, gravity1, etc. Of course, button 1 could have a better name. You don’t have to serialize them if you give them unique names. 5 sets isn’t that many, so you probably don’t need tables.

hmm … do you mean on button1 save to local data something like “button1_thrust”, “button1_gravity” and the like, and copy those values to the globals used in the adjustment sliders? and i guess i’d need 5 save buttons and 5 load ones?

Yes, something like that. You could have one read and one save button. When you want to read, press read then the button you want to read. Press save, then the button you want to save. There’s probably better ways, but I haven’t given it much thought.

@RonJeffries I tried some things and here’s a simple version that might help. Press read or save then one of the settings buttons. You can add more options to the sett function.

function setup()
    rectMode(CENTER)
    name={"settings1","settings2","settings3","settings4","settings5",
        "read","save"}
    btn={}
    table.insert(btn,button(50,300,1,sett))
    table.insert(btn,button(50,260,2,sett))
    table.insert(btn,button(50,220,3,sett))
    table.insert(btn,button(50,180,4,sett))
    table.insert(btn,button(50,140,5,sett))
    table.insert(btn,button(50,500,6,function() read=true save=false end))
    table.insert(btn,button(50,460,7,function() save=true read=false end))
end

function draw()
    background(40, 40, 50)
    for a,b in pairs(btn) do
        b:draw()
    end
end

function touched(t)
    for a,b in pairs(btn) do
        b:touched(t)
    end
end

function sett(v)
    if save then
        --saveLocalData(name[v].."gravity",gravity)
        --saveLocalData(name[v].."thrust",thrust)
        -- add more options
        print("save",name[v].."names")    -- remove
    end
    if read then
        --gravity=readLocalData(name[v].."gravity")
        --thrust=readLocalData(name[v].."thrust")
        -- add more options
        print("read",name[v].."names")    -- remove
    end
    save=false
    read=false
end


button=class()

function button:init(x,y,v,f)
    self.x=x
    self.y=y
    self.v=v
    self.f=f
end

function button:draw()
    fill(255)
    if (save and name[self.v]=="save") or (read and name[self.v]=="read") then
        fill(0,255,0)
    end
    rect(self.x,self.y,80,30)
    fill(255,0,0)
    text(name[self.v],self.x,self.y)   
end


function button:touched(t)
    if t.state==BEGAN then
        if t.x>self.x-40 and t.x<self.x+40 and t.y>self.y-15 and t.y<self.y+15 then
            self.f(self.v)
        end
    end
end

ah interesting, the save/read sets a mode, then the other button uses the mode. i was taught that modes are evil but it’s an interesting trick in this context, thanks.

modes are evil ??? Nothing in programming is evil. You just have to watch what your doing. If you get sloppy with your code, you’ll have trouble with anything.

Yes, and some tools are more dangerous than others. the mode is always tricky. for example, in your example (only an example, and a good one) once we touch a save or load button, we WILL save or load. Now that’s easy to fix, toggling the flags instead of setting them. And yes, it is just an example. It’s also an example of how modes can get us locked onto a situation that is tricky to get out of. Here, no big deal, don’t get me wrong. I like the idea and will quite likely use it. And in addition to being a neat idea, it’s an example of why modes need to be used with great care.

There is always a need for care. Sufficient sloppiness will break anything. However, there surely are practices that are easier to get wrong, and some that are easier to get right. Modes are one that raise a flag for me, and maybe raising the flag is enough. Or maybe I’d lean a bit away from them.

And in this case, it’s a really nifty idea. Thanks!