Note: This is an abridged version of my full major research project paper. To play the game, visit my itch.io page.

Intro

The project that became my Master's degree MRP started as an observation: just as most people use cars without understanding how they work, and rely on others to maintain and repair them, even "digital natives" in their 20s and early 30s use their technology the same way. I've heard and overheard dozens of people complain about relatively simple issues like Outlook being configured incorrectly, Wi-Fi issues that were fixed by running the built-in Windows troubleshooter, and phone settings. The purpose of this project is not to look down on less technical people. Instead, it's twofold. First, what are the consequences of this lack of knowledge? We're all intuitively aware that non-"car people" are vulnerable to being ripped off by mechanics; are there parallels to technology? Second, what can be done about it?  To maintain the scope of this project (a 6-month major research project and and game development cycle), I took digital privacy and security as a stand-in for overall technological competence - research is fairly easy to come by, and the comparison is logically sound.

The Problem

To hand-wave a little bit, there is a common perception in media and popular culture that millennials (b. 1981-1996) are "tech-savvy", but are less concerned with many digital security factors and privacy behaviours. Think about how many grandparents you've heard ask their grandchildren for tech advice, or how many dire warnings about young adults showing a lack of concern for the photos and content they post on social media. However, some initial research validated that millennials are not as unique as may be commonly perceived. In fact, when looking at the older half of the generation, they show just as much concern for their privacy online as Generation X, if not more. Instead, this perceived lack of caring for privacy and security among young millennials and Generation Z might simply be a function of having less to lose - no significant financial resources, little medical history, and less career progression.

So, having established that millennials, in general, would value protecting their privacy, how do their security behaviours actually measure up? If the popular perception holds true, they should be markedly better than older generations, at least assuming their "tech-savviness" extends to protecting their data online. Turns out that's not the case. Millennials are strong in some areas, like using password managers at higher rates, but overall show all of the behaviours most people would likely admit to themselves - reusing passwords, insufficient password complexity, not installing antivirus software, delaying security updates, and more.

As a game, The Scoop both succeeded and failed. I was very happy with the storytelling elements, the graphics, and the gameplay, but I felt there could have been more educational content and (on the "research" side of "major research project") better measurements of the educational outcomes. In the rest of this write-up, I'll describe specific aspects of the game that stand out, especially the ones I didn't get to write about in the paper because they were outside the scope of the research.

The Game

The original concept for The Scoop was a toolbox of multiple games, linked by a hub world, which would each teach a single area of technology. However, that scope was quickly reduced to a single proof-of-concept game, partly due to the COVID pandemic which reduced time on campus and access to university resources, and partly to allow a higher level of polish rather than rushing multiple games.

I think it turned out pretty well (play it here). This is my first time making a game, so I failed fast and early, and managed to work past most of the bugs. One element I was only able to discuss briefly in the paper was the graphics, which I almost entirely drew myself. All of the character, menu, and overworld art was drawn by hand in Aseprite, with only a few in-game UI icons pulled from Kenny Game Pack 41. I think it turned out pretty well (see the banner image at the top).

Character Speech

I did briefly pursue a "talking" system where the characters could dynamically voice audio based on the written dialogue. This was inspired by Animal Crossing (which I was playing at the time), where the characters speak gibberish but it's still semi-intelligible. My first thought was to have the characters read the first letter of every word in a high pitch - which sounded about as terrible as you'd expect. Next, I downloaded a set of all the unique English phonemes, and tried to recognize them in the text and sound them out. That sounded better, but the transitions between the sounds weren't nearly smooth enough, and it was easy to distinguish the boundaries. It was kind of an uncanny valley of gibberish. The final attempt before giving up was to reverse the audio of the phoneme clip. That actually sounded remarkably good, and was going to be implemented in the final game...until it turned out Unity builds for WebGL don't support playing audio in reverse. Go figure. Of course, I realized later that I could have just thrown the phoneme clips in Audacity and reversed them manually, but by that point I'd moved on to other challenges with the game.

Save/Load Functions

This was an interesting one. This is a long-ish and (supposedly) story-driven game, where the first thing the player does is create an avatar that looks like them. I hated the idea that if they reloaded the page, all that progress would be gone and they'd have to restart. The simplest way to implement saving and loading data is to use the PlayerPrefs functions built into Unity, which can persistently store and recall small (<1 MB total) amounts of data. Only string or integer variables can be stored, and they also need to be given a name to recall them by. Storing level progress was easy enough - an integer represents the number of levels which have already been completed, and if this is greater than zero, the start screen will show a continue button. Normally, I would have used a similar approach to store avatar data: multiple parameters could be used as indices into face, hair, and colour arrays. However, I was running out of time and having issues with that method, so I used a simpler one. I took the bitmap representation of the avatar, encoded the bytes to a string, and wrote that to a JSON object which I then saved in PlayerPrefs. This does have one advantage, besides ease of implementation - even if the order or number of hairstyles change in future, player avatars will always appear the same as when they were created. "If it's stupid and it works, it's not stupid."