DEVBLOG 8 OR SO: So Many Options

This one’s maybe a little boring if you’re not into gamedev’s seedy underside, and doesn’t necessarily have a lot to do with Echoes. Sorry!

Today we’re talking about how a user customizes his in-game experience. We’re talking about options.

The first question to ask is, “What gameplay parameters should a user be able to change?” and the answer will usually be about preference instead of power. “Screen shake? y/n” is a better option than “Double jump? y/n” in most games, for example. (Writing this makes me sort of want to make a game where the options menu is a core mechanic, but that sounds pretty boring. “Enemies shooting at you? no thx.”)

Most of these options will have more to do with the interface and how the player controls the game than the actual game mechanics. For example, things like volume and keybinds don’t really change the game’s core mechanics, and are things players will frequently want to tweak. Occasionally, you’ll have a control option with multiple ways to execute something (hold-against the wall to wall jump or just be touching it? down-a to fall through a platform, or just tap down?), especially when each way has an advantage (speed or ease of use) over the other.

Having identified that, figure out how to represent it in data. Keybinds are a great example of this in Echoes. Before we added customizable binds, what did what was entirely hardcoded — so the game would interpret BUTTON_A coming from a controller as an “accept” or a “jump” depending on the context, but what it needs to do is interpret $THE_JUMP_BUTTON_WHATEVER_THAT_IS instead, and evaluate what the jump button is when it’s needed. There needs to be something the player can write to to tell the system what his preferences are. (Most of the time, this is as simple as just one variable of an appropriate type that can be interpreted efficiently. Volume as a float, fullscreen? as a boolean, etc.)

Lastly, the player needs a means by which to actually change data. This is where your options menu comes in! Imagine an OptionElement class that has two display fields (optionName and optionValue) where either or both of those can be text or an image, and a way to pass input along. When a player chooses one, copy whatever value is in there to an appropriate temporary variable, and interpret the player’s input to alter the temporary value. (Scroll through resolutions, +/- volume, flip a bool, whatever.) When the player hits accept, copy the temporary value into the “master” value, and inform the necessary game subsystem of the change (for example, if the resolution option is changed, tell your window handle and your directx device — if the music volume is changed, tell your audio handler).

Options! They’re great, and now I don’t have to awkwardly explain “Sorry, sorry, you can’t change the resolution yet” to our awesome twitch streamers. Thanks for reading!