Going with the flOw
It’s a snowy-stay-inside day (for us anyway), so you might as well play a game. (Unless, of course, you’re in my Software Design class, in which case you ought to be in the lab working like dogs! :->) Consequently, you might want to check out flOw, a free Flash game written as part of Jenova Chen’s MFA thesis.
OK, the idea of a game as part of someone’s MFA thesis means that this thing is probably either going to suck huge or be pretty cool, and while I haven’t played a lot, I’m leaning towards the pretty cool end of the spectrum. The game is apparently based on Mihaly Csikszentmihalyi’s concept of flow. Without having read Chen’s thesis I don’t know exactly what parts of Csikszentmihalyi’s theories are central to the design of the flOw (the game), but it appears from Chen’s mission statement that the key concept is the arguably obvious, but sadly oft-ignored, relationship between challenge and ability:
When the challenge is greater than our abilities, we become anxious and potentially dead. When the challenge is significantly less than that of which we are worthy, we become bored, and potentially dead.
When the balance between challenge and ability is right, we can enter a state of “flow”, where “we feel that we control the activity, our worries and concerns disappear, our subjective experience of time is altered”.
Maintaining the dynamic balance between abilities and challenge is key to the fun experience in work. That is, keeping it dynamic. Making it possible for anyone to find exactly the right amount of challenge needed to engage exactly those abilities needed to access Flow.Which means that when work is fun we have created complex, but negotiable challenges, challenges that allow the individual to engage or disengage, to work harder or work safer.
And while Chen is using game design to explore these ideas, they apply to lots of activities, including writing, programming, driving (and probably flying), playing an instrument, and juggling. Returning to my aforementioned Software Design students, for example, one of the biggest challenges in teaching that class (and many other courses) is successfully negotiating the transition from small, solo activities to large, challenging, group activities. If the projects remain too small and simple, then at least some students won’t be challenged enough to stay focussed and interested, and while they are unlikely to die in the literal (or game) sense, their grades can certainly tank if they drift too much. On the other hand, if we hand them a massive task and just walk away, many students will be overwhelmed by the challenge, have no idea how to even begin the work, and die.
According to Csikszentmihalyi, there are at least four pre-requisites for obtaining a sense of flow:
- We are up to the activity.
- We are able to concentrate on the activity.
- The activity has clear goals.
- The activity has direct feedback.
In Software Design the first tends to come down to (a) solid prep out of Data Structures, (b) some motivational speaking (they’re often nervous coming into Software Design, and you have to reassure them), and (c) being around a lot to help them over bumps so they don’t start to lose faith and drift on you. The second is (I think) mostly up to them, although trying to stay out of their way probably helps (e.g., don’t lecture endlessly on things that appear irrelevant and give them plenty of time to work in the lab). Clear goals should be a part of any educational activity, but a good project (like a good writing assignment) ought to have a lot of possible (good) outcomes, so the goals have to about properties of the outcome such as clarity, relevance, and focus. In the case of Software Design, we use a number of metrics gathering tools (JUnit tests, Clover test coverage, PMD) and communication and tracking tools (CVS/Subversion, TWiki, a home-grown tracking tool) to help clarify those goals and and provide regular, consistent feedback.
The other major challenge is to help break down a task that can seem overwhelming at first. If all they see is this huge mountain to climb in nothing but swim trunks and battered sneakers, they not surprisingly tend to lock up. If you can help them develop and focus on manageable intermediate goals, and also help them realize they have the skills and tools they need to reach those goals, then they have a much great chance of succeeding.
And all of this is not to say that somehow I/we have got this all worked out perfectly in our classes, but we try. My students are currently in the tail end of a large two week project that they’ve found pretty difficult (because it is). They’ve made lots of progress, but they’re still struggling with a variety of things, and I arguably haven’t given them optimal support. We’ve been wrestling with a number of our tools, so the “regular feedback” part hasn’t worked as well as I’d like, and it seemed to take them forever to “get” the whole idea of the Observer Pattern as a way to manage the interactions between their GUI views and their backend. We’ll cope, though.
Coming back to the game, the intent in flOw is to provide the player with the ability to easily adjust the difficulty of the game to suit their level of skill and understanding. When you drop into the thing, it’s not at all obvious (at least for me) what you’re supposed to do, so part of the challenge is simply figuring out what’s going on. It’s pretty clear that you’re supposed to guide your little swimming thing around, and it seems likely (giving the scoop-y mouth thing) that you’re supposed to “eat” other little simming things. It took me a little longer, however, to get a sense for the business of diving deeper and moving back up to shallower water, and how one controls that. One of the cool things about the game, though, is that the different depths feel much more continuous and less like the discrete levels common in other games, and the ability to move back and forth between them fairly easily does make you feel much more in control. I also like the fact that if you have a run in with a nasty beasty that wants to eat you, you don’t just die and start over, you are automatically bumped back up to a shallower area. Thus when you’re new and still trying to figure out what’s what, if you go too deep too fast, you don’t just die and become all frustruted, but instead are nudged back into safer waters.
‘Nuff said - go try it for yourself. I found watching this demo clip very helpful in giving me a sense of what gameplay could look like.
Credit (or blame!) for pointing me at this goes to Nate Fortuna, so take it up with him if you don’t get your work done.
No tag for this post.
February 26th, 2007 at 00:00
Some of these ideas are pretty similar to Ralph Koster’s ideas in his book, The Theory of Fun. He discusses how games are all a sort of pattern matching. If a game is too hard, too complex, we give up and are frustrated. Likewise for an lab assignment in software design. Or if a game is too simple, it’s boring and nothing is gained. Game players seek the best way to play or beat the game, always.
In the context of games, this pretty clearly relates to the “Anxiety” and “Boredom” sections of the flow diagram presented here: http://www.jenovachen.com/flowingames/missionstatement.htm
In the context of coursework, you’re probably more concerned with not overwhelming students while keeping as many as possible from being bored- that is then penalty for too difficult assignments is greater than too easy ones- at least where the student’s grade is concerned (and probably most students).
The more I think about it, the more I suspect there isn’t much beyond a mix of challenge and abilities to create flow. I’m not quite sure how the ideas of clear goals work in… The game Flow seems to have no goals and few instructions. However, there is a natural drive to explore. Players quickly notice they can increase the size of their creature, which seems to be an acceptable and interesting goal to play towards. There’s also a drive to explore the next level.
What about for coursework? Without a clear definition of the assignment, the aspect of a challenge is simply missing. Other games, particularly A Tale in the Desert and Eve Online do tend to suffer from the lack of goals. There’s so much that could be done, but the band of flow seems very narrow.
Anyway, thinking back to my coursework, I’ve had enjoyable projects of the appropriate challenge level, and boring projects that were a drag, but eventually completed. Portions of an assignment can be frustratingly hard, but it’s hard to say how often these challenges defeat students. Usually they are addressed in the next lecture or perhaps dropped.
1) We are up to the activity.
2) We are able to concentrate on the activity.
3) The activity has clear goals.
4) The activity has direct feedback.
When I look at these prerequisites from the standpoint of classes like Software Design I think each one can stand in the way of students being in the flow.
1) Simply being up for an activity is having a reason to do the assignment, understanding it and its purpose.
2) Concentrating on an activity means having the personal motivation to sit down and do it. I think this is mostly a personal thing although that doesn’t mean that the professor does not have an important role to play here. I could expound on this, but it is beyond the scope of my response :P
3) Clear goals (long term and short term). This is why we have stories.
4) Direct feedback is about seeing results and seeing how what was learned in a lecture applies to programming. I write unit tests for their direct feedback.
As I look at learning the observer pattern, I suspect it’s fairly abstract for students. They might not see the immediate need for the added complexity, but give the professor the benefit of the doubt (unless the professor’s major is in marine biology). But given some example code and the goal to add listeners to a large and incomplete project could be understandably difficult. They might not be up to something of this size, and furthermore, the’re not a lot of direct feedback, since they can’t see it in action. .
A small mini-lab, or even assignment is probably the best way to demonstrate this. Even a small lab has a sense of completion. It’s done and over with in a reasonable amount of time. The goals for a small assignment are more clear and seem more attainable.