• # Designing a "Playable" UI That Secretly Teaches How to Play

UX for Games

## How to play

Just in case you haven't played the game, here's a short introduction to the gameplay:
1. Get the goat and keep it on your head to score points
2. First player to reach 3k points wins the game
3. If you don't have the goat, steal it
4. You steal the goat by dashing onto the carrier (this is important)
That's essentially the goal of Toto Temple. There's more depth to it, but it's stuff you're supposed to figure out by yourself. Here's a relevant (and really important) example:
1. Dashing is not strictly reserved for stealing the goat
2. It makes you move quickly in a straight line, so use it to move around faster as well (don't walk)
Notice how Yellow got to the goat before Green did?
That's it, you know how to play Toto Temple. We've added a lot more content since then, but the basics are still the same.

## First UI concept (jam version)

Before we talk about the UI system currently in place in Toto Temple Deluxe, let's see where we started. The first (and only) menu we had in the jam version was this:
"A" to join, "B" to... un-join?
Super straightforward. You press "A" to join and when there's at least 2 players, the "press start" option pops up and you can start the game. Note that there's no "color selection" option (say what!?). You simply press "A" and figure out which color you got depending on which controller you picked up. The lack of color selection might seem weird at first, but it didn't feel that important during the jam, especially since there's no behavior/skills differences between each color (more on that below).

## Live events: Looking for trouble

Back in November 2013, the original Toto Temple was being featured at Gamercamp, a small and charming event taking place in Toronto.
Between the jam version and the version we presented at Gamercamp, we've made a bunch of tweaks in the gameplay: smoother controls, balancing the points system, etc. One thing we didn't do, though, was making changes to the UI system. Why would we change something that isn't broken, right? During a live event, the ideal scenario is usually to let players figure out the game / controls by themselves. It's a lot less work for you and it's a good sign that your game (or UI) is well-designed. What we noticed back then is that once in the game, most players had no clue how to navigate using the "dash" mechanic. Even after "reading" the short tutorial for controls and listening to our oral explanations, players kept moving around by running and jumping.
See? No dash. Oh wait! Green player is on to something...
Over and over, you could hear us say: "To dash, you need to press the X button AND the direction in which you'd like to dash. So to dash up, you push the left joystick up and you press X at the same time. You can dash in all 4 directions, even left up right down consecutively if you want". What we think was happening is that players associated the dash mechanic with "stealing the goat", and only with that, since it's the main objective. They would wait to come aligned with the goat carrier before dashing. Like we mentioned above, dashing can be used to move around faster, something most players didn't think of. It's technically not a bad thing, since you're supposed to learn that kind of stuff by yourself as you play, but we still felt like we could have done a better job at introducing the concept to new players.

## Back to the drawing board

At that point, we noticed that dashing in multiple directions was definitely something most players had trouble with. Dashing left and right was kind of okay, though. Since your Toto was automatically facing left or right, you ended up dashing in one direction or the other by simply pressing X (no direction). Dashing down is not often required at first (you start using it more as you start dashing to move around a lot). The real problem was dashing up. You had to dash up way more often than down, since gravity was pulling you down and you often wanted to go up in the level.
Dashing is noticeably faster than running and jumping
Eventually, players would understand that dashing is always useful, but it was hard to enjoy the game and be competitive without knowing that important detail. We had to do something about it.

## Character selection: First lesson

A short time after gathering all that new information, we got invited to demo Toto Temple at a small gaming event in Montreal called The Prince of Arcade. It was a good occasion to try and improve the game's teaching methods and see it in action. First idea we had to solve the dashing problem was to bring the platforming and the physics into the menu and literally ask players to dash up to join the game, instead of simply pressing "A". It wouldn't teach them how to play, but they would at least be aware of the key combination.
Dash up to join, dash down to quit
After watching players play the game all evening, we noticed that most of them would take less time to start dashing in different directions. The new "playable" menu definitely had an impact. We didn't know back then, but that would end up being our very first step towards a completely physical and playable UI.

## Deluxe makeover

Shortly after testing out the playable menu, we got in touch with the great folks at Ouya and managed to get a partnership deal for a bigger and better version of the game. We had plans for more levels, new modes, power-ups, and of course, a completely new UI system. Since we were going for a physical and playable approach for the new UI, we decided to literally go "outdoors" with temple-like boxes, etc.
No more abstract boxes! Smell that fresh air?
The first version based on the new look and feel was pretty much the same thing, but inside some nice looking pillars in an outdoor scenery (see above), you know, instead of boring and flat boxes. Since we didn't have that big and colorful picture of the player in the background anymore, we added colored statues on top to really add contrast regarding who is in and who is not. It creates a visual mass in the top part of the screen that is easier for the eye to scan, compared to just a button being on / off. While not the main purpose, it also creates a small visual celebration. As a newcomer, it makes you feel a bit like the game is happy that you joined!

## Weird behaviors

Now for some strange reasons we still don't understand, we've seen a lot of player dash up to join the game, then immediately dash down to leave the game. Then dash up, then dash down. Again and again and again. They would do that until someone pressed start, and if they were lucky, they would happen to be "in" as the game progressed to the next step. Most of the time, they ended up being "out" and we had to go back, wait for them to join, then proceed again. The worst cases were the ones when another player would mindlessly dash down and leave as we were waiting for the remaining player to join. What the heck? What we think is that players aren't used to have an impact on the UI by playing around with their character. They simply don't realize their actions are changing the game's settings.
We also made the background light up to make it more obvious that you're in.
To fix the problem, we simply removed the "dash down to quit" button (see above). To leave the game, you had to dash in the "join" button again (a toggle system, basically). It helped reduce the amount of weird "switch flicking", but once in a while we can still see some players join and leave over and over using only the top button. It didn't completely fix the problem, but at least they seem to understand what to do after their first try.

## Level selection: More teaching

The next menu screen we ended up needing was a "level selection" screen. We were aiming at 5 or 6 new Deluxe levels (or temples), so we needed a way to choose one from the bunch. Still with that same functional unity in mind, we came up with a first iteration using left and right buttons to choose your level (see below):
Still missing some assets, but you get the point.
While sketching the new screen, we thought: "Hey, what a good opportunity to teach even more stuff to players!". With this one, we were trying to teach you 2 things related to movement:
1. You can dash up, but you can also dash left and right
2. Those buttons are too high? Well guess what, you can jump and dash consecutively!
To help understand the directives a bit more, we even added subtle decoration details to guide your eye from the starting position of your character, all the way up to the buttons on each sides. Here's what worked:
• We've seen a lot of players simply select the default level by pressing start right away on their first playtest. We concluded that it was okay since you usually don't know any of the levels on your first try (the first one is as good as any other). They saw that there were other levels available, so they understood that it was possible to manually choose.
• Most players recognized the buttons and the fact they need to bump into them, just like they did in the previous screen.
Here's what didn't work:
• Players understood the "jump and dash" combination, but since they were new at the game, they were having a hard time hitting the button multiple times in a row.
• The problem was coming from the fact that your eye wanted to look at the level thumbnails so you can pick the one you liked, but you felt like you also needed to look at your character to make sure you were aiming correctly at the button. It was weird and unpleasant.
• Some of them also took a bit too much time to figure out that the X button could be use for something else than joining the game (they probably didn't notice the dash animation while they were looking at their controller to spot the X button).
"Oh ok, wait. What are the buttons? How do I..." - Yellow player
Here's what we did (see above):
• To make it more comfortable to select a level, we added little step so you could mindlessly dash left or right and focus on the level thumbnail. It wasn't teaching you to jump and dash consecutively anymore, but it was at least teaching you to jump (necessary to reach the button), a thing that the previous screen didn't require.
• We added level icons with a single thumbnail so it could be easier to see the whole picture (how many levels total).
• We moved the "dash left / right" instruction from the middle top to both sides. They're also closer to each button so they were easier to notice and we made them blue like the actual X button (in this case it's U for the Ouya equivalent).
• It wasn't much of a problem, but we made the whole box smaller in width so it'd take less time to dash from one button to the other.

## Mode selection: Final exam

The last menu to come in was the "mode selection" screen. Even if it was very simple at its core, it also happened to be the trickiest to implement. To quickly give you an idea of the UI flow before going further, here's the order in which you'd go through the 3 menu screens:
1. Character selection comes first since we'll need to know how many players will join for the next step.
2. Mode selection is second, so you can quickly define the teams if that was your intention from the start. We want to let you set what you have in mind as soon as possible, so you don't have to wait and "remember it".
3. Level selection comes last. If we ever decide to create "mode-specific" levels, the filter will already be defined.
An early sketch the whole UI flow
For the "mode selection", we basically needed a simple way of selecting a mode from a list, just like with the "level selection". An obvious choice was to duplicate the screen we made for the "level selection", but it didn't feel right (hard to quickly differentiate one screen from the other, etc). We also wanted to cover as much of the different controls as possible, so the other obvious choice was to ask players to dash up and down (instead of left and right) to go through the list. With a button at the top and one at the bottom, the screen was pretty much done. Then the hard part came in and we had to design the team selection box (below).
Position-based team selection ftw!
As you probably remember, one of the trickiest detail we had to deal with was that most of the controller buttons are already used to move your character around. Setting up teams without the use of a joystick-controlled cursor or the "A" button to confirm anything forced us to go in a different way. With only a small physical box at disposition, we had to design a system that was easy to understand, fast to setup and that didn't use any controller buttons. As you can see above, we decided to use a new variable to set things up: your position in the box. Here are the components and their uses:
1. Avatar blocks are sitting on your head when you're not in a team, and they automatically snap in place when you enter a "team zone"
2. A physical "VS" block to literally separate the two teams, which also acts as a "dead zone" to make the transition from team to team clearer
3. A "dash down" button that makes the list loop around
4. "Press start" indicator popping up when the teams are set
We've never really encountered major problems with this screen so far, so we've kept like that since.

## Quick teaching roundup

So far, here's what players should have in mind (subconsciously at least) before they even enter the game:
1. They should know that the X button can be used simultaneously with the joystick
2. They should know that A is for jump
3. They should know that X works in multiple directions, including up, left and right
They might not clearly remember everything they did in the menus, but their subconscious picture of the controls should look like this (below). Its a good thing, since it's exactly all the buttons they'll need to play the game!

## Post launch: Player requests

Toto Temple Deluxe has been published and you've already seen the most of the UI that went into the game. Following the release, we did like we always do: we kept interacting with fans in forums, comments, blogs, etc. The 2 most recurring comments (or requests) we received were:
1. I don't have friends to play with, can you add bots?
2. I want to be able to choose my color at the start of the game! I know it doesn't change anything gameplay-wise, but [insert color] is my favorite color and I'd like to play with it.
Both of these are super legit requests, and after some long discussions to evaluate the costs of implementing those things, we decided to go for it even if it was expensive, long and complicated. Not very bright, I know. But we love you.

## Update: Destroying a screen for 1 feature

Both "bots selection" and "color selection" are closely related to "character selection", which we quickly identified as a problem, UI-wise at least. Our current menu for "character selection" (if we can even call it a "selection") wasn't really designed to give players a choice of color or character. The pillar boxes are pretty small, and handling a bots selection system later on would also add up to the clogginess. We tried to think of different solutions to keep our current UI for that screen, but none of them was efficient, clean or simply felt right. We then decided to start over from scratch!
Characters automatically jump when you push the joystick to wake them up. That way, you can spot which one you are right when you're expecting visual feedback!
Here's what changed:
• We kept the big statues. It's not a change, but we loved them too much to get rid of them.
• We now have a big public box, instead of beautiful, individual pillars (still sad about those pillars).
• We added uncolored Totos with player numbers over their heads so you can keep track of who you are.
• You can now choose the color you want by dashing in the corresponding button.
• You can switch from your current color to an unselected one directly.
• You can't steal someone's color, and vice versa.
• We do not have bots yet, but this design should let you decided if, for instance, green player will join in as a bot, etc. We'll simply cut the "join" button into two buttons: "Join" and "add as bot". At least that's the plan.

## Conclusion: Benefits and difficulties

Making a fully playable UI was definitely a good experiment for us. Even if it wasn't completely necessary, it helped convey the complexity of the controls to new players. We could have relied on traditional, text-based tutorials, but most player would have just ignored them to then have a hard time playing the game like it's supposed to be played. Making a playable UI system is great if your game needs it, obviously, but it also comes with its share of difficulties: Benefits:
• You barely notice that you're learning
• Way less boring than text and steps by steps / holding hand
• Eases the players into your game mechanics
Difficulties:
• Hard to strike a good balance between efficiency and clarity
• It's easy to start adding physical buttons everywhere, but that will get really confusing really fast
Games with really simple mechanics or barely no menus may not really benefit from this kind of system. On the other hand, a playable UI could help preserve immersion and overall unity even if you don't need it as a teaching tool. Look at games like Antichamber by Alexander Bruce and Braid by Jonathan Blow. They both have playable menus, even if they don't necessarily teach the player how to play the game in a literal way. Instead, they help preserve immersion, so that you're not cut out of the game's universe each time you need to use a menu.
In Antichamber, you just need to look around and point at stuff to interact with the menu In Braid, you physically go through a door to pick a world / level
Obviously, we're not implying that our method is the best / only way to do a playable menu. It's just a long walkthrough (maybe too long, sorry) of our development process. If you think it could have been done better based on our game's needs, or if you have any comments, feedback or questions, we would love to hear them! Note: This article was originally published on the Juicy Beast blog, and is reproduced here with kind permission from the author Yowan. Thanks Yowan!

Report Article

## User Feedback

Very cool insight in the UI design process, and your game look s absolutely gorgeous!

##### Share on other sites

Very cool insight in the UI design process, and your game look s absolutely gorgeous!

Thank you very much :)

