Preface

For much of my game designing career, most of my games have been designed “bottom-up,” which essentially boils down to “gameplay first, aesthetics later.” I first ideate particular mechanics that I find fun and exciting in a vacuum (existing only as abstract objects and rules). Then, once I tune the gameplay to my liking and identify the emotions and themes that emerge from the gameplay based on playtests, I add a coat of art, narrative, and other aesthetics that fit to support what already exists mechanically.

It’s rare that I ever start a project “top-down,” or know exactly what themes, narrative, messages, or emotions I want to emerge within the player. It’s uncharted territory for me to start with a mold of wanting to make a game that makes the user “feel like X,” or “understand what it’s like to be Y,” or “is themed around the stories of Z,” and then building mechanics based on this.

As we studied different theorists and observed different projects throughout the semester, I found myself particularly drawn to the narrative intentionality of these projects. Whether it’s “Depression Quest” with its systemic expression of living with depression, or Pippin Barr’s minimalist experiences that convey meaning through constraints, much of what we’ve viewed had a very clear abstract intent that drives the rest of the design and expresses it through the player’s engagement.

Project

Drawing inspiration from these works and theorists like Bogost’s concept of procedural rhetoric and Murray’s ideas about kaleidoscopic storytelling, I aim to take a novel I have a deep appreciation for – “Kafka on the Shore” by Haruki Murakami – and create a gaming experience that expresses its themes and aesthetics through mechanics rather than just narrative adaptation.

The key thing I’m attempting to avoid with this project is simply converting the narrative into a linear, interactable format. The focus here is not to retell the narrative but to create a gaming experience that expresses the same themes and aesthetics as the story. I hope that a player who has never read the novel may play the game and, when asked what themes and emotions were involved in its gameplay, will match much of what’s present in the novel. Meanwhile, a player familiar with the book will come out of it thinking, “Wow I really felt like I was playing as the character from the story!”

Current Ideas

What precisely this project looks like will be iterative as I work on it throughout the month. I’m still unsure if it will be best to approach this as a digital experience or potentially as a board game, so I’m hesitant to make any hard commitments until I figure more out. However, the central concept I’m playing with is the strong theme of Fate & Prophecy in the novel. The key characters of note with this theme are Kafka Tamura, Nakata Satoru, and Colonel Sanders, with three players currently planned to take on these roles.

• Kafka is a young man running away from home to escape an oedipal curse given by his father, that his fate is to “kill his father and bed his mother and sister.” In gameplay, my idea is that this player would be the “Runner of Fate,” they would be made aware of their lost condition (their “Fate”) and must do everything they can to ensure this condition does not happen. The game would likely be turn-based, and if the player manages to avoid their fate for a certain number of turns, they win. 
• Nakata Satoru is an elderly man who, despite his simple mind, possesses supernatural abilities like talking to cats or creating a storm of raining fish. He unconsciously follows a path that makes him an unwitting agent of fate, ultimately fulfilling Kafka’s destiny without knowing it. In the context of gameplay, this player would be the “Agent of Fate,” and they would be utterly unaware of Kafka’s fate, but they would have unique abilities to try and make it occur. This player would rely on the Colonel for direction on their actions. This player wins by activating Kafka’s loss condition. 
• Colonel Sanders is a mysterious being who appears as the KFC mascot. He is present to provide Nakata with vague directions on what he must do, never elaborating or explaining why it needs to be done, but acting as an aid to ensure Nakata performs them. In gameplay, this player would be “Fate,” they would be omnipotent in Kafka’s loss condition and would exist to aid Nakata by providing cryptic hints on what he needs to do. However, this player would be unable to act directly or change the game state, only capable of enacting their will by guiding Nakata to perform specific actions. This player wins when Nakata wins.

Of course, these ideas are high-level and subject to change, and I’d like to incorporate many other key symbols and parts of the novel (Turning of the entrance stone to change the game state, Kafka taking over Nakata’s body, etc.) I’d need to fill in a lot of stuff, but I hope this demonstrates the type of narrative conversion I’m going for.

Deliverables:

• All materials needed to play the game, including an instructional video/booklet for players to learn
• A Game Design Document explaining the game’s mechanics in detail. Encompasses the vision for the project, reasons for certain gameplay decisions, and mechanical relations to the chosen novel.
• Documentation of playtests run with others and their consequences on the game’s design. This will describe 
  • The current state of the game’s ruleset
  • Questions and problems I beg to answer with the playtest
  • Detailed notes on what I observe as playtesters engage with the game. What do they enjoy? What are they frustrated with? What is vague?
  • A list of changes I make to the game based on the test
• A post-mortem analysis at the end of the project. What went well? What didn’t? What did I learn from this experiment, and what could I do better in future projects?

