Prof. Christian Sandvig
26 April 2016
For my final project, I created a virtual visual walkthrough of the first chapter of a text-based game that I designed last semester. The text based game, called “Okay,” is a mystery-thriller that combines the so-called ‘limitations’ of text with the player’s imagination to create a game that would be intimately personal to each player, because they would be the one whose mind would supply the appearance of the game’s villain, the mysterious roommate. The original game explored the ways our own fear, isolation, and confusion can often trap us, but also walked the player through the process of healing and left them with the courage to stand up to their greatest fears. While I was originally creating “Okay,” I relied heavily on pointed descriptions, timing, and music to draw the player in. So, when I was presented the opportunity to learn Scratch, I wanted to try to recreate “Okay” as a visual game, to find out if it would be more or less effective in a more traditional format. Effectiveness, however, is tricky to measure empirically, so rather I’ve come to the conclusion that there are certainly forms of gameplay that Scratch makes easier, as well as forms of gameplay Scratch makes harder.
When starting out, I sought to stick more to the game’s origins as an RPG. However, it quickly became apparent that offering the player several varied text options was cumbersome and slowed the game down considerably. So, rather than take a “dating sim”-esque approach, I decided to make the game a panoramic walkthrough and rely more on visuals than text, since Scratch doesn’t offer any in-program opportunities for text aside from the “say” and “think” blocks. In order to have the same number of text options I’d had in the original version, I would have had to make a ridiculous number of sprites. Thus it’s easy to conclude that Scratch prioritizes objects and visual cues over alphabetical or written ones. Additionally, it becomes clear that Scratch prefers games that are shorter and lighter. I had programmed another run-in with the mysterious roommate on their way out of the house, but my second text engine for that sprite kept breaking after running through the first block. Therefore, to keep my game simple and running optimally, I scratched (pun intended) that conversation and had the roommate leave before you could argue with them like you do in the Twine version of the game. Nevertheless, despite these limitations, Scratch allowed me to do something I’ve never done before–make a visual, interactive video game. While Twine does make an allowance for images, it clearly doesn’t allow movement or interactivity with objects like Scratch does. Additionally, Scratch is amazingly accessible. While I’m proud of the original “Okay,” not many people have the time to play a 3 hour long text-based RPG. Scratch, on the other hand, lends itself to simple yet fun games that are easy to create, play, and share with the world. Games that fall under the umbrella terms “side scrollers,” “arcade-style shooters,” and “dress-ups” flourish with Scratch, which makes sense given that Scratch is a learning language. Through Scratch, many people like me are getting their first taste for the world of programming, and though Scratch has its limitations, they serve to stoke one’s curiosity about how they could surpass those limits by learning new, more advanced languages.