##### Share on other sites

"First idea we had to solve the dashing problem was to bring the platforming and the physics into the menu and literally ask players to dash up to join the game, instead of simply pressing “A”. It wouldn’t teach them how to play, but they would at least be aware of the key combination."

This is very insightful.  And it has me thinking about how I design my games...

##### Share on other sites

If I'm not mistaken, this is why Megaman became so popular. Back then, nobody wanted to read manuals or guides for button combinations, so Megaman gave you limited options. For example, when you first start out in Megaman X, if you try to go left, you get nowhere. However, if you go right, you can continue. It goes on, such as falling into a pit in the same leveling and realizing you could wall jump to get out.

##### Share on other sites

If I'm not mistaken, this is why Megaman became so popular. [...] when you first start out in Megaman X, if you try to go left, you get nowhere. However, if you go right, you can continue.

I thought that was true for almost every sidescrolling game of that era? When Metroid was introduced, Miyamoto intentionally made it so you couldn't progress to the right until after you went to the left and got the powerup (Morph Ball?), specifically to teach that you can go to the left and right, since no (or very few) games did that at that point in time. (supposedly. I can't find a source where Miyamoto himself says this was intentional, only third-party sources claiming he said it

Take for example the Super Mario Bros games (the first (1985) of which was released two years before the first Mega Man (1987), let alone before Mega Man X (1993)). You go right. And right. And right. Until you win.

