Video Games are Real

Tag: usability

  • Platformer Video Games with a Keyboard? How Different are Gamepads and Keyboards, Really?

    Platformer Video Games with a Keyboard? How Different are Gamepads and Keyboards, Really?

    Subscribe on YouTube

    During a recent usability review playtest of an in-progress video game, I noticed something strange about the way the main menu registered gamepad inputs. This led me down an especially nerdy path to better understand what was going on.

    I recently conducted a usability and gameplay analysis of an in-development game called Dungeon in a Bottle. It’s a 2D precision platformer and is absolutely delightful.

    One focus of my analysis was the menu system. The developer, Very Handsome Games, called specific attention to the menu system as something they’d like me to take a look at. So I did. I look at things that people want me to look at. It’s who I am. It’s also why driving down a billboard-filled highway can be dangerous for me and any of my passengers. Billboards are meant for looking at.

    When you’ve been playing video games with an eye toward usability for as long as I have, you start to intuit things on a gut level without having to rely on a checklist of usability heuristics. In the case of the Dungeon in a Bottle menu system, something felt a bit off. But I couldn’t articulate it, so I kept on with my play session. Later in the game, I noticed that a particular mechanic, called a Moth Jump, depended on button presses during specific intervals of time that, for some reason, perhaps my own ineptitude, I couldn’t quite land consistently.

    The issue I found with the menu system is that when changing from one menu item to another using a gamepad it was possible, and actually quite common, to cycle so quickly through the menu options that landing on a specific option was difficult.

    So, I had a theory worth testing: Are gamepad button presses less instant than keyboard button presses? Do players tend to hold gamepad button presses longer than keyboard button presses for the same objective?

    Well, first I wanted to better understand Dungeon in a Bottle’s own playtesting measures. I reached out to the developer and asked them to validate a hunch that the game’s testing so far had been focused on keyboard input. They validated this hunch. Nice.

    Validation feels nice.

    But a hunch alone wasn’t enough. I needed data. So, I mocked up a menu system to test this theory. I used a menu system both because that’s the situation that initially churned my gut, but also because it’s a testing environment that eliminates skill-based variables. I needed to remove as many variables as I could because I don’t have access to a fancy lab with lots of eager test participants. No, I have access to a smelly room and just three less than eager family members.

    So, I have the test environment, I have the testers, and with a quick script to count frames during button presses, I have my data stream. Each session went like this: I had the player sit in front of the screen. I then instructed them to pick up the controller. I told them that the d-pad should be used for this test. I wasn’t testing how intuitive the interface was, afterall. I was testing for frame counts. So I felt comfortable directly telling the player how to navigate the menu. I then gave them a simple set of instructions to follow. For example, go down to the exit option. Now go up to the color option, now go back down to the exit option, and on and on until the player had pressed an average of 28 buttons. I then had them do the same for the keyboard.

    Afterwards, I had some data. Average frame counts are higher for gamepad button presses:

    And this average is consistent even at the individual participant level:

    Sure, this data isn’t enough to be statically valuable, but it’s definitely enough to add some credence to this idea that gamepad directional buttons tended to be pressed for longer durations than keyboard arrow keys.

    Practically speaking, how is this useful? First, and perhaps most importantly, it means Bob’s thoughts about the “instant and satisfying” nature of keyboard button presses is valid from slightly more than just a subjective perspective. Second, it means that any coding in the game that relies on specific button states may need to take this input-based player behavior into account. Now, I have not talked with Very Handsome Games specifically about how they coded the game, so from here on out I’m only relying hypotheticals that could be applied to any game.

    First, know that there are three states that a button can be in. In Gamemaker Studio 2, the engine that I’m most familiar with, these button states are:

    • check_pressed, which checks to see if the button has been pressed
    • check, which checks to see if the button is currently down
    • check_released, which checks to see if the button has been released
    GameMaker Studio button states: _check_pressed, _check, _check_released

    If cycling through the menu is based on the check function, then knowing that gamepad users hold buttons longer means that those players may inadvertently cycle past the desired option. Perhaps replacing this with the check_pressed function would be better, as this would allow the menu selection to advance only once per button press. However, for games with very long menus, this would force the player to press a button many times instead of just holding the button. Think the way Contra on the NES is way less problematic when using a turbo button. In this scenario, the check_pressed function is probably the right way to go, but some additional logic might be called for Perhaps the developer would want to incorporate a timer to allow the selection to advance only after a set number of frames has passed. According to the lowest frame count capture for a gamepad in my study, that number would be five frames. The developer could also have these rules be separate for gamepad and keyboard users if they really wanted to cater to specific gaming habits.

    Overall, I’m really happy with this finding. Again, it’s not statically valuable, but it is incredibly interesting, to me at least, as it further helps me understand the differences between gamepad and keyboard inputs. Too often I think of the two interfaces as entirely preference based. I don’t think of them often enough as different in terms of functionality, at least not with games that are limited to very simple mechanics and few button requirements.

    Credits and Mentioned:

    WULFF DEN / I’m done using D-Pads

    My games usability review presentations

    Music credits

    • Bossa Antigua by Kevin MacLeod, Link: https://incompetech.filmmusic.io/song/3454-bossa-antigua, License: http://creativecommons.org/licenses/by/4.0/
    • Pump by Kevin MacLeod, Link: https://incompetech.filmmusic.io/song/4252-pump, License: http://creativecommons.org/licenses/by/4.0/
  • Is Usability the Reason You Quit That Video Game You Thought You Liked?

    Is Usability the Reason You Quit That Video Game You Thought You Liked?

    Subscribe on YouTube

    Have you ever played a game and, you wouldn’t say you’re having fun, maybe fun ish? The combat is adequately combatty. The environment is suitability environment-like. Even the story is appropriately narrative-ish. But despite all of the obvious important elements firing on just enough cylinders, something doesn’t feel right. Something isn’t quite working for you. Maybe, the game simply has poor usability.

    What is Games Usability?

    So, let’s begin with explaining what games usability is. It’s not the same as accessibility. Accessibility deals with making games playable by people with all types of impairments and disabilities, both temporary and permanent. Usability deals with making sure players understand how to play the game. Broadly speaking, accessibility is about the ability to play the game. Usability is about the ability to understand the game.

    Games usability seeks to answer three questions about a game as the player plays it:

    1. Does the player know what they have to do?
    2. Is the player able to do what they need to?
    3. Does the player know how to achieve their goals?

    A usability reviewer might investigate these questions using usability heuristics, which are rules of thumb or guiding principles. For example, a game can benefit from using real-world equivalents to indicate in-game functionality. If I, as a player, see that a gun has a long barrel and big scope, I can understand that as probably a sniper weapon and therefore its functionality can be inferred. It’s a gun that’s slow to load but good at shooting long distances. Interestingly, conventions also fold into this concept. Even if a person has never seen a real sniper weapon, if they’ve played other video games with sniper weapons, they will still understand the functionality.

    Probably long, slow shooty. Probably not short, fast shooty.

    So, deviation from a heuristic could be enough to introduce a bit of friction between the player and the design intent of the game, that being how the game wants the player to feel and act. If the apparent sniper weapon turned out to be an automatic gun that fired mortar rounds, that would be weird. [1]Maybe awesome. But, still, weird. The player, though, might not immediately recognize this as inherently strange. Perhaps the game is set on an alien planet full of strange objects. But imagine this dissonance compounded over many hours of play with many different objects. The player may feel that something is off with the game.

    Steve Krug, in his book “Don’t Make Me Think,” introduced this idea of the reservoir of goodwill. This is the idea that users, or players in our case, will come to a game wanting to have a good experience. But each time the player experiences an issue that doesn’t make the experience great, the player’s reservoir of goodwill depletes until, if it reaches empty, the player quits the game. It’s more nuanced than that, of course, the player can build up a strong fault tolerance if motivated to continue playing through outside pressure, social pressure, emotional pressure, inertia, or simple potential (that eventual good feeling of seeing the platinum trophy pop), but the idea of usability as viewed through the reservoir of goodwill concept, can help explain the otherwise unexplainable reasons we have good enough experiences with a game instead of great experiences with a game.

    The Reservoir of Goodwill by Steve Krug

    But video games can, and I’d argue often should, stretch, or even destroy, the heuristics as long as game usability remains. Let’s talk about this using a very common design convention and heuristic pairing. The health status icon. Usability dictates that the player character’s health, in most games, should be shown to the player any time the player needs to make decisions based on the health, which is, in many games, always. The amount of health you have remaining determines pretty much every action in a lot of games. For me, someone who’s paranoid about sudden enemy attacks at every turn, if the amount of health I have remaining is ever less than 100%, my next action is to find more health.

    Therefore , a conventional way to display character health to the player is by using a series of heart icons or a health bar, sometimes red in color, and often a corner of the screen. This placement, shape, and color has become so ubiquitous that it’s jarring when health status meters, especially in action adventure and platformer games, don’t follow at least two of these conventions.

    Yeah, that feels right.

    Sometimes designers will play with conventions. World to the West, a fantastic top-down Zelda-like game, honors the color and placement conventions of the health status meter, but instead of using a common shape like a heart, circle, or a bar, World to the West uses a series of diamond shapes organized in sets of three. I admit, when I first started playing, I was a bit confused. I knew the element reflected character health, but I wasn’t sure why they were laid out like they are. Why in angled stacks of three? Ultimately, this layout had no gameplay purpose, but my confusion is worth noting as it shows just how powerful conventions can be.

    Nope. That’s weird.

    Then, take a game like Vanquish, a third person action shooter with…a very, very atypical health status meter. The health system uses a recognizable green-yellow-red color indicator to connote full health, medium health, and low health, respectively, which is good, as the color scheme is well-known by way of most real-life traffic light systems. However, the placement of the health status meter is confusing. In fact it’s so confusing, many players have had to ask online how to even find where in the game the player character’s health status can be seen. In Vanquish, the player has to look at the player character’s suit, either at the player character’s helmet, back, or calf. All three placements are usability nightmares because they are not always in the same place, are often obscured, are hard to intentionally make visible, and making them visible compromises other systems in the game–as in, moving the camera around to view the health may mean the player isn’t able to see enemies.

    This health system status element is something that, if I were part of the development team, I would have argued for a playtest or usability review as soon as this idea made its way to the corkboard.

    If I have to point it out with an arrow, it is bad.

    The further a designer strays from conventions, the more they have to justify those though gameplay. Conventions are great ways to get players to focus on what a designer wants a player to focus on. People don’t have infinite ram to store every pixel and every system function in their brain. Conventions are very useful shortcuts to allow game designers to experiment and create where experimentation and creation can thrive. And sometimes, a game like Vanquish tries something new and it’s not until years later that I look back and realize, oh yeah, the health system sucked and that definitely, though subconsciously, influenced my decision to thrown that game in the trashcan.

    Credits and Mentioned:

    Music credits

    • Bossa Antigua by Kevin MacLeod, Link: https://incompetech.filmmusic.io/song/3454-bossa-antigua, License: http://creativecommons.org/licenses/by/4.0/
    • Pump by Kevin MacLeod, Link: https://incompetech.filmmusic.io/song/4252-pump, License: http://creativecommons.org/licenses/by/4.0/

    Footnotes

    Footnotes
    ↑1 Maybe awesome. But, still, weird.