Game Design

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 … Continue reading Usability, Design, and the three bears

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

By Sebastian Uribe

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 … Continue reading Quick Design Note: do user testing with eyes open and mouth shut

Code refactoring in videogames

By Sebastian Uribe

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 … Continue reading Code refactoring in videogames

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

By Sebastian Uribe

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 … Continue reading Quick Design Note: show, don’t tell… unless you have to.

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

By Sebastian Uribe

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 … Continue reading Quick Design Note: don’t feed unfinished features to casual testers

Quick Design Note: Make state changes explicit

By Sebastian Uribe

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 … Continue reading Quick Design Note: Make state changes explicit

Quick Design Note: Explain only one thing at a time

By Sebastian Uribe

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 … Continue reading Quick Design Note: Explain only one thing at a time

Quick Design Note: The zen tutorial principle

By Sebastian Uribe

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.

Quick Design notes: from the game designer trenches

By Sebastian Uribe

I usually carry two things with me: a tablet with Flip, and a small pocket notebook with a pen. When I ask people to try the game, I sit next to them with the notebook and write quick notes pointing out what have they misunderstood about the game. I decided to share some of this notes in a more generalized (but still short) way, in the hope that they might be interesting for other game designers, and even for users. They will come in short posts, no more than a paragraph each, as “Quick Design Notes“.

Of puzzle game design, Threes and clones

By Sebastian Uribe

Threes vs. the clones Probably most independent game developers have read by now the long post about cloning of their game, from the creators of the Threes. If not, I encourage you to read it now. I personally learnt about 2048 before Threes. Somebody showed it to me, proudly pointing out that it was made by a friend of him. He seemed unaware that his friend had cloned another game, and it would not surprise me if 2048 developer had no ill intentions at all (and the developers of Threes seem to hold nothing against him). The problem with puzzle games … Continue reading Of puzzle game design, Threes and clones