A while ago, I started a series of articles that I never finished, on creating a configuration system for GameMaker games. I posted Part 2 almost 2 years ago, and had intended to follow up in just a couple weeks with Part 3, but it stalled and never came out.
A few readers have asked, so I figure an explanation is owed.
The series I had started on creating a configuration system has been on hold since the second article. As I got into designing the system, I kept running into problems with making my system platform-independent and universal.
I had intended to write a universal configuration management engine for handling things like monitor resolution switching, master volume, music volume, and sound fx volume, and a customizable set of configuration widgets for whatever your game might need (essentially, a set of generic, reusable buttons, sliders, checkboxes, and other UI controls). Ideally, I had hoped to write a set of scripts that would use GML functions to define rooms and objects that would constitute the configuration system. Ultimately, I wanted to create a GML script config_system_create() that would set up the entire system — rooms, objects, and functionality, so that you could simply import a GEX extension, call one function, and have a full-featured system generated at runtime, without having to spend any time designing and implementing all the resources yourself. But in GM:S, YYG obsoleted the functions that allowed me to define objects at runtime, execute strings as GML code, and a number of other functions relating to how Windows handles video and audio.
My goal was to enable a developer to drop in my finished configuration system as a GameMaker extension, and invoke its default implementation with a single function call, and use other function calls in the extension to build custom features, but use most of the features without modification, beyond turning features on or off, and to also have the capability of adding customized settings specific to their game. I wanted to write my system one time, and have it be re-usable so that I could save myself from having to spend a lot of time re-creating the system in each new project.
Most difficult of all, it requires that I design a system that anticipates every need a game developer might possibly have, for any type of game they might dream up. Doing it one time and never having to touch it again would be great, but it’s probably not realistic.
This was an overly-ambitious goal. I’m laughing at myself a bit, now, thinking about it.
Still, there were a lot of achievable ideas that I had for the tutorial, and a demonstration of how to implement them would be a worthwhile exercise.
It won’t be drop-in, single-function system, and it’ll be specific to the Windows build target, but the design should be adaptable to your project with a little work.
I don’t want to make a promise for when I expect to deliver this, but I will complete the series and a reference implementation before I publish the first article.