Category Archives: Radical Game Design

Radical Games: The Clay – Project Proposal

The Clay is a project inspired by simple storytelling, an attempt to combine pixels, notes, and a background story into an experience that would make the audience feel something for the characters and get sucked into the game world. The game began with a simple idea, a mental image of a little boy breaking out of a building onto a bridge with a sunset, and him panting and dropping to the ground, while a player is tapping harder and harder on the screen to get him to stand up and keep running. Over time, a story has emerged of a world complete with a population of clay/terracotta people, a set of large tyrannical antagonists, and a subplot for the game specifically is to be simply about a connection between two friends. It is to be heavily music-based, with the notes and the rhythm matching the main Clay’s footsteps and drawing the player into a meditative state. Clay concept day 1

  The piece of note paper, including the first idea for the ‘clay’,

concepts for the music, thematic elements, and the ending of the story.

However, this is a ‘radical’ video game design class. Most games are designed to bring the player into some sort of a ‘trance’ – what would be different about this game? The radical aspect of this game, in my opinion, is that, while being so simple, there will be no way to keep track of a score. The only thing driving the player to play the game will be whatever emotional connection they have to the character. There will be no way to measure how far they get into the ‘endless’ level unless they’ve beaten it (which will certainly require a lot of time and perseverance). And hopefully, with slow, droning music and an adequately designed setting, the trance state that the players are brought into will be one not of energy, anxiety, and hyper-awareness, but one in which their brains are opened into pathways of thought and focus that bring them into a more relaxed and real-world-productive state. Clay Form ConceptClay person concept

