Embrace the complexity
Around 1:00 AM, on a night just before Christmas in 2009, I sat at my desk and wept tears of frustrated exhaustion into my laptop. Having enthusiastically pitched an interactive piece for 12 performers and escalator for a festival in January, I’d just started work on the implementation and it wasn’t going well. My first attempt at running the Computer Vision example from the Open Frameworks website had resulted in 600 compile errors. I had no idea how to solve them, I’d been at it for hours, and I was yet to write a single line of code.
The problem was that I was still quite the newbie. As such I was lacking a bundle of skills which are peripheral but nonetheless essential to the writing of code. To solve my compile errors I needed to know how to use command line tools, check out repositories, fix makefiles, and configure my IDE. At that moment, I had neither the time nor the will to study any of it. Instead I resorted to what I call the workaround strategy; I trawled internet forums until I eventually found a post linking to a version that would compile on my machine. This got the job done, but in a much more labour intensive and stressful way. It left my project fragile and susceptible to breaking changes.
More importantly I learnt little from the experience and so I set myself up for successive stressful replays on subsequent projects. Indeed I continued resorting to the workaround strategy for several more projects before finally learning the lesson and investing sufficient time in developing peripheral skills. Years later, as I found myself guiding undergraduate students in creating their own OpenFrameworks projects, I observed them repeating the same mistake. So why do newbies avoid learning peripheral skills ? I can think of a number of reasons:
Firstly, there are few practice opportunities for developing peripheral skills outside of a project scenario. As my anecdote demonstrates, the pressures of project work are incompatible with developing them. Once in the middle of project development, working on these skills appears tangential to the project goals, and so students will resort to workarounds.
Secondly, unlike languages, peripheral skills form a nebulous cluster of interconnected knowledge. This makes them difficult to study. For example, a student might start studying Git only to discover that they first need to understand package management systems to install it, which in turn requires an understanding of command line tools and so on. Without prior knowledge of how deep the rabbit hole goes, this quickly becomes overwhelming for the student.
Finally, in their attempts to shield users from these complexities via project builders and addons, creative computing frameworks actively discourage going anywhere near that rabbit hole. When the user is a newbie, the user-framework relationship can quickly develop into one of restrictive dependency where tortuous circumnavigations are performed in order to avoid what might be a simple inclusion of an external library. Belying this final issue is perhaps a more fundamental dialectic between accessibility and independence in computing pedagogy. Enclosed, pedagogically-conceived frameworks can only take students so far in their journeys to become coders; to achieve independence they must learn to embrace complexity and thrive in it.
So, in 2015, in an attempt to address all of this I created my first gamified learning project, Adventures in Wonderland. It’s primary aim is to teach a set of peripheral skills necessary for creating C++ projects in a way that would convey playful curiosity. There’s a mantra that recurs throughout — “Embrace the complexity”. The idea is to furnish students with a positive mindset not only for learning these tools but also for the other interconnected knowledge clusters that they’re bound to encounter as developers in the future. I hoped my students would become enthusiastic about going down rabbit holes.
The adventure takes the form of a five week course. Students begin by downloading a file called README and following the instructions. They use the command line to travel down a metaphorical rabbit hole through a series of nested folders to find a character called Rabbit who guides them on their journey. As the adventure progresses, the clues and tasks shift from navigating around directories and reading text files to stitching together photo fragments of campus locations and interacting with hidden servers on local wifi networks. It all culminates in a secret escape room where students unlock a trap door and finally meet the Mad Hatter.
The scoring mechanic has its own pedagogical motivation somewhat analogous to Anne Fine’s flour babies. I noticed that students were rather careless with their files, and often mislaid source code right before submission. So the adventure keeps track of students’ progress via a text file which they have to keep for the duration. This operated a little like a stamp book. As they completed a stage a new hashed code was added to the student’s score file recording their progress. If they lost the file — they frequently did — then they simply had to go back to the start of the adventure and build up their scorefile again.
The project proved popular with my students and ran for several years. As my first foray into game-based learning, it had its flaws; The trail mechanic didn’t allow players to skip difficult tasks, and the one shot nature of the tasks offered limited practice opportunities for students. However, the relationships between theme, mechanics and values in Adventures in Wonderland had an integral quality that was incredibly powerful. I certainly enchanted a few students down that rabbit hole.
Try it out yourself. Play the game here