A few weeks ago in class, I touched on “The Walking Dead” video games and how interactive mediums can push storytelling beyond what is ordinarily possible in most traditional media forms. Now we have Bogost’s definition of “procedural rhetoric” and how video games can make arguments or teach lessons through their rules and mechanics, rather than just telling you something directly. As such, I’d like to take another brief look at this game to discuss how it approaches a “coming of age” story that directly uses its interactive format to allow the user to experience this growth alongside the protagonist rather than simply observing it as an outsider.

In Season 1, the player controls Lee, an adult who is a father figure to a young child named Clementine who has lost her parents. During this section, players make decisions in the narrative with clear knowledge of what consequences will arise from them. It’s obvious which dialogue options appeal to which philosophies and which characters. Choosing to save one character over another or accusing a person of betrayal or anything else will have straightforward and logical ramifications. The game’s mechanics reflect an adult’s understanding of the world – choices have clear consequences, and the player can generally predict the outcome of their decisions, mirroring an adult’s ability to understand cause and effect.

However, in Season 2, when the player takes control of Clementine as a slightly older child, the game’s mechanics transform to reflect her perspective. Up until this point, Clementine had all her decisions made for her by Lee, so with him gone, she makes the mistake of leaving her gun unattended and getting her friend killed. The player has absolutely no agency in this, Clementine isn’t used to considering the ramifications of her actions, so the player isn’t allowed to either. As the game progresses from this starting point of her character, decisions made have a murky aura in what their consequences will be. A simple act of kindness to a friend can unexpectedly cause a man’s death. A seemingly neutral statement may unexpectedly cause hatred and resentment from other characters. Minor choices sometimes have massive unforeseen consequences, while apparently major decisions might prove meaningless. This mechanical shift isn’t just a part of the story; it’s procedural rhetoric in action, using the game’s systems to show the nature of growing up and how children’s uncertainty and inexperience have them perceive the world.

The game culminates in its final decision, where the two adult figures get into a climactic argument that ends in a violent brawl. Clementine then chooses, does she let one character get killed, or shoot the other to save them? After a season of uncertain decisions and ambiguity, this is interestingly the only time in the game where Clementine as a character, and we as a player, have a clear understanding of the consequences of our decision. In this sense, the game is clearly about this growth, this development from having no-agency to complete-agency, and the murky path needed to reach this point. It’s about becoming Lee, and by using clarity in the game’s systems themselves, players don’t just observe Clementine’s coming-of-age story – they feel it directly through their interaction with the game’s mechanics.

In this way, The Walking Dead demonstrates one of the unique strengths of procedural rhetoric in video games – the ability to make arguments not just through what the player sees or is told, but through how they interact with the game itself. The game doesn’t just tell us about growing up; it creates a system that lets us experience that transition from childhood uncertainty to adult understanding through its very mechanics. This approach to storytelling would be impossible (or very difficult) in traditional media forms like books or film, which can only show us these transitions from the outside. By leveraging the interactive nature of video games and carefully designing its systems to reflect its themes, The Walking Dead creates a uniquely powerful coming-of-age story that exemplifies Bogost’s concept of procedural rhetoric.

Before we started this unit, I had never read Alice In Wonderland. In fact, I had never even watched the film (and still haven’t) so I approached the text with a very fresh mind. Given how much I adore illogical, abstract, and ludic artworks, I definitely found much to enjoy in the writing. One of the main things that stood out to me, which we discussed in class, was the distinct modularity of the chapters, in that each one felt self-contained from all the others. You can swap around the chapters in any order, and it would not matter as long as you cleaned up their transitions a little.

As my group brainstormed the different options we could approach with the project, we had many ideas. Ranging from intersecting different video-game genres to reflect the chaotic nature of the narrative to a straightforward branching-retelling in Twine to ambitious 2D Unity projects. After a week or two of brainstorming, we leaned into the modularity of the chapters in the novel. We let each of us have our take on how a particular chapter may look in an interactive narrative format. With how random and odd the story could be, there was no reason to stick to a consistent style for the entire project. Since I’ve only really touched C# and game-related-code, Matthew and Tasha took the lead on making the project function.

My initial goal was to try to flex my game-design muscles within my chapter and come up with something really interesting that incorporated Alice’s narrative into the gameplay in some cool way. Unfortunately, my Disney trip and other obligations greatly limited how much time I had to work on the project, so I aimed for something simple and intuitive to get the project finished in time.

The game’s initial concept was to be a grid-based mini-game based on the end of chapter 6, where you control the Cheshire Cat and lead Alice to the house of the March Hare. You do this by clicking on a tile to spawn the cat. The player can only choose a tile that is in a straight line vertically or horizontally to Alice. Alice would then walk to where the cat is one tile at a time; if she runs into an obstacle while walking, the player loses and must restart. After choosing a tile, the Cheshire’s grin permanently stays on that tile, and the player can not place a future cat there again. So the overall goal is to lead Alice from point A to point B while having her avoid obstacles along the way

