1
\$\begingroup\$

I'm making a game using java. I'm wondering what would be the best way to store games options (like screen height and width, full screen boolean and many other similar options the user can select) at run time?

Currently, I read the options from a text file so everything that comes out of the reader is a string. I would like to add the value of the string to the appropriate variable in as few steps as possible. I would also avoid having to code getters and setters for all variables there is and have a general getter and setter that takes the name of the option as a parameter. ex:

    public void set(String name, Object value){ 
        options[name] = value;
    }

    public Object get(String name){
        return (Object options[name]);
    }

I was thinking about a hashmap of variable names and values but the problem is: not all variables are of the same type, I'll have ints and doubles and booleans. so what would be the best way to store all those different variable types and access them with general calls? Should I leave them as Object and cast them as I need to use them? Or do i really have to set them all manually in my code (which would be quite the hassle should i decide to add more options down the line)?

UPDATE: So, here's the code i got so far for serialization but still not working:

Options.java:

public class Options implements java.io.Serializable{

//Final variables declaration
static transient final String SAVE_DIR = System.getProperty("user.dir") + "\\res\\saves\\";
static transient final String OPTION_FILE = "options.ser";

//Static variables declaration
public int s_width;
public int s_height;
public float fov;
private static transient Options instance;

private Options()
{
    this.s_width = (this.s_width == 0)? 800 : this.s_width;
    this.s_height = (this.s_height == 0)? 600 : this.s_height;
    this.fov = (this.fov == 0)? 60 : this.fov;
}

public static Options GetInstance()
{
    if(instance ==  null)
        instance = new Options();
    return instance;
}

Serializer.java:

public class Serializer {
private static Options o = Options.GetInstance(); 

    public static void loadOptions()
    {       
        File dir = new File(Options.SAVE_DIR);
        if(dir.exists())
        {
            File file = new File(dir + "\\" + Options.OPTION_FILE);
            if(!file.exists())
            {
                saveOptions();
            }

            try {
                FileInputStream fileIn = new FileInputStream(file);
                ObjectInputStream in = new ObjectInputStream(fileIn);
                o = (Options) in.readObject();
                in.close();
                fileIn.close();
            } catch (IOException | ClassNotFoundException e) {
                e.printStackTrace();
            }
        }
        else
        {
            dir.mkdir();
            saveOptions();
        }
    }

    public static void saveOptions()
    {
        File dir = new File(Options.SAVE_DIR + "\\" + Options.OPTION_FILE);
        try {
            if(!dir.exists())
            {
                dir.createNewFile();
                o = Options.GetInstance();
                System.out.println("otpion.ser created and initialised succesfully!");
            }
            FileOutputStream f = new FileOutputStream(dir);
            ObjectOutputStream out = new ObjectOutputStream(f);
            out.writeObject(o);
            out.close();
            f.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}
\$\endgroup\$
0
\$\begingroup\$

From my experience working on codebases with millions of lines of code, and hundreds of settings encoded like this, I don't think it will be as much of a hassle as you think to have a getter/setter for each option. In fact, if you're using an IDE, it's actually fairly nice to be able to type "Options." and get a list of all the preferences in your app, rather than digging through files trying to remember if you named it "ScreenWidth" or "ViewWidth".

Make sure you're using java.serialization.io - Here's a good tutorial: http://www.tutorialspoint.com/java/java_serialization.htm

That way the only thing you ever have to add is the getter/setter itself. Saving to disk takes care of itself (assuming you're only ever saving primitive data types).

\$\endgroup\$
  • \$\begingroup\$ OMG!! that's exactly what i needed! now i can add all my options to my options class and simply serialize it to a file and deserialyse it to retrieve the saved options! I knew it was worth it to wait one more day to code that class! I was going to have a map or string and objects and try to figure out the type of each variables once casted as object LOL! what a pain! You just saved me tons of hours of coding and about 3 full bottles of tylenols! \$\endgroup\$ – Alkarym Moro Sep 30 '15 at 14:20
  • \$\begingroup\$ Great! Glad I could help. Java's built in serialization is much nicer than having to write it yourself, haha. Although, like I implied, it gets a bit messier if you need to serialize pointers. \$\endgroup\$ – tandersen Sep 30 '15 at 18:20
  • \$\begingroup\$ ok, i think i got lost on the way... so, i have my class Options which contains all the static values of all my options. I have a classe serializer that loads and save the content of my option class but when i do Options o = new Options and save that "o" it saves only the name of the class... what am i doing wrong? \$\endgroup\$ – Alkarym Moro Sep 30 '15 at 19:56
  • \$\begingroup\$ I don't think serializer works with static fields. Is there some reason you need them to be static? I would imagine your options file is the only instance in the program. \$\endgroup\$ – tandersen Sep 30 '15 at 20:41
  • \$\begingroup\$ well i was making them static so that i could access them by typing Options.screenHeight for example. I could make my class a singleton and insure that every instance of it are of the same object. I made them static as well because if I wanted to call Options.setScreenHeight() i could w/o intanciating a new Options object. \$\endgroup\$ – Alkarym Moro Sep 30 '15 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.