Tailored UI, Tailored Experience, Tailored Everything!
In the previous entry we talked about how we want to make our upcoming game Ronn For Your Life accessible to more types of players by letting them tailor their difficulty setting in several ways. We're all about letting the players customize and tailor as much of the game as possible to their own personal needs. So now that we've allowed that for the difficulty, let's apply the same principle to another important part of the game - the user interface!
Once again, the main philosophy here is that people are different and have not just different needs, but different preferences as well. It's not necessarily a question of accessibility; customization options should go beyond just that, and as much as possible, move into the field of personal preference as well.
A great example of this, especially in regards to a roleplaying game such as Ronn For Your Life, is meta data or meta information. Think of this as the type of 'extra knowledge' about something in the game that you, the player knows, but which your character in the game doesn't know. You know how in some games, you'll see the name of a character floating above its head before you've even talked to that character to actually get its name? That would be an example of meta data. For anyone who's played games like Fable or Mass Effect, you'll know that games like these will offer you certain choices that are pre-labeled as good or evil (or paragon or renegade), so that you as the player knows in advance that a certain choice is considered good or evil. This would be another example of meta data. The list goes on, but you get the picture.
This is an area where two people who both fundamentally like RPGs may be in very different camps; some people prefer to have as much meta data as possible available at all times, while others may prefer to not have any at all for full character immersion. There may be yet a third camp who prefers a certain "golden middleway".
Am I Evil?
As a game with a high focus on moral choices, Ronn For Your Life will have countless of dialogue choices such as referenced above. In cases like this, players will have the option to let the dialogue system show upfront whether a choice will be counted as good or evil - or mask it altogether.
Here's a quick example of the difference in action - in one screenshot, the meta data option for dialogue option alignment is on, and in the other, the option is off.
Oh, and as always in this pre-alpha stage of the game and its blogposts - laughable but temporary programmer art for demonstration purposes only™ incoming.
Dialogue option alignment meta data: Off
Dialogue option alignment meta data: On
Meta Data And Beyond
Another example of how this can be used for showing or hiding meta data is information about NPCs and enemies. I mentioned the example of the typical 'floating name' above someone's head. This is something you can tweak; you can choose to never show anyone's name as meta data, always show someone's name as meta data, or you can choose for the game to only show someone's name as meta data when you're within a certain range of them (a range which you can set yourself).
But information about an enemy's health is an even better example of just how far we want to go with this philosophy; something as simple as showing or hiding information about an enemy's health already gives you at least 5 different options. As with NPC and enemy names, you can choose to never under any circumstances see how much health an enemy has. On the other hand, you can choose to always see every enemy's health. You can also choose to display health for only the enemies who are within a certain custom distance of you. Another option is to only show the health of an enemy whenever it changes - say, when an enemy takes damage, it will display its healthbar for a time - and once again, for how long is yet another parameter you can set. Finally, you can choose to combine the two latter, showing the healthbar of an enemy only if it is within your set range and its health recently changed.
I don't plan on stopping here; I'm considering including options for setting the size of the healthbar (scaling it up and down), or even just displaying it as numbers instead of a bar.
Here's an example (again, placeholder visuals - for demonstration purposes)
In this example, the player has set the game to only show an enemy's healthbar when the enemy's health actually changes, and then after a few seconds with no change, it will fade away. This timer can be customized as well. In this example, the name is set to always be shown (so my audience can at least read that it's supposed to be a zombie), but once again, this can be configured - names and healthbars for NPCs/enemies are completely separate with their own separate settings. You could even make a configuration where name and healthbar both shows up within a certain range, but where the name will always show up ever so slightly before the healthbar (and you can also change the speed with which they will fade in/out of existence) if you so desire. There are so many options.
But really this goes beyond "just" meta data - this, in principle, applies to just about every little UI snippet in the game. Another good example is your own HUD, which has similar settings; you can choose whether to always show HUD elements (health, mana, etc.), never show HUD elements, or only show them on and for a time after something changes.
Everything right now is just tied to simple settings in an external file (your saved preferences), and later I will be adding a graphical interface for you to set everything up the way you want it. But there are actually more external settings than I plan to add a graphical interface for! For example, the fact that the enemy's name and health is red in the example above is also based on an externally stored setting. Now, I don't plan to add graphical settings for changing those kinds of things, but for enthusiasts and modders, it will be very simple to change these small datapoints in the file - so you could have your very own pink healthbars if you wanted to...
One Last Example
As a final example, let's look at something as typical as control prompts. These are your standard "Press X To Interact" kind of prompts that typically appear when close to an object you can interact with in a game, whether it's a door, a switch, an NPC or something else. In Ronn For Your Life you can actually tweak something as simple as this a great deal. Since the PC version of the game allows you to set a primary keyboard control and a secondary keyboard control for all actions, plus the ability to set your own gamepad controls, it becomes a question of which exact button these prompts should display. The answer? Totally up to you!
In total, you end up with 6 different options for what those kinds of prompts should display;
- Nothing (not recommended, but who are we to judge?)
- Primary keyboard function only
- Primary + secondary keyboard functions
- Primary keyboard + gamepad functions
- Primary keyboard + secondary keyboard + gamepad functions
- Gamepad function only
To be honest, I was somewhat triggered to do this when I recently played a fairly new AAA title where these kinds of prompts did not even reflect your own customized controls. Not only does this show your custom mappings, but this level of control actually allows you to tweak these prompts to anywhere from nothing at all to every possible control mapping available across several input methods.
In addition, you can also change the style of the prompts; you can choose between a graphical style where the key / button you've mapped will show as an image of that key / button (so, instead of "Press X To Interact" it would be "Press <SHOW IMAGE OF X BUTTON> To Interact"), or if you have some sort of aversion to those types of graphical display styles, you can opt to have prompts show as pure old school text.
Here's a quick example of the 6 different prompt settings (all in the graphical display style):
Obviously the formatting of the prompts needs some work, but essentially this is how you will be able to alter these prompts. All 6 examples above are in the graphical icon style, but you could set it to display simple text strings like "Space", "F" and "X" instead (which would obviously also be localized for non-english versions) - essentially making for 11 different possible versions of a simple "interact with NPC" prompt.
All the control keys and buttons that can possibly be displayed are reflective of the ones in your own customized control setup, and you decide whether to see none, one, several or all of them. In addition, should you have setup your game prompts to include gamepad buttons (or only show gamepad buttons) but your gamepad has been disconnected since last playsession, then the game will default to just showing your preferred prompt style but without the gamepad button included (until it is once again connected).
The examples mentioned in this blog are just the very basics - they're meant to illustrate one of the very cores of our fundamental design philosophies behind the entire game - flexibility, accessibility and customization. If something makes sense to give you as an option, a setting, a preference - we will. Some things in the game will be the way they are because they're designed to be that way - but there will be a vast amount of preferences for you to play with that will hopefully enable you to tailor as many parts of the game as closely to your personal needs and desires as possible. These are just the tip of the iceberg.
If you are designing a game yourself, I challenge you to ask yourself a few questions about things like these:
Can I make it an option? If so, is there a reason why I shouldn't? Would it harm the game, or would it help it?
Typically, making something an option isn't really that much extra work, since you're basically just reading / writing to some sort of external storage instead of hardcoding the data. There is a bit of extra work in providing the graphical interface to change these settings for the user, as well as some more QA for testing all the different combinations of options - but in return, your player gets a game that is most likely a lot more flexible to suit that player's needs and preferences. Unless the extra work is too significant or it just really doesn't make sense as an option (or downright hurts the game or its design vision), then you should really ask yourself why something isn't an option. I do. All the time.