I usually would first prototype this design itself on grid paper to try and see if this would even work as a game, but due to time constraints, I neglected this and went straight to the code, spending a long while getting the grid system, turn system, and core mechanics to work. Unfortunately, I had many bugs and errors getting this to work as I wanted to, and by the time I approached something functional, I realized just how little time I spent properly thinking about how I even *wanted* so many parts of the game to work. I tried to take many steps back and experiment with paper-prototyping the concept to figure out what needed to be done to make the game fun. But at that point, it was already 5AM during my last night in NYC; I was exhausted from the code and had my train to Florida that afternoon. I decided to drop everything until I came back from my trip. I informed my group of my failed mini-game attempt and that I’d work as much as I had to when I came back from Florida.

When I returned, I had two days to either try to salvage the mess I left behind or figure out another option. One of my group members suggested that, as an alternative, I could reskin my existing game, “Pick Yourself Up!” as the Flamingo Croquet game from the novel. I was hesitant to pursue this as I’m pretty uncomfortable with art and felt that giving up on my initial plan would hurt my identity as a game designer, but after realizing how unfun and unfinished my current work was, I decided it’d be best to focus my efforts on making new art assets for an existing game that I already knew worked. I went through many iterations on how the new pixel assets looked, with the hedgehog being a particular challenge, and after a day’s work ended up with what is shown in the final project.

Overall, I’m really happy with what we ended up with. Everyone in my group was super talented, and we ended up with a project that truly came together. Of course, I feel a good amount of regret on the chapter I personally produced, as I definitely wish I could have ended with something more exciting than what I made. But, in the end, I suppose experiences like these are important for artists to go through. Not every idea will work out, and attempting to skip essential parts of the process to get things out quicker will only lead to more confusion, delays, and uninteresting results. And while the sunk-cost fallacy can make it tempting to keep at it and try to make a bad idea become a good one, it’s often in the artist’s best interests to give up on what isn’t working and figure out something else that can work.

There’s an undeniable pleasure found in the act of creation within an enclosed system that elicits the fun in many famous games. To take a blank canvas and use only what’s available to you, to make whatever you can push the boundaries to allow yourself to make. To go about things one step at a time to eventually end up with a massive and satisfying end product. People are building entire cities or computers in Minecraft, vast interconnected narratives in D&D, or brand new games and experiences within Super Mario Maker.

“The structures, limits, and materials of the world are not enemies poised against human creativity and experience, but rather support creativity and experience,” as Ian Bogost claims, and it’s clear that this is particularly true when giving players any method of creation. They will take your rules and push them to the very limit, working within your framework to make things you never even considered possible, and this is fun for the players. Creation under strict limitations elicits clever problem-solving from the user, which makes this a game.

In this sense, can one consider a game engine such as Unity to be a game? In many ways, the act of development elicits the same pleasures found in these other games: chipping away at a product to eventually make something massive and grand, streamlining the efficiency and output of your code (akin to the programming-like pleasures derived from Factorio), and then taking the game objects you’ve created and placing them in interesting ways to make interesting levels or stories.

Though it’s clear why the general public has never considered a product like Unity to be the sandbox experience of their dreams. As Bogost states, “The pleasure of limits arises from the experience of deliberately working within them,” and in a product like Unity, there simply aren’t any limits or rules to constrain the user. You can make, literally, ANYTHING. That amount of freedom is daunting and paralyzing, leaving many who start game development overwhelmed and unsure of where to start.

Perhaps this is why the practice of “game-jams” (making a game based around a certain theme under a timeframe) is so common in the field, especially among beginners. Having full, unrestricted freedom is so paralyzing that the only way anyone can truly appreciate the game-like qualities of game development is by finding any kind of box to stay inside of

Understanding the daunting freedom of a game engine like Unity makes me wonder if this is truly the best place to start for those interested in game development, as many in the profession tend to recommend. Of course, once you get past the initial paralysis and understand how to self-impose your limits, you can eventually find the similar pleasures found in creative-building games like Minecraft. Still, I consistently see people on game dev forums who just started and have no clue what to do after learning the program, and many outright give up.

This thinking has brought my attention to the game development engine PICO-8. This program seems determined to provide an answer to the limitless freedom other popular engines offer, generating a “playful” alternative to game development.

PICO-8 is a “fantasy console,” a virtual system that mimics the limited graphics and audio of 8-bit systems of the 1980s. It forces the user to work with a 128×128-pixel display, 16 colors, 4-channel audio, an all-in-one development environment, 8192 maximum tokens of code, and many other limitations. 

I’ve yet to experiment with the engine myself, but writing this has made me grow more and more interested in trying it. Not only do its strict limitations allow for playful and creative problem-solving and a forced adherence to a smaller scope, but the “fantasy console” seems like it would elicit much of Caillois’ Mimicry, as you’re effectively role-playing as an 80s game developer who must make a game under the constraints of their technology of the era, adding an extra layer of playfulness to the development experience.

So, perhaps in the future, when someone asks me how to best start learning game development, I may tell them to save Unity for later and go straight to PICO-8, as the limitations and smaller scope it provides may help them find the playfulness in the hobby sooner than with Unity.