Usability, Design, and the three bears

Yesterday I showed Flip to three developers. The Big Developer was annoyed by the flashing sign that said “Too many moves”. He likes to tinker with things, try out possibilities, and the fact that the game told him that he was already beyond the move count felt frustrating to him. The Medium developer mostly ignored the sign, because he is used to playing games that tell you when you are not going to reach your objective. He played and solved some levels, and others he just skipped. The Small developer was not even aware that a sign was flashing on the screen, so he did not realize that he was not solving the puzzles when he used too many moves. He did not even read the message telling him that he could do it in less moves.

This is just a sample of how diverse people are: even among those who might be seen as such a niche group (game developers) there can be a huge variation in behavior. And I’ve already noticed that variation in almost every aspect of the game. Some people love the controls. Some hate it. Some like level progression, others feel constrained by it.
Can I cater to all of them? Of course not. And with a limited budget, I cannot fund a serious research, find my target group, do proper testing, etc. What I do is to go with a tablet or two, game loaded, everywhere. Whenever I can, I ask people to play. And after that, I create something that is stable, coherent and that, when you follow its rules, works. There are still a couple things players can think, that worry me and are very difficult to handle.

“Is this possible or am I doing something wrong?” / “Why is the game not allowing me to do this?”

This is very hard. How can a player know that something is possible, when she is doing it in the wrong way? With flip, this happens for example when players place the fingers between pieces instead of on top. Also, when people want to rotate something from outside to inside. This has been mostly solved by the tutorial, which shows people what to do and asks them to repeat it.

“I had not seen that!”

Similar to the one above, a player might not realize what is happening. He could be missing content, or just the fact that he is not progressing (like Small developer above). I used to have a move counter shaped as several bars. Dark means a move is still left, light means move done. e.g., two darks: a level with 2 min. moves and no move done yet. one light three dark: a level with 4 moves and 1 done already. But as the first level had only two moves, some people interpreted the two dark bars as a pause symbol, and ignored them altogether. The only way to find this problems is by looking at people play, letting them do something, and later ask them if they saw some detail. You can be quite surprised about what people perceive.

“This game annoys me!”

There is a subset of the people I’ve tested with, I’ll say between 10 and 20%, that just want to try things but don’t like the game nagging them for going over the minimum amount of moves. Flip does not discourage experimentation, but it also does not reward it properly. You get no points for solving something in more than the minimum. It is probably something I will have to change, implementing some “3 stars” system or similar. On the other hand, not every game is for everyone, and finding the right players is important.

Flip Released!

