How my online gaming addiction saved my Ph.D.

Or, how I cookie-clicked my way to a doctorate in interaction design.

It’s been 5 years since I finished my Ph.D. on user interfaces for machine learning. To celebrate/commiserate, I’m sharing an unusual (if I may say so myself) grad school war story, the story of how sinking hundreds of hours into pointless online games unexpectedly sped up my ability to do research by a factor of 10, perhaps more.

The idle game renaissance of 2013

The year is 2013. The slow burning Disney super hit Frozen is picking up steam, and soon parents the world over will be terrorised by toddlers in Olaf and Elsa costumes tunelessly belting ‘Let it Go’. Simultaneously, a French programmer known only as Orteil (meaning ‘toe’) releases a game that takes the online gaming world by storm for its absurdity, simplicity and addictiveness.

The game? Cookie Clicker. The objective of the game is simple: get as many cookies as you can. You can click a giant cookie to generate a cookie, but this method doesn’t scale particularly well. Instead, you can spend some of your cookies to hire grandmas to bake cookies for you. Over time, you gain access to cookie farms, factories, and a seemingly endless series of increasingly absurd and productive cookie generation devices.

A lot of ink was spilled at the time on cookie clicker’s addictive nature. Despite its apparent simplicity, there was something incredibly fun and moreish about its core gameplay loop. While it was not the first game in this genre, it is perhaps the most influential. Within weeks, the Internet was awash with hundreds of ‘clicker’ games ranging from simple re-skins of Cookie Clicker to inventive new interpretations of the genre that pushed its boundaries and articulated the core elements that made it fun. The genre eventually came to be known as ‘incremental’ or ‘idle’ games, centred around an active Reddit community, and even inspiring dozens of research papers.

Down the rabbit hole

One of the peculiar and interesting aspects of this game is that it rewards you for not playing it. Often, the next cookie purchase requires several orders of magnitude more cookies than you are currently producing, so you have no option but to leave the game alone, sometimes for days, before your cookie factories churn out enough cookies for you to unlock the next level of progress. This is why it is called an ‘idle’ game.

One of the interesting aspects of this game is that it rewards you for not playing it.

However, the game is clever; it provides multiple potential pathways towards your next goal, and small decisions you make can compound, making the difference between an overnight wait or a wait of several days. Calculating the best way to allocate your limited resources before leaving the game to run overnight becomes a complex mathematical puzzle with many moving parts. Catnip for nerds.

I fell pretty hard for Cookie Clicker. I had it running on my computer 24×7 for months, tending to it every few hours. I visited the Cookie Clicker subreddit everyday, where people would discuss strategy, post tips, and results of experiments. A cottage industry of browser add-ons emerged that allowed you to automate certain aspects of gameplay as well as track cookie production statistics and compute in-game decision formulas. The game was in written in the web programming language JavaScript, and so were these add-ons.

By playing with and tweaking these add-ons I inadvertently learned a lot about how programming for the browser works. I was even able to track down the root cause of an issue where I wasn’t generating cookies as quickly as my calculations anticipated. It turns out that Google Chrome throttles JavaScript timers in background tabs, meaning that in order for my add-on to auto-click as fast as it was supposed to, the tab needed to be visible in the foreground. I plotted a graph of the phenomenon and presented my research to the reddit community, adding to the growing body of knowledge about this game (and my own growing body of knowledge about programming for the browser).

By playing, I inadvertently learned a lot about how programming for the browser works.

My failed attempt at making a game

At some point, several months into my Cookie Clicker journey (and having also become a connoisseur of several other incremental games along the way), I finally started to feel the creative itch. Why couldn’t I make my own incremental game?

Being steeped in academia, and unburdened by the cynicism that comes with experience, I imagined an incremental game where you start off as a lowly graduate student, trying to gain research points by writing papers, and slowly go up the ranks of professorship until you become the head of a department churning out hundreds of high-quality research papers and attracting billions of investment dollars. I started writing a very basic game. I had a rough vision in mind, but I didn’t have all the web programming skills I needed yet. So I learned one step at a time, one concept as a time, until I knew enough to put together a rough prototype.

It looked awful, but it had a few minutes of gameplay and was a good proof-of-concept. I continued working on the game for a few days but, my itch having been scratched, I ran out of steam. I also became aware that some clever scientists at CERN had developed a much better version of the game that I was planning to build. I abandoned my game and didn’t give the episode another thought.

A skill I didn’t know I had

A few months later I found myself in a discussion with my Ph.D. advisor about uncertainty in charts and graphs. We had come up with the idea of using error bars as a control mechanism — if you want to compute a data point with more certainty, could you drag the error bars around to indicate the level of uncertainty you were comfortable with? We designed an experiment to test this idea, now all we needed was an interactive prototype for people to use.