Infact, in the only Megaman Game I've played - Dr Wily's Revenge (1991), in some levels you go both right and left, as the level zig-zags around. (Great game! )

I just pulled up the maps of the Mega Man X levels, and indeed you are correct that they all seem to go straight right (and up/down). The older Mega Man games did so as well - was this an intentional design decision, or an accident because of a lack of precedent otherwise? Regardless, was it really the "cause" of Mega Man's success?

You said it is to simplify the controls (because nobody wanted to read the manuals for the controls), but you can still go left and right within each room, it's just the levels that lead you to the right, so while it simplifies level design, it wouldn't simplify the controls any.

Back then, nobody wanted to read manuals or guides for button combinations

Everyone I talk to says they enjoyed reading manuals back in the day. I'm not sure how much of this is just nostalgia, but I'm a youngin' who grew up in the 1990s, and starting playing games in the latter half of 1990s, and I distinctly remember reading the little plastic manuals that came with N64 games, and also PC games, and distinctly remember others in my family doing the same thing. Not because we couldn't jump in and play the game, but because we also enjoyed reading the manuals. My little sister, 16, still does this even now with her 3DS and Wii games.

##### Share on other sites
An excellent and enjoyable article. Your game looks great too! :)

##### Share on other sites

An interesting article and an impressive idea about a playable menu, but I couldn't help wandering to myself, they spent a lot of time on a menu, wouldn't some of that time have been better spent on adding more gameplay and content to the game?! Generally speaking, if a game is engaging and has interesting gameplay, characters, music, overall ambiance, etc., players will go through the effort of reading a tutorial or asking somebody or even looking up online how to play it. Look at some of the more popular arcade games from the 80's and 90's, for example. There was very minimal information about the controls and how to play the game, but players learned if they liked the game enough. In games like Mortal Kombat and Street Fighter, for example, there wasn't really much of anything in the game about what buttons did what. In MK, which is notorious for its fatalities, there was nothing in the game about the button inputs to perform one, but players figured it out and shared the knowledge amongst each other.

