Keep Your Players Flowing
What’s the Flow?
The concept of Flow (Csikszentmihalyi, 1990) defines the mental state in which a person performing an activity is fully immersed in a feeling of focus, full involvement, and enjoyment in the process of the activity. It is a state of complete absorption with the activity at hand. It is a state in which people are so involved in an activity that nothing else seems to matter. For purposes of this article, we’ll simplify it asserting that Flow is the Optimum Challenge.
Why is the Flow Important for Us?
Because when we enter the Flow, we feel intrinsically motivated and happier, which is related to our perception of fun. As a side note, you’ll always want your players to be as much intrinsically motivated as possible, and since it is hard enough to foster intrinsic motivation, this is another reason why the state of Flow is an important game design element.
What Are the Requirements of the Flow?
1. Clear Goals and Progress
The player must know what is she trying to achieve and how to track her progress.
2. Clear and Immediate Feedback
This helps the player react to changing demands and allows her to adjust her performance to maintain the flow state.
3. Optimum Level of Difficulty
The player must have a good balance between the perceived challenges of the task at hand and her own perceived skills. The player must have confidence that she is capable to do the task at hand. We must ensure that we are communicating to the players correctly the difficulty of the task, and that they are able to evaluate accurately their level of skill. If they fail to understand one of these two things, the Flow state will be much more difficult to achieve, and it will be lost easier.
How Do I Get Players in the Flow?
Players enter and stay in the Flow when the game offers them the Optimum Challenge, this is to say, a balance between the difficulty of the task against their skill. The comparison of difficulty-skill will determine how the game experience will be (see the image below). Through his research, Csikszentmihalyi identified eight different experiences. I encourage you to think of examples of each one as your read them:
- Low challenges versus high skills can serve as relaxing experiences.
- Low challenges versus moderate skills lead to boredom.
- Low challenges versus low skills give place to apathy.
- Moderate challenges versus low skills foster worry and concern.
- Moderate challenges versus high skills create experiences of control.
- High challenges versus low skills make the players feel anxious.
- High challenges versus moderate skills create activation
- High challenges versus high skills enable the players to enter in the Flow.
Remember that “High challenges versus high skills” doesn’t mean that the task is very difficult per se. If the player doesn’t know anything about your game, learning even the basics can be a challenging task, no matter if these basics are really simple. On a side note, this is out of the scope of this article, but I figured it would be worth to mention that there are more elements you should consider when creating your game experience, namely that it should be able to be perceived as challenging for inexperienced players while not resulting too easy for the experienced players. If the new players find it too difficult or if the experienced players feel you are insulting their skills, there is a good chance that they will abandon your game. It doesn’t mean that you should satisfy them all; rather, there are techniques that allow for experienced users to squeeze more performance out of a system when interacting with it, which new users don’t even are aware of.
How Do I Keep Players in the Flow?
As players repeat the activities of the game, they improve their skill. In order to keep them in a state of flow, the difficulty of the activities must rise to match their skill. If the difficulty of the activities doesn’t change, eventually the player will move from a “High challenges versus high skills” experience (Flow) to a “Low Difficulty with High Skill” experience (boredom). If the difficulty rises too fast, the player will end up in a “High challenges versus low skills” experience (anxiety).
Conclusions
We want our players to enter the state of Flow. We will get them there by presenting them with challenges that match perfectly their skills. As players play our game, their skill improves, so we will need to rise the challenge to keep them engaged.
Bibliography
Books
Enrique G. Fernández, Mº Dolores Martín, Javier Domínguez, “Psychological Processes” Donald A. Norman, “The Psychology of Everyday Things”
Websites
George Fan, “How I Go my Mom to play Plants vs. Zombies” Wikipedia, “Flow (Psychology)” Wikipedia “Mihaly Csikszentmihalyi”
The First Time You Write for Games
In my last three games, I have worked with writers who had never worked in games. I observed that they went through the same phases before feeling comfortable with their tasks, so I thought it could be helpful if I wrote them down.
Please, keep in mind that these are my observations and, hence, are completely subjective.
I hope you find it useful!
First Step: Overcoming Your Fear
Writers believe we need to make the game before, so they can write a story over it, but it’s hard to do it that way. Gameplay and Story are developed systemically, one affecting the other as both are fleshed out, but I have found out that is often easier to start by writing a story and then gamificating it. Let’s put it this way: they just need to write a story, and we will find a way to represent that story with the tools we have (our gameplay mechanics, our 3D assets and our imagination).
Writing a story and gamificating it afterwards doesn’t mean its gameplay is going to be weaker. In fact, it’s going to be better.
If they think they have to make something different to write a script for a game, they get blocked, because they are waiting for an input that will never come.
The solution is pretty simple: they only need to write a normal script.
Second Step: Self-Gamifying Your Story
Now that they have understood that we only need a normal, regular script, they start writing it and they discover it is taking them much longer than they thought. In fact, it is taking them much longer than a regular script. Needless to say, they get worried, and consequently blocked.
Their problem in this stage is that, unconsciously, they are trying to think from a gameplay perspective as they write. They try to handcraft their story to include gameplay situations or to describe these situations, and this slows them down, because it is something really difficult and they don’t have the necessary information to make it: What are the game mechanics? How long would it take to play through this gameplay situation I just imagined? How would be the experience from a narrative experience? Will the players grasp what I’m trying to convey here if I lean too much on gameplay?
There is an interesting fact here: If they have worked in games before, they will probably end up doing exactly this, and it will be just fine. It’s only the first times that your work might be more difficult, but as you learn the tools of the trade (what kind of things you can ask from a 3D artist, or what scenes will require expensive and specific cinematics) you will become more and more comfortable pre-gamifying your stories.
Third Step: Realization
- They just write a simple, regular script.
- The developers elaborate a proposal of how can that story be represented through the means available (gameplay, assets, time, effort, etc).
- They meet and talk about it. They reach a consensus.
- They all go back to their places and start working in what will be probably an awesome game.
NOTE: Again, this last step is not a requirement; if the writer has some gaming experience he/she could gamify part of the story as described in the second step, speeding up the process.
Idiot or cancel?
Today I had to explain to a group of non-technical people why is it important to run at least some user tests on your product. This is the anecdote I used, and since they liked it and it seemed to convince them, I thought I would share it here, just in case someone needs to explain the same thing.
This is a real story, and happened quite a long ago when they were inventing the dialog box (that is, the “Yes/No” dialog we often see on any computer) at Palo Alto Research Center.
When the software required confirmation from the user, it displayed a small window called a “dialog box”, that contained a question, and presented two buttons, for positive or negative confirmation. The buttons were labeled “Do It” and “Cancel”. The designers observed that a few users seemed to stumble at the point that the dialog was displayed, clicking “Cancel” when they should have clicked “Do It”, but it wasn’t clear what they were having trouble with.
Finally, the team noticed one user that was particularly flummoxed by the dialog box, who even seemed to be getting a bit angry. The moderator interrupted the test and asked him what the problem was. He replied, “I’m not a dolt, why is the software calling me a dolt?”It turns out he wasn’t noticing the space between the ‘o’ and the ‘I’ in ‘Do It’; in the sans-serif system font we were using, a capital ‘I’ looked very much like a lower case ‘l’, so he was reading ‘Do It’ as ‘Dolt’ and was therefore kind of offended.
After a bit of consideration, we switched the positive confirmation button label to ‘OK’ (which was initially avoided, because we thought it was too colloquial), and from that point on people seemed to have fewer problems.
For non-english speakers (like myself), “dolt” means “idiot”, so the users were confronted with choosing between “Idiot” or “Cancel”. No wonder why they were annoyed!
Here you have the source, if you want to know more.
Understanding Information Architecture
I stumbled upon this presentation today and I loved it. I don’t really think it would be enough explanation just by itself for someone that is not already somewhat into this matter, but I believe that it’s a great starting point.
In case you never heard of IA before, it guides your criteria when you analyze, organize and label information in your game. It defines how content is structured, what components are needed in each screen and which routes exist to that content. It cares about that info being understood, it tries to homogenize cognitive load all across the system and ensures that everything is findable, too. In short, if you want to design games you should be proficient Information Architect.
Maybe some other time we’ll have some time to write about IA. In the meantime, if you have five minutes, I’d recommend you to enjoy this:
http://prezi.com/aafmvya6bk7t/understanding-information-architecture/
Isilion out
Research before walking into the unknown
– I said I don’t want to hear about it!
– Listen… no one is going to take your creativity from you. They simply will teach you tools and techniques that will enable you to make the most of it. They will show you which problems others found before you – people who, in addition, have devoted a lifetime to that matter – and how to tackle them so, instead of starting from scratch, you can climb the mountain of their experience and create from there to the stars.
– Not in a thousand years! Music comes from my heart and I will not subjugate her to someone’s wishes!
(Based in a real conversation)
Ludosofía 
You must be logged in to post a comment.