November Design Challenge – Winner Announced!

We are so excited about our monthly design challenges, because they give us all a chance to practice what we think is the core design principle in creating accessible games: consideration. This month, we asked participants to tell us how they would adjust the design of a popular game that’s been getting a lot of play around our houses lately, “Among Us.” We are excited to share with you the design solutions our participants came up with for changing “Among Us” into a game that could be played with a single button.

We were so impressed with the solutions that were offered, and we believe that we can all learn from the creative ideas that were shared with us. So, here’s the design suggestions that surfaced in the contest, and our Playability Initiative designers’ response.

Navigation and Player Movement

Blake Schreurs was the winner of this month’s challenge, and he began with ship navigation:

“For this game, navigating the space is a big deal, but navigating 2D spaces is something of a challenge with one button. In this case, I’ve implemented a predictive path algorithm: The user is focused on where they want to go, and the game will take them there. Each click will select a room after the room they’re going to.

Of course, the risk of getting stabbed is very real in this game, so back-tracking (if you see something that scares you) happens immediately.

The implementation code could use some polish, but this is to demonstrate a design, not be game-ready.

Oh, the color choice for the paths is on purpose: should still be distinct for those who are colorblind. Also, rooms with “chores” are a different shape (diamond) than intermediary nodes (hex). I was going to put in colored arrows “You’re going here”, but I found the “target room bubble” was extremely effective.

You’ll also notice that the game will select the next room for you when you reach a node. This is on purpose, as staying moving = staying alive, so I thought that was better than sitting still by default. You can sit still by going back to a previous node.”

 

Ryan Green had this to say about the navigation design:

“What I appreciate most about Blake’s design is that the immediacy of system response to player input is at the forefront of his thinking right from the get go. This is a game that requires users to be able to react. As Blake says, “moving = staying alive.”  His implementation of movement is very clever. Instead of selection occurring when the player is stopped at a point-of-interest, he uses the time between nodes to allow the player to anticipate their next move.  Allowing players to make decisions while they are moving frees the player from the tedium of movement, and gives them permission to think strategically.”

Player Customization

Next, Blake tackled cosmetic customizations in the game. Showing how much accessible game design requires a comprehensive approach, it’s not all about the mechanics.

“Do not underestimate the value of pets and clothes… These help give players individuality, or let them all participate in group activities (like all wearing party hats).

It is, in fact, so important, that cosmetics are one of the primary ways the game makes money… Personality matters, and we can’t overlook this. 

However, picking something from a large selection with one button is kinda awful. Given 1 second cycle time for choosing objects, and a reaction time of 0.5 seconds (and please forgive any math errors, it’s late)… With a fully linear format, choosing between 64 items can take anywhere between 0.5 (first item) and 63.5 seconds, with a mean time of 32.5 seconds. ICK! Oh, and if you MISS your item? Double ick.

With an X/Y input grid you have anywhere between 0.5 and 14.5 seconds, with a mean time of 8 seconds. Missing your selection depends entirely on implementation here, but may make you feel a little dead inside.

Hahaha! But wait! There is another way! A binary search!

With a binary hierarchical selection, a selection time is anywhere between 3 and 6.5 seconds, with a mean that’s really hard to calculate, but in the neighborhood of 5-ish seconds. Missing your selection means you go back up one step in the hierarchy.

It also doesn’t FEEL as long, because you’re invested in making intermediate steps along the way. You’re not waiting 6 seconds before you can act, there’s always an action just a moment away.

This demo uses very basic colors to show the concept. In a real-world design, we’ll want smooth animation, and to de-emphasize all non-selected items by greying them out, so the user can stay focused on the item they want.”

Ryan Green says, 

“Again, in menu selection situations, Blake rightly points out that cycling many options can be tedious, error prone, and take a very long time. The binary tree search is great because it narrows the decision space for the player down to two options. One additional accommodation I would have liked to have seen mapped out more clearly is either a “back,” “undo,” or a “confirm” option.  I like that Blake’s method reduces the cycling time for correcting mistakes, it is less clear to me how players would tell the system they do not want the current selection.”

J’accuse!!!

