![Flow start up screen](\"https:\/\/i0.wp.com\/UnhinderedByTalent.com\/Phi\/wp-content\/images\/Flowscreencapture.jpg?w=400&ssl=1\")
<\/a><\/p>\nIt’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>, a free Flash game written as part of Jenova Chen’s MFA thesis.<\/p>\n 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<\/a>. 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<\/a> that the key concept is the arguably obvious, but sadly oft-ignored, relationship between challenge and ability:<\/p>\n \nWhen 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.\n<\/p><\/blockquote>\n 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”.<\/p>\n \nMaintaining 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.\n<\/p><\/blockquote>\n 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. <\/p>\n According to Csikszentmihalyi, there are at least four pre-requisites for obtaining a sense of flow:<\/p>\n 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<\/em> 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<\/em> 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<\/a>, Clover test coverage<\/a>, PMD<\/a>) and communication and tracking tools (CVS<\/a>\/Subversion<\/a>, TWiki<\/a>, a home-grown tracking tool) to help clarify those goals and and provide regular, consistent feedback.<\/p>\n 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<\/em> 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<\/em> to “get” the whole idea of the Observer Pattern<\/a> as a way to manage the interactions between their GUI views and their backend. We’ll cope, though.<\/p>\n 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<\/em>, 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.<\/p>\n ‘Nuff said – go try it for yourself. I found watching this demo clip<\/a> very helpful in giving me a sense of what gameplay could look like.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":"\n
![\"Boss](\"https:\/\/i0.wp.com\/www.experimental-gameplay.org\/2006\/flow.jpg?w=840\")
\nThe 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.<\/p>\n