Yesterday Flip was released on Google Play ( and submitted to Amazon (approved, pending publishing). I am also awaiting pre-approval from Windows Phone marketplace, and working on the iOS version, which should be finished and tested in no more than a week.

It’s been not so long since I started it, just over three months. Till now I did not work a lot on creating awareness, so for the following weeks I’ll focus on creating awareness and generating downloads, while working slightly on the idea for my new game.


Quick Design Note: do user testing with eyes open and mouth shut

You are testing your game with someone. You see her not understanding what to do, having a hard time realizing that some feature is there, or just struggling to click on some object, and you feel bad. You feel like she is suffering because of you, too shy to say “I don’t understand this!” because you are there, and you want to ease her suffering. Don’t explain, wait. Unless what they are struggling with is not what you want to test, keep your mouth shut. Just tell them something: like “I will explain later, I promise, but now I want to see how you understand this. If you don’t, it is my fault, not yours“. Keep your eyes open, write down what you see they do, what they don’t understand, but try to resist the urge to talk until they finished their play session. If you start explaining you might later forget what was the thing that was not easy to understand, and you will never improve the usability or design.

BTW, new Flip gameplay video!

I completely forgot to post this.

A new gameplay video (4 minutes) for all level types in Flip. It also showcases the new (and final) art style, about which I’ll write at some point in the future.


Code refactoring in videogames

I’m less than two weeks from releasing Flip, and the main feature remaining to finish and test is in-app purchase. I have no certainty the game will make any money, or if I will touch again any line of code after release. And I am now refactoring the Dialog system. Why?, would a lot of people ask, and it is a very valid question… But to understand why, first some discussion on refactoring.

What is actually to refactor?

By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.

—Joshua Kerievsky, Refactoring to Patterns
[quote taken from wikipedia]


Typical examples, usually supported by IDEs, are extracting repeated parts of code from different places, to create a function that can be reused. Or changing the parameters of a function so it can be a little more generic and also reused better. But those are code-level examples of refactoring, and in a general way, refactoring means changing your code to be better. And “better” should be understood as better to “handle the problem it is intended to handle”. So it might happen that the code you wrote at the beginning was just some prototype code and you need to make it more understandable or usable, or that your understanding of the problem at hand has changed, and so the code is no longer good at handling your new conception of the problem.

So of course It makes sense to change bad, rushed code and turn it into something readable, and that should be done as quick as you can, before you forget what that constant meant, or why you do things in a particular order. But after a while, your code stabilizes becomes robust, and it is not so important to touch it again. So how about when your problem changes?

Reinventing the camera, or parts of it

I remember discussions more than 10 years ago with fellow developers about how “Making videogames is like filming a movie but having to develop a new camera for every time”. Nowadays that is not so true, as component based game frameworks (like Unity) allow you not only to reuse the engine, but also parts of functionality, as long as you developed them carefully.

So the “base technology” part of the problem to solve, is not part of what you need to refactor. In a game, the other big part is the game logic itself. And usually, you just develop the game once, on a strict budget and with little time, you release it, maybe you patch it, and never really touch the code again. So… why refactor the dialog system?

Refactoring is also learning

Because, stretching the term a bit, sometimes what you refactor is your understanding of a particular problem. Sometimes you have to redo things to understand on an abstract level what a good solution would be. Because the only thing that you will carry for certain from a project to another, is your understanding on how to solve problems. In my case, the dialog system is a mess. I have several dialogs across the application, each made in a custom way, and I’m having to add a lot of ad-hoc logic to deal with the purchases (showing a dialog, waiting, closing it when another messages comes, etc.). And even though I might never touch this again, I need to learn how to solve this problem with my current tools, so in the next game I will be more efficient. Because if I don’t learn now, anyway I will have to deal with this problem in the future. And doing it the right way from now onward, is much more efficient than doing it wrong forever.


Quick Design Note: show, don’t tell… unless you have to.

As a player, would you prefer to be told “to revert your previous move, click on the UNDO button located on the bottom left corner“, or for such a button to be clearly shown to you, and when clicking it (after being subtly induced to do that), seeing the result? From my experience, most players don’t like reading and will ignore a text even as short as that. And when playing, they expect an active experience (interacting) rather than a passive one (reading). The trick is to induce them to do something without telling them explicitly . But sometimes some things are difficult or time consuming to show, and the most efficient way to explain them is to clearly state them. As an example, when you want to rotate more than one piece in Flip, you grab the innermost and move it outwards. There are several reasons (outside of the scope of this post) why you cannot pick the outermost and move it inwards. Unfortunately, I have still not found a better way to transmit that idea than to state it explicitly: “rotate from inside to outside”.

Quick Design Note: don’t feed unfinished features to casual testers

If you are hiring people to professionally test your game, then you can just tell them to ignore placeholder content, bugs, etc. They will (should!) professionally ignore them and report you on the things that you actually ask them. But when testing with “real” people, users who might casually try your game for just a few minutes, having features not in working condition is not a good idea. It will attract a lot of their attention, and it will be hard for them to ignore them, even if you ask them to. They will assume your game is broken, which will predispose them to evaluate the game in a negative light, and their willingness to test will most probably fall to the floor. If you feel the game is not in condition for testing with casual users, then don’t do it. Remove the feature from the build, and leave only finished stuff for them to try.

Quick Design Note: Make state changes explicit

Sometimes you try to switch the state of the game quickly to let the player “flow” fast and easily through it (people playing mobile games sometimes don’t have a lot of patience). Imagine in a puzzle game, when the player finishes a level, you drop her immediately in the next one. But what happens when you do it really fast, and the levels are similar? Many players will not understand that a state change has occurred, and will think that you just reversed their last move, or that they are still in the same. Stating that a puzzle was finished does not make it explicit that you are now showing something different. Additional cues are sometimes required. Sound cues alone are not good enough, as people might play with sound off or on noisy places. Text, fade in/outs, etc. or other visual cues seem to work best.

Quick Design Note: Explain only one thing at a time

In an early tutorial to Flip I made a terrible mistake. In one step, I showed the player a move, and asked him to repeat it. In the next step, I showed another move, because I wanted to show that it was also possible, but asked the player to click the undo button (which appeared at the same time of the move). Of course, every single person I gave it for testing, tried to do the move they saw on screen.
Do not try to explain two things at once, specially when players are just learning: they will probably ignore one of the two.

Quick Design Note: The zen tutorial principle

The best tutorial is the one that is not a tutorial.

Introduce the concepts to the player in a way that does not feel like he is doing an actual tutorial. Lots of players prefer to skip explanations, thinking they are smart enough to understand your game. They might be, but there are always details they will not catch and later feel frustrated. With a free game (with IAP or other free to paid model) that means they will throw it away.