Need a game options module

[StLoch]

It will give us somewhere to store persistent data like key mappings, graphics settings, etc... Things get pushed to disk on exit and loaded back up on launch. When the user makes changes to the GameOptions object, the changes should be held in a sort of limbo and applied all at once (much like it works in typical options menus). When settings are applied, changed settings should trigger certain procs that are capable of updating the game state in an appropriate manner to suit the new changes. For example:

Changing the resolution or the fullscreen option means we have to recreate the window. When 'apply' happens, if either of these settings have changed, the "create new window" proc will be called (only once), where it can destroy the current window, if needed, and create the new one with the proper settings.

Using procs allows us to decouple the logic associated with changing the settings from the GameOptions object and rather rely on the scope best suited to making the changes happen.

[StLoch]

I'm not sure if this should be treated as a "stupid" data saving object or as something with actual intelligence (for example, it know that when switching to full screen, we need to destroy the current window and recreate it as full screen). I'm thinking the latter might be more useful, but I worry about all of the dependencies it might cause. Perhaps this can be mitigated by splitting this into sections (Graphics section, Input section, etc...)?

[StLoch]

Oh, or perhaps there is cleverness that can be done using closures in ruby! We can define the object as little more than a data saving object and attach procs to the various getters and setters and then define these in places that make sense. No coupling and all of the awesome.

[StLoch]

Another question is if things should use IT or if IT should use things. MHCore will need to read some options to create the default window, for example. Is this OK or are we going to end up with 30 things that require this options class to work?

[datalurkur]

I vote that other classes should use it. For example, I imagine the UIManager talking to it to say things like "give me a list of the possible resolutions" and tell it things like "the user has selected this resolution, switch to it," at which point it can call a proc that some other class (gamestate, in this case) has passed it previously.

[StLoch]

Oh man, my last comment wasn't at all clear. Your example would definitely happen as you've described, but it's not quite what I was trying to get out. Here is a better explanation of what I was trying to comment on. There are two ways I could see initial startup going:

1) MHCore loads up the GameOptions object and reads in the resolution, bpp, and fullscreen settings and creates the window itself with the values read from the stored options.

2) MHCore loads up the stored options and the act of loading triggers the various procs associated with setting certain actions. These procs do things like re-create the window with the proper settings. Since a window doesn't already exist, the initial window would just be created with the proper settings.

A similar example: Default material settings need to be set in the MaterialManager. We can either: a) Manually read the options and set them ourselves or b) rely on the procs to do it for us.

The latter certainly sounds nicer in terms of avoiding duplicate work, but there are other things to consider like what additional bindings might we need to write to make it work, what sort of default initialization stuff is currently in place we'll need to change, etc... I think it will be a bit more work to get going, but probably much happier in the long run.

One way we'll definitely want the option procs to work is that rather than triggering automatically, we'll have the options object store changes and have an "apply" method that actually sets things, saves the new stuff to disk, and activates the procs according to what has changed.

I'll update the main task description with all of this. I should have earlier this morning.

[StLoch]

Oh right, and of course there are cases (like with key bindings) where the appropriate object for GameOptions to modify won't even necessarily exist yet. We have to be able to handle cases like this, as well.

[datalurkur]

I like the idea of using procs. It's more flexible and probably won't require too much extra effort. I agree, in the end, it will be worth it.

[datalurkur]

This is already past discussion and well underway.