Concept art for the antagonist (left) and the main character (right

The game will feature assets that will attempt to work in ways that the player would not expect, but will still make sense. For example, there will hopefully be creatures crawling around the temple that the game is based in that the player can encounter – upon touching these creatures, either nothing would happen to the character, or something positive would happen that would catch the person off guard. If there are creatures that resemble broken, crumbling forms of the antagonists, maybe upon coming into contact with them the protagonist will take pity on them and give them aid. Torches, which are generally used to provide light, could be used to harden the clay and thus have a negative connotation. Generally, while providing an entertaining and compelling experience, I want the game to make subtle, consistent nudges at the player’s expectations of what a game should be.

Fade Post Mortem

I ended up spending a lot more time on coding than I initially realized it would take. Oddly enough it was in things I assumed would be seemingly simple that ended up taking the most time whereas many of the codes I thought would be quite challenging ended up being quite a breeze. For instance, creating consistent backgrounds that changed for each scene and that travelled with the player seemed like it would take forever to get working but ultimately it was just a matter of creating an object that traveled with the camera and laying an image texture over it. Screen Shot 2016-05-01 at 9.36.21 PM Screen Shot 2016-05-01 at 9.35.44 PM (examples of different backgrounds that travel with the player.) Meanwhile, things that seemed as though they would be basic, such as changing the code from an endless runner format to one where the player simply moves with the push of a button took an incredibly long amount of time. Ultimately what gave me the most trouble was making obstacles that moved back and forth on a set track. I had some semblance of an idea that this would be a difficult task but I did not realize it would take me literal weeks to get working. Ultimately I was able to write a code that not only moved it the obstacles but changed direction when the obstacle’s edge hit one of two catchers. From there I had to make sure that the obstacles changed direction to ensure that the side with the trigger always hit the catcher it was moving towards and thus prevent it from getting stuck. Additionally, getting the flower to work has taken quite some time, though some factors have gone more quickly than others. For instance, getting the flower to trigger a sound effect, destroy the obstacles, and stop the music did not take much work, however, getting the flower to vanish after being picked up has proven quite difficult. I am also still working on getting the flower counter to trigger one of two multiple endings which will hopefully be done in the next couple of days. Screen Shot 2016-05-01 at 9.35.18 PM ( heart obstacles plus flower) Ultimately I had a lot of fun taking my basic idea and messing around with problem and solution boxes of the game as discussed in class during our discussion of Avant-garde Videogames: Playing with Technoculture by Schrank, Brian, and J. David Bolter. I had my initial idea of a game dealing with loss and memory but it wasn’t quite “radical.” However, after the discussion of the text, I came to the idea of messing around with traditional expectations of video games. Thus I changed my game to reflect this, placing tempting “power-ups” in the form of flowers that remove the obstacles but which ultimately trigger the bad ending (as signaled through musical and art shifts.) Ultimately the player must overcome their knee jerk desire to take the power-up they have been trained by other games to try to get. Instead they must take the game on at its most difficult in order to achieve the good ending. In this way, the player mirrors the journey of the protagonist and his resistance (or succumbing to) the desire to simply block out his memories rather than face them. Ultimately working on this game has been a major learning experience. I have learned not only how to mess around with traditional gaming formats to create something deeper, but I have also been exposed to many new programs that were entirely new to me yet which are incredibly valuable tools. Programs such as Unity, GarageBand, and Piskel all took quite a long time to get used to and learn how to use, but once I got the hang of them it felt like some real tools were added to my arsenal. All in all this has been a major learning experience, that, though incredibly time consuming and often very frustrating, has taught me much and left me with many useful skills. Screen Shot 2016-05-01 at 9.49.59 PM (Sample of GarageBand, one of the many new tools I learned to use during this project)

Once Upon a Time Post Mortem

Screen Shot 2016-05-01 at 10.46.33 AM Once Upon a Time was (and still is) a project that has taught me a lot about making a video game, but more generally making anything. The first, and most important rule, that I learned was to MEASURE EVERYTHING. It doesn’t matter if your making a table, a video game, a painting, etc. make sure that you measure and scale the pieces of your project before you go about constructing it or you will inevitably have to make certain parts over again. This is precisely what happened to me, I did not yet understand how (and the gross amount of work and time it would have saved me) to scale objects. When making and then inserting the platforms into Unity, I discovered that the relative size of my platforms to my main character made the game unplayable (or at least a totally different game. What I ended up having to do was delete many of my assets and then redraw them from scratch. While it is true it was somewhat easier for me to redraw them the second time, it was easier but unnecessary. In a way there were two types of problems that I had in this game. There were the known problems (things like: I am not an amazing artist, I don’t know code well, have 0 experience), which ended up being fairly small potatoes in terms of time spent fixing them. Then, there were unknown problems (things like: scaling, getting my background to rotate). Inevitably I ran into problems that I did not know I would have at the outset of the game. I have mixed feelings about these problems, on the one hand I did enjoy the task of problem solving the unknown problems, it was at the same time a stressful task and required no small amount of time itself. That was in a large way the biggest time suck problem that I had during the game. There was also a large element of creating a game that balanced what I wanted to do with what I was capable of doing. The game’s theme is time and when creating the art and the power ups at the beginning I created many more platform sketches, obstacle ideas, and power up concepts than I used. For example, I wanted to insert a “blackhole” obstacle, that warped the time of the game as well as sucked in the player (and platforms) if they got too close. Unfortunately, I do not have the programming chops currently to code a black hole into my game (although I do have the sneaking suspicion it is not as hard as one might imagine). There were also many platforms that fit well with the theme of time, but for one of two reasons I only created three types of platforms. The first reason is simply time, since each platform is a clock and counts, the number of iterations that I had to create to create one single platform was quite large and it was unreasonable (and would have been a waste of time that needed to be spent on other things) if I had created the 15-20+ platforms that I imagined at the beginning. The second reason is that some concepts did not exactly mesh with the way the game came out as it was produced. For example, I had a shoe platform, the time concept being that the should would tap up and down like it was keeping time with a song. Another example would be a metronome. While both types of platforms are fine examples of the passage of time, both of them represent time in moments or in seconds and the platforms that I have ended up going with have a longer timeframe. Having both types of platforms would inherently disturb the manner in which the player would perceive time within the game and although that is one of the goals of the game, this would have been in a way that did not serve the purpose of the game. I spent some time belaboring the character model that i wanted to go with. My options were the rain drop and the center of the clock Emits. While I did love the rain drop because of its connection to Blade Runner and the potential it had to look beautiful (luckily I got to render some of the animations and it did look beautiful), it was simply a step away from the game. Once Upon a Time, although I have a ton packed into it in my own experience, is a very simple game and the rain drop would be a little bit too far off from the rest of the style of the game for a few reasons. Not only the complexity and fluidity with which the rain drop is rendered (the rest of the game looking quite blocky), it also did not make narrative sense without stretching the narrative unnecessarily. The picture I’ve added is a screenshot of the game as it is. The things I need to complete still are getting the other types of clocks running (only digital runs now), adding the background and background sound as well as adding the splash art at the beginning.

Gumiho Post-mortem

Getting Gumiho to its current state has taken a lot of work! Maybe a bit more than I expected! But it’s been very rewarding to see the game slowly take form. I still haven’t finished the game, but I have implemented all of the major scenes in at least a rudimentary form. Screen Shot 2016-04-30 at 11.50.46 PM

The Gumiho title screen. I wanted a font that was elegant but unpretentious.

One of the biggest challenges of creating Gumiho has been learning all the skills and tools necessary to realize my vision for the game. Creating the game involved work in Animate, Photoshop, Unity (and Unity C#), Audacity, and Garage Band, all tools I was completely unfamiliar with before starting the project. Learning to produce the results I wanted using these tools and my rudimentary art, coding, and sound design skills has proven to be quite challenging and has involved a lot of trial, error, and reference to tutorials.

Screen Shot 2016-04-30 at 11.51.29 PM

Gumiho’s first scene. The environment in this scene ended up changing quite a bit from the paper prototype. Ultimately, I felt as though the “shrine” setting fit the narrative better than the more mundane rural setting that I had originally planned on using, and created some interesting ambiguity in the relationship between the PC (left) and the NPC (right).

 Creating the art assets was one of the most time consuming aspects of the process. Most of the art was created using flash, and it took me some time to figure out how to achieve the aesthetic I was aiming for within the program. Ultimately I’m fairly happy with what I achieved, although the majority of the sprites, with the exception of the PC in the first scene, are currently lacking animation. Although the PC’s animation is functional, it lacks the fluidity I was hoping to achieve. Screen Shot 2016-04-30 at 11.52.09 PM

The game’s platforming sequence. I had some difficulty with this scene. I knew how I wanted to present the narrative through gameplay, but I couldn’t figure out what the platforms should look like. Ultimately, I decided to borrow from Buddhist symbolism. The lotus flowers, representing the potential for an individual to attain purity despite murky surroundings, felt like an appropriate visual accompaniment to the teardrops that lead to the “PC death” ending.

Unlike the opening scene, which proved to be fairly straightforward to code and was primarily challenging from a visual perspective, the platforming sequence was something of a technical challenge. Originally, my intention was to make the heart and tear holding platforms spawn in “sets,” with the higher platform being smaller and holding a teardrop, while the lower platform was larger and held a heart. The platforms were to be placed at varying heights. This design proved difficult to implement, and I eventually settled on a simpler solution in which most of the platforms spawn at a fixed height close the the bottom of the screen, and the tear platforms spawn at a second fixed height close to the top. They no longer spawn in sets, and the rate of occurrence is simply randomized based on a variable the determines how often they will spawn.

Screen Shot 2016-04-30 at 11.52.52 PM

The first time the player kills the NPC, as evidenced by the single filled in heart in the tracker in the upper left. This scene loads after the player has collected enough hearts in the platforming sequence.

  Screen Shot 2016-04-30 at 11.53.28 PM

 The “PC death” ending. Art not final.

Overall I’m fairly happy with the state of Gumiho, although it will be difficult to know to what degree I succeeded in achieving my original goals for the game until I’ve successfully linked up all the scenes (some lingering issues remain with the code that controls fading from one scene to the next) and tested it on fresh players who are unfamiliar with the narrative. The project has proven to be quite challenging in almost all aspects, but I feel like I’ve learned a lot and can’t wait to finish this game and move on to the next one! Thanks to all my classmates for providing great feedback on my game throughout the development process, and to Angela for teaching such an amazing class!

Gumiho Project Proposal

The primary inspiration for Gumiho was the potential that exists in interactive media to create dissonance between the player and the player character. I wanted to create a game in which the PC’s interpretation of events in the game world is at odds with the player’s assumptions, prompting the player to reconsider the nature of the PC once the reality of their actions is revealed to them. In order to accomplish this, I chose to base the narrative off of the Gumiho myth in Korean folklore. Essentially, the PC is a Gumiho, a sort of fox demon that takes on a human form in order to seduce humans and eat their hearts. The Gumiho must regularly consume hearts in order to stay alive. If they manage to consume enough, they may become a normal human Gumiho aims to be radical by calling into question the value of “progression” in the game. The game presents two possible outcomes: either the player collects enough hearts in the platforming sequence to kill the NPC and claim their heart for themselves, or they abstain from collecting the hearts and sacrifice themselves in order to save the NPC. Taking the hearts leads to the longest experience, and allows the player to continue through to what feels like a more natural outcome; the player must repeat the process of collecting them several times for several different NPCs. It is also in a sense the most easily attainable outcome, however, as the hearts are placed in more readily accessible positions as opposed to the teardrops that lead to the PC’s death. Further, the outcome that results from taking the hearts is not necessarily the most emotionally fulfilling for the player, as it forces them to cause harm and does not allow them to play the hero of the story, or even a positive character (although the relative satisfaction derived from the two endings is, of course, ultimately determined by the disposition of each individual player). By disrupting the expected relationships between effort, time invested, and narrative reward, Gumiho aims to push the player to consider current conventions with regards to narrative presentation in video games. Gumiho1

An early version of the game’s story, before the platforming sequence had been finalized.

The precise narrative structure went through several iterations before arriving at the version that was used in the paper game. The game uses a sort of runner section to represent the PC’s thoughts in abstracted form, and one of the biggest challenges was figuring out how to implement this sequence in a way that would make sense to the player. Part of the solution involved paying careful attention to the continuity of visual elements between the “real” and “abstracted” segments of the game. Gumiho3

It took some time to arrive at a narrative delivery that was clear while still retaining the original meaning of the story. In this version the platforming sequence is starting to take form.

The paper playtest was successful insofar as that the players were able to interact successfully with the game and follow the story from beginning to end. Unfortunately, however, I did not receive much in the way of feedback that might lead to revision of the proposed game.  I am somewhat concerned that the testers’ familiarity with the game’s narrative may have obscured any remaining issues with narrative clarity. Gumiho2

Above: The paper version of Gumiho. Artwork for the platforming sequence still hasn’t been finalized.

We derived the following asset list from the paper game: Background 1, Background 2, Trees, House, Male NPC, Female NPC, Male NPC dead, Female NPC dead, PC human form, PC fox form, PC fox form dead, Platforms, Hearts, Teardrops, Broken heart, Heart-tracker Interface.

Once Upon a Time Concept

EmitMovingWoodenHourglassDigital(scale)AnalogScaled   The art featured above is my main character (Emit) and the three types of platforms that I am using currently. More to come. The concept behind my videogame Once Upon a Time began when we did our exercise for homework about transferring a fairytale into a five point aristotelian narrative. I did not use the fairytale that I adapted for that exercise, but as I found myself thinking of the fairytales as a hole and the manner in which many of them start, with the introduction “Once upon a time”. Being a lover of puns, I pictured a small spec of dust sitting on top of a clock and the clocks hand moving a beat and the spec falling off of the clock and being sprung forward into/with the seemingly absolute flow of time. My main characters name is Emit. I played with two concepts for Emit. One, although I did not use it, was a raindrop. I based the concept partly on a quote from Blade Runner, “Moments in time are lost like tears in the rain.” This quote encompassed much of what I sought to talk about through my game and I attempted to create my character through this paradigm. While I did, and still do, love the idea of using a rain drop, I found myself feeling like I was forcing the issue and then scrapped the rain drop for the simpler Emit that I had created before the rain drop, who was simply a black spot with a small white eye. The idea of this Emit being that Emit is the center piece of an alarm clock. This introduces the idea that Emit, and therefore the player, is holding together time in a very literal way. In the opening scene/splash art, when the player presses the “Start” button the alarm clock would shake and break, dropping its hand and Emit out from the case that normally holds it together. Once the face is broken, Emit begins to move along the platforms that are all clock themed in some way until either he falls off and dies or ends up destroying the fabric of time itself. It is arguable whether either of these possibilities is failure or success. As I continued to flush out this idea, the theme of time naturally gelled with the flow contained traditionally within an endless runner video game, both of which seem from the human perspective to be nearly endless if you look at them from end to end. That being said, this being a class that in some ways pushes us to subvert the genre of endless runner, I wanted to create a way in which Once Upon a Time would subvert the genre. The manner in which I imagined going about this came about fairly naturally as well. When I thought about introducing the idea of power ups, speeding up and slowing down time came to mind as the power ups. Thinking a step further, and luckily having been inundated for years with science fiction stories, when one plays with time and manipulates it, the fabric of time begins to break down, so in collecting the power ups that make the game more interesting and fun, the player will break down the game and when a certain number of power ups are collected the game space will be destroyed (Game Over). It seems that the only way to win is to not play. Overall, I very much enjoy Once Upon a Time on a conceptual level. The themes of the passage of time, inevitability and even fatalism are ones that I find interesting and ruminate on continually in my own life so it has been quite useful to be able to explore them in a detached medium.  

Radical Games: Fade

Screen Shot 2016-04-25 at 1.59.50 AM My project plays with the ideas of memory and loss through a simple 2D side scroller. The player progresses through various stages of memories, each which comes equipped with deadly obstacles that must be navigated past representing each memory. For instance in one memory of love the obstacles are hearts, whereas another memory of music has musical notes that must be snuck past. As each level is passed the protagonist is taken to a portal that teleports him into another memory, all together totaling five and telling a complete story. The story is ultimately about a young man, falling in love with a young woman, her death, and his attempt to overcome the grief. The player has the option to attempt to use flowers that grow up over the landscape to eliminate the memories and the obstacles along with them as a way of easing past each level. However, this ultimately triggers the “bad” ending. Only by working past each memory, rather than hiding from them or trying to destroy them can the player find the good ending. The art style is a simple pixel style, meant to be light and simple. The colors start off dreary in the “real” world, then transition to vibrant and happy in the initial happy memories, before getting darker and darker as the memories reach nearer to the tragedy. Ultimately if the happy ending is achieved the colors and tone return to happiness and light, whereas if the bad ending is reached, the darkness overtakes the player. This art style is supposed to tie together the childlike nature of the game and the player with the darker themes and hard challenges present within.