Here are Blake’s thoughts on Accusing others and voting. 

“There are up to 8 players. I’ve given each a distinct shape, and a color using the Paul Tol palette (again, to support folks with color vision challenges). If I actually had the skills/resources to do actual character design, these would be the silhouettes / primary colors of those designs… As is, you’re stuck with ugly block art.

Choosing the player you want to defend/accuse is another hierarchical selection. I refined it some, so it doesn’t have quite that “rough concept” feel. Once you select a character to defend/blame, a linear slider is used to pick how confident you are of their innocence / guilt.

At the discussion round-up, the display would show how each player voted for each other.

The voting would work very similarly: One option for each other player, and a skip button.”

When Ryan Green reviewed the accusations, he said, 

“My only note here is that it seems to me the player would be selecting a player to accuse, so I might reverse the order of the slider to read back → Imposter → Sus → Crew. This would speed up the process of accusing someone by moving the most likely selection to the beginning of the scanning process.”

When Blake looked at the tasks and chores, he elegantly boiled down this aspect of the game as, “things to make you stay in place so someone can stab you.” (And I’m going to use this as justification for why I refuse to do any chores around my house from here on out.)

“In this case, these are essentially mini-games. They need to be short, since the player won’t be able to exit the mini-game prematurely (since the mini-game will essentially be taking over the input).

There are a broad variety that you can do. Flappy-bird. Geometry dash. Stop the spinner on a desired color. Hit trajectory. Alto-like games. Frogger-oids.

It’s pretty much the same with ship events: Core meltdown? Have a few folks navigate to the engine room and inject coolant.

The main exception would be the Emergency Meeting button, which would cycle between pressing or not pressing. Pressing it calls a meeting, not pressing returns the player to ship navigation.

This is pretty high level. For a full game design you’d want to go into more detail. That is to say: There is more design work that can be done here, but none of it is terribly novel.”

Ryan Green seemed particularly impressed with mini-game design, saying, 

“Blake’s suggestions for mini-games are perfect. The more simple controls in these examples don’t diminish the challenge of the minigame, but they do make them equally accessible to all player input types.”

Killing and reporting bodies.

“Again, this is all VERY rough, and would need to be cleaned up considerably for a proof-of-concept.

This is a snippet of showing reporting a body. I’ve moved the map to a mini-map, and have created a lighting environment more like Among Us. The player icon has changed to that of the last example. The opaque shadowing makes it feel more like you “stumble across” the body, as opposed to trying to navigate to it to report it.

Ultimately, it adds another timing element so that players can’t rest too easy between navigation nodes.

If you’re the imposter, and the other character is alive, then it would be a nearly identical interaction to kill them.”

Overall, Ryan Green was really inspired by this winning design submission, saying,  

“Blake really went above and beyond with his entry this month. I was thoroughly impressed! I have fallen into the design trap of emphasizing the less important elements of gameplay and losing sight of the point of the game. As Hayden likes to say “what does the player want to do, and what is preventing them from doing it?” Blake’s solution keeps that question in mind and maintains what makes Among Us fundamentally fun to play.”

When Playability Initiative Designer, Hayden Scott-Baron, helped us select Blake as the winner, he had this to say about Blake’s entry:

“My favourite part of Blake’s design is the consideration of player movement, which can be one of the trickiest things to adapt to single button. Focusing on pathfinding is an excellent approach that greatly limits the number of items being cycled at any one time, and keeps players moving around the ship. It also shows the ways that different maps can be more accommodating to different input methods, with junction and hub layouts vastly altering what it means to head into certain rooms or choose a new location.  It could be interesting to see location goals overlaid with behaviour goals, with the player deciding how much they want to follow other players and perform tasks. The ideas about interface and voting are excellent too, and show how each activity needs unique consideration. Great work!”

Our next one-button design challenge goes live at the end of this week, on Friday December 4th. To participate, make sure you’ve joined our Playability Initiative Facebook group, and then send us your designs in the comments of the challenge post. (Also, we fully recognize that Blake went above and beyond in his response to our challenge and we want to reassure everyone that we will consider entries based on the merit of their ideas and not based on the length of the submission.)