A discussion in the game subforum got me thinking about ways to architect platform independent code that provides players with options they can change - It seems more complicated than it should be.
(Btw: if you want to discuss whether options are a good or bad idea please use the game forum thread)
For a first pass, providing a Config() call might be the cleanest solution. Config() would just call Win32Config(), or LinuxConfig() ... etc
The platform layer then pops up a dialog box (using the OS windows/controls) with the options, apply the changes and return back to the game layer. If one of the options was to change the sound device output, then the game layer still gets a buffer to fill, it doesn't need to know that the sound card changed. Similarly, if the resolution is changed, the game layer doesn't know or care, it still just gets a buffer with size = (width x height) to fill.
The complication is if the options screen needs to be rendered using the game font and graphics. The platform code then calls back into the game code to render the options on screen - it starts becoming messy with the game layer calling the platform layer, and the platform layer calling back into the game layer.
Any ideas on a better way to do this ?
(Btw: if you want to discuss whether options are a good or bad idea please use the game forum thread)
For a first pass, providing a Config() call might be the cleanest solution. Config() would just call Win32Config(), or LinuxConfig() ... etc
The platform layer then pops up a dialog box (using the OS windows/controls) with the options, apply the changes and return back to the game layer. If one of the options was to change the sound device output, then the game layer still gets a buffer to fill, it doesn't need to know that the sound card changed. Similarly, if the resolution is changed, the game layer doesn't know or care, it still just gets a buffer with size = (width x height) to fill.
The complication is if the options screen needs to be rendered using the game font and graphics. The platform code then calls back into the game code to render the options on screen - it starts becoming messy with the game layer calling the platform layer, and the platform layer calling back into the game layer.
Any ideas on a better way to do this ?
I think the best way to go would be to have the platform layer take care of all the options using an OS dialog box.
If they should be handled in-game we don't really need to have the game call back to the platform layer. The platform layer can define all the available options and their descriptions in some kind of struct and pass them to the game. The game then can present a custom GUI for the options, change the values and in the next pass of the main loop the platform layer can apply those changed settings.
This way we nicely can separate this. The game knows how to display and update the option values and the platform code defines what options are available and how to apply them.
If they should be handled in-game we don't really need to have the game call back to the platform layer. The platform layer can define all the available options and their descriptions in some kind of struct and pass them to the game. The game then can present a custom GUI for the options, change the values and in the next pass of the main loop the platform layer can apply those changed settings.
This way we nicely can separate this. The game knows how to display and update the option values and the platform code defines what options are available and how to apply them.
I think there's something to be said for the Unity-style popup which doesn't interrupt the "flow" of the game. It eliminates the need for the platform layer to talk to the game about it at all (other than in normal initialization) and still provides all the options that some users seem very passionate about.
Just make a simple descriptor that the OS layer can use to enumerate its options to the game. That way the game then iterates over the options that each platform specifies and can use all the game services to draw the options window, etc., so it is nicely integrated.
- Casey
- Casey
cmuratori
Just make a simple descriptor that the OS layer can use to enumerate its options to the game. That way the game then iterates over the options that each platform specifies and can use all the game services to draw the options window, etc., so it is nicely integrated.
That is exactly what I meant.