It’s worth mentioning that until this point my primary programming experience was in Java, Python, and R. I used Python and R for data manipulation and analysis, and Java for prototyping user interfaces (UIs). The problem was that I wasn’t very good at it. Although my own skills were partly to blame, from my perspective it was also the case that Java’s antiquated UI programming libraries were terrible for rapid UI prototyping. As a consequence, in the entire first year of my Ph.D. I produced only one, rather simple prototype.

I was dreading having to build this error bars prototype in Java when it suddenly hit me: why not build this as a web app? It seems completely obvious in hindsight, but it was a revelation to me at the time. For various reasons, the ecosystem of web development is much better geared towards UI prototyping. The months spent futzing about in Cookie Clicker add-ons, reading JavaScript documentation, and building my own terrible game had, unbeknownst to me, laid the foundations for all the skills I needed to build, tweak, debug, and most importantly, learn what I needed to learn to complete this prototype.

Previously, this might have taken me weeks. With JavaScript, I built the prototype in hours. Using web technology had another advantage: it was easy to deploy the study as a website and therefore get many more participants than I would have normally gotten in a lab-based experiment. The study was completed within a month and was published at a good conference.

My success with this study encouraged and empowered me. It became painfully clear how much of a creativity and productivity bottleneck my UI programming skills had been. The transition to web development resulted in a 10x increase in my prototyping speed. Over the next two years of my PhD I built several prototypes of varying complexity. And while other challenges inevitably arose, the building of UI prototypes remained a smooth and enjoyable experience throughout. I cannot conceive of how I would have produced nearly as much if I had stuck with Java.

Cookie Clicker saved my Ph.D.

The transition to web development resulted in a 10x increase in my prototyping speed. Cookie Clicker saved my Ph.D.

The moral of the story

There are several ways we could moralise this story.

We could view my investigations of Cookie Clicker’s mechanisms as ‘basic research’, i.e., research without an immediate application in mind. There is evidence that basic research in the sciences leads to productivity increases in manufacturing. Eloquent arguments have been made that forgoing basic research is costly, that “when academic research starts demonstrating industry relevance is when funding should be cut off, not augmented.”

Or, taking it down a peg, we could simply label what I was doing as gathering ‘useless knowledge’, which like basic research does not have an immediate application in mind, and additionally does not even seek to answer questions considered useful in some way. Here again, mine would not be the first story lending credence to the idea that useless knowledge is, ultimately, useful!

But perhaps the simplest way to view this episode was as a playful, recreational activity which through sheer dumb luck gave me the skills needed to solve an important problem in my work life. My colleague Titus Barik analysed how programmers talk about programming as play, involving ‘spontaneous and creative expression’, ‘experimentation’, and ‘purposeless, ludic activity’. He found that many programmers reflect on episodes of playful programming as joyful experiences that catalysed learning.

I’m extremely grateful to Cookie Clicker for the journey it put me on, but even if I hadn’t ended up learning JavaScript because of it, I still wouldn’t regret, and would cherish, the many many hours I spent tinkering and clicking away in my college dorm bedroom.

References

Mansfield, Edwin. “Basic research and productivity increase in manufacturing.” The American Economic Review 70, no. 5 (1980): 863-873.

Flexner, Abraham. “The Usefulness of Useless Knowledge”. Harpers, issue 179, June/November 1939. Available at https://www.ias.edu/ideas/usefulness-useless-knowledge.

Barik, Titus. “Expressions on the nature and significance of programming and play.” In 2017 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp. 145-153. IEEE, 2017.

Sarkar, Advait. Interactive analytical modelling. No. UCAM-CL-TR-920. University of Cambridge, Computer Laboratory, 2018.

Sarkar, Advait, Alan F. Blackwell, Mateja Jamnik, and Martin Spott. “Interaction with Uncertainty in Visualisations.” In EuroVis (Short Papers), pp. 133-137. 2015.

Sarkar, Advait, Alan F. Blackwell, Mateia Jamnik, and Martin Spott. “Teach and try: A simple interaction technique for exploratory data modelling by end users.” In 2014 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp. 53-56. IEEE, 2014.

Sarkar, Advait, Martin Spott, Alan F. Blackwell, and Mateja Jamnik. “Visual discovery and model-driven explanation of time series patterns.” In 2016 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp. 78-86. IEEE, 2016.

Sarkar, Advait, Mateja Jamnik, Alan F. Blackwell, and Martin Spott. “Interactive visual machine learning in spreadsheets.” In 2015 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp. 159-163. IEEE, 2015.

Sarkar, Advait, Cecily Morrison, Jonas F. Dorn, Rishi Bedi, Saskia Steinheimer, Jacques Boisvert, Jessica Burggraaff et al. “Setwise comparison: Consistent, scalable, continuum labels for computer vision.” In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pp. 261-271. 2016.