I am not criticizing, per se, more like wandering about the merits of adding playable menus and how much playable to make them.  It seems to me something like in Antichamber is more optimal. You still get the playable menu feel, but really the "play" part is very minimal and it only serves to teach  the player the controls of the game.

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 0
• 0
• 4
• 3

• 15
• 21
• 21
• 11
• 9
• ### Similar Content

• Concept for Delayed Shots in a Fast Paced Shooter

The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
• By Pepsidog
I'm wanting to create a hybrid game between turn based and action.  I'm looking to create a system where the player has a list of attack or move options on their turn, but I want to add a skill minigame in order to make the game more engaging for non-strategists.  I figured some sort of minigame or something.  Any ideas are welcome.  Thanks in advance!
• By EchoCell
Hello folks! I’m looking for advice on which engine I should go with for a 2D game I want to make. The goal is to make a side-scrolling beat’em up/2D fighting game hybrid where the main levels are in beat’em up mode, but the boss battles are in 2D fighter mode. The combat controls (combos, special moves, etc) would be the same in both modes, and the game would include a tournament mode that is entirely in 2D fighter mode.
I have minimal game developing experience, and am essentially a noob. I am mostly familiar with RPGMaker, but have also experimented lightly with Unity. I have zero programming knowledge, and thus am partial to engines more accessible to complete beginners.
What engine(s) would be best suited to this kind of game? I am interested in both M.U.G.E.N and OpenBOR, but I don’t think either would allow the kind of genre-crossing I want to accomplish without significant programming skills that I don’t have.
Also - and I realize I’m thinking too far ahead - I would like to be able to release this game via HTML5 and just host it online somewhere if possible. Otherwise I am okay with it being PC only.
Thank you for your time and input!
-Autumn
• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?
×