Games
About
The Trials of Snowshoe Thompson is a game about an immigrant on a skiing expedition across the Sierra Nevada mountains of 1856.
The game is based on a real-life folk hero who answered an ad to deliver the mail between two remote towns in the Sierras. From his native Norway, John Thompson brought skiing to the western US and traversed the same route every winter for 20 years. Our game sees him as a young man searching for purpose on his first journey skiing over the mountains. We want our players to feel gratification from learning how to ski and connection to this folksy chapter in American history.
Development
I created and pitched this game idea for the Adavanced Games Project program at USC in 2020. It was accepted and we started development in May 2020, Our team grew to 28 people by the end of production, made up mostly of students from USC and Otis College of Art and Design.
I served as the Director of the game and oversaw creative decisions, production, and recruitment. I presented progress on the game biweekly to a panel of faculty for critique and advice. Because of my experience with solo development, I was also able to hop into the project for tasks when others on the team were busy. I did the lighting in the level, animated the beginning cutscene, adjusted terrain geometry and prop placement, and tuned the movement and camera systems. To pitch the game, I prototyped the gameplay and animation systems. The largest portion of my work was giving feedback and creative guidance to our team's artists and gameplay, level, narrative, and sound designers.
After a year of work, we presented our 10-20 min demo of the game for the USC Expo on May 15, 2021. You can check it out here or watch the full playthrough below.
We used Unity and C# as our primary tools, but also used Maya, Blender, Houdini, Substance Painter &Designer, Audacity, and Reaper. We used Perforce for version control, Jira for task tracking, and Discord &Zoom for communication.
You can check out my original pitching document here!
Team
Director - Ben Haderle
Lead Producer - KP Glenn
Producer &QA Manager - Arreanna Rostosky
Lead Designer - Fanfu Shentu
Technical Designer - Orson Wu
Lead Narrative Designer &QA Tester - Marika Perlmutter
Voice Actor (Snowshoe Thompson) - Evan Ivey
Lead Engineer - Aidan Takami
Engineer - Tyler Amano-Smerling
Engineer - Zichang Liu
Engineer - Greymon Tang
Engineer - April Chang
Lead Sound Designer &Engineer - Furkan Kilicaslan
Sound Designer - Graham Southern
Composer - Matthew Feder
Trailer Composer - Mario Verlangieri
Lead Artist - Longkun Yang
Character, Environment, &Lighting Concepts - Tiffany Kao
Character Concepts &UI Art - Eddie Marhx-Bolanos
Prop Concepts - James Liu
Cinematics - Dorian Trinh
Prop Concepts, Modeling, &Texturing - Patrice Nguyen
Prop Modeling &Texturing - Nick Vidal
Prop Modeling &Texturing and Character Modeling, Rigging, &Texturing - Pasan Dharmasena
Character Animator - Mia Andrea
Lead Usability Tester - Cole Ordesky
Lead Marketer &QA Tester - Stephen Ayres
Marketer &QA Tester - Stuart Bryson
About
Shoal is a short zen exploration game about growing a school of fish. I made it with Xiaocheng Tang as part of Andy Nealen and Peter Brinson's Interactive Production class at USC in Spring 2020. Dave Lewis made our incredible music.
I did much of the programming work concerning the fish's movement, the camera, and the sequencing. I also contributed some shaders, level design, and sound mixing. Much of this project's design was guided by trying to showcase the visual appeal of the way the fish looked. In that respect, I think the game was a success. However, I don't think the meachincs/possibility space as they stand could support the structure of anything much longer than the 10-15 minutes the game lasts right now. I was happy to work more in 3D and I'm happy with how the game looks.
For a full list of credits please check out the itch page or play the game :)
About
Ladders! is an early-80s-arcade-style action game about risk, flow, and growth while climbing an endless onslaught of falling ladders. It was my senior year capstone at NYU and I worked on it on and off for about a year. I did mostly everything from design to code to art to sound, but there are some more detailed credits in the game.
It's out now for iOS and Android!
Design
Players face an endless gauntlet of ladders that are not just challenges to overcome. Instead the field of ladders is a field of choices that carry risk. Jumping on a dangerous ladder may give the player an opportunity to pick up a coin for bonus points or put them in a better position to make their next choice. Alternatively, making a dangerous move could could result in disorienting effects, complicating future choices and forcing actions as a last resort.
As long as players make choices fast enough, they will continue to pick up speed. While the Ladderman doesn't stop, they climb faster and the player gains more points. At high speeds, it becomes a choice not to stop and risk making a quick, poor move. The speed is the greatest contributor to the sense of flow in the game, the sense of mastery in the player.
The challenges in Ladders! are not easy. Or, at least, they do not appear easy on first encounter. On their first run, most players fail to survive more than ten seconds. However by their tenth run, most have overcome that hurdle and now face new barriers. Ladders! requires a development of skill that drives players to set goals, not only to best others, but to best themselves.
You can learn about and play the first prototype here.
About
Take a Walk is a game about reflection, exploration, and chilling out. Enjoy short play sessions (~5 min) as you walk around a handcrafted 2D alpine environment and are given the chance to write about your experience. Meet new characters for every day of the week!
You can listen to the soundtrack by the wonderful Efe Torunoglu here .
Take a Walk was originally made as part of Bennett Foddy's Intro to Game Development class in Spring of 2016 at NYU. I then expanded on the content and refined the experience and released it in January of 2017. Check it out! If you're interested in knwoing more about the development, check out the devlogs at the bottom of the page.
Screenshots
Devlogs
Hi! This is the first of a few posts I'm planning about my current project for my Intro to Game Development class. Basically we spend the semester working on a solo digital game. We have one week to come up with and pitch an idea, five weeks to develop the core gameplay, four weeks to work on audiovisual stuff, and then five weeks to make more content/do polish/etc. I'm currently a week away from completing my gameplay focused prototype and so I'd like to write a post giving an introduction to the game before (hopefully)posting an in depth look into the gameplay in a week or two.
So here we go...
My game is called Take a Walk.
It's a 2D adventure game about exploration and chilling out. The idea was mostly born out of my desire to write more. I used to write a lot in highschool- whether it be daily journals or short fiction- but since I've moved to New York, I've really fallen off the habit. With Take a Walk, I want to create an explorable 2D environment that enables a situation that is conducive to being reflective. Since I find it easiest to reflect when I'm in the mountains, I'm basing the environment off the lakes I've been to while backpacking in the High Sierras. Specifically, I'm loosely adapting the area around Upper Graveyard Lake in the John Muir Wilderness.
Above you'll see my brother and I at the lake back in 2013 (it looks hazy because there were a lot of fires that year). Below is a higher quality photo that I think better captures the tone I want.
I was influenced by the casual exploration of Superbrothers: Sword and Sworcery and the written player creations of Elegy for a Dead World .
Each play session should last 10-15 minutes. In the first 7-10 minutes, the player explores the area, interacting with various parts of the landscape and talking to the hikers that hang out there. In the second half of a session the player would be given the option to write as much as they want. This writing should then be saved externally for personal use. In each new session there should be small changes to the lake(different time of day, new people, etc) so that there is something new to discover. Here's a slide from the presentation I gave that was my tentative backlog:
That's about it for now. I guess I should mention that I'm using Unity and Visual Studio to develop the game and it's going pretty well! Like I said up top, hopefully I'll be posting more about the gameplay in a week or two
Hello! This is gonna be an update on the exploration journaling game, Take a Walk. It'll be mostly focused on how I implemented the core gameplay features seeing as those are mostly done and locked in. Here goes it...
Some info on the tools I'm using- I'm using Unity 5.3.2f1 for the main engine and programming scripts in C# using Microsoft Visual Studio. I haven't really found an advantage to using Visual Studio yet over MonoDevelop, but I guess it's something to hold over the Mac users in class... I'm using Trello for backlogging tasks and then I use Twine to outline the dialogue so I can see it all in front of me. For version control I'm using a combination of Smart SVN(the trial version) connected to a free Assembla server. Somewhere along the line I messed up or something so now Unity thinks my project is called "trunk." I tried to fix it but it broke a bunch of things so I decided to just go with it. That's pretty much it in terms of stuff I used for creating the gameplay, but I'll include more applications I as shift to the audiovisual portions of the game.
When I started off, I broke up my work into three main sections: the walking, the dialogue, and the writing. These sections stayed pretty true throughout the project without any major additions. The one thing that I would say expanded a lot more than I anticipated was the connection of everything through different scenes. The solution I have for that isn't really clean, but it works, so I'm not touching it (this is a pretty common theme). I'm just going to go through each section and talk about how I implemented each one.
So first one is the walking. At the most basic level, the player clicks somewhere on the screen and the character moves to that point. At the time of the gameplay prototype, the way that worked was by converting the mouse position to world position, storing that and using it as both a direction and a determining factor in the speed of the player, the idea being that the player slows down as they get closer to the point.
With that out of the way, I began working to get a pathway of colliders working because it's not a game unless I can place invisible walls in front of you. This was simple enough and went as expected if you're at all familiar with Unity. What I did have to figure out was the way I wanted the camera to follow the player. In a classic novice move, I made the camera just a child of the player so that they would always move together. Bad move. It turns out that that's really disorienting. So my first solution was basically just to delay the movement of the camera by less than a second and then have it just follow at the player's velocity. This worked pretty well, but it wasn't perfect. There were ways to get the camera misaligned since it was essentially moving the same way as the player but starting late and ending at the same time the player stopped. I learned about a little thing called lerping and now I just have the camera move half the distance between it's position and the player position every frame. I've had no problems with that.
Finally, I had to deal with scene switching. I messed around with the SceneManager utility in Unity because it kept telling me that Appplication.LoadLevel was deprecated, but every time I searched for help online for my problems, people just kept saying to use Application.LoadLevel. So I ignored my issues with that yellow line under my code and moved forward. The way Application.LoadLevel works means that I have to pick and choose which gameObjects to save between scenes. At this time, I save the player, the camera, and the character that's been selected for dialogue (more on this later). Then I also have some variables exposed so that when the player and camera pop into the next scene they can be put in the right position. This creates a weird popping effect from a frame or two that I plan on fixing in polish. All this adds up so that the player can hit a collider with the sceneLink script attached and be transported to the next scene. That's pretty much it for the moving around. Next up: dialogue.
For the dialogue, I had less of a clear idea of how to do it. So I researched on how to do it. Basically what I found was a bunch of these dialogue modules you could download from the Unity asset store, all of which I would've probably had to modify further for it to work the way I wanted. I'll keep my fifteen bucks, thank you very much. Some of my classmates were also implementing dialogue so I took a peak at what they were up to. Most of their systems were a little bit more involved than I needed because their emphasis was conveying plot points through dialogue. I just needed a simple system where the player an character could exchange one line at a time for a short conversation.
Basically I just settled on brute forcing it. I got a sprite, attached a canvas in world space to it, and gave it a trigger so that it would only appear when the player was colliding with it. The player can leave anytime they choose. In actually creating dialogue, I made two prefabs: one button for the player's options and a text box for the response. At any time in a conversation, the player will only have two options. Once an option is clicked it hides the buttons and presents the response using Unity's EventSystem. Next, I made a a script that basically handles moving from a character response to presenting the next two options since there isn't an easy way to tie it in to the EventSystem that I know of. This whole construction means that I have to write the text into Unity UI objects (which sucks) and also have to manually link options to responses and responses to options (which also sucks), but once again this works the way I want it to and I'm not writing dialogue on too big of a scale where it's going to take up a lot of my time.
The one big bug I had to deal with was one where when the player clicked on an option he would move towards that option and the canvas would disappear as he moved out of the trigger. I solved this by giving the dialogue character an additional two triggers over the buttons that become active when the canvas is active. Then when the player clicks while in dialogue, I check to see if I've hit the colliers with a raycast. If the player has clicked the button, they will not move. That was pretty much it for dialogue.
Finally, we arrive at the journaling aspect of the game. I thought that this was going to take the longest since I had absolutely no clue on how to write to an external file, but it turned out to be a breeze.
Basically, I just have a canvas attached to the camera in screen space that is set active whenever the player presses left ctrl. In this space there is a large text entry box, a word counter, a prompt, and directions on how to save the writing once players have written enough. Here's a screen shot.
This is a screenshot from where the game is as of the publishing of this update so you'll notice the visuals are quite a bit more progressed than if I had been thinking ahead and actually taken screenshots when this was all ugly default/programming art. But there really isn't a better way to describe it than to show it.
I was able to find an old build of the game that I forgot I had kept so here's a screenshot from the original gameplay prototype. Learned my lesson on creating and saving builds as well so there ya go. Now back to your regularly scheduled devlog.
The last part of this puzzle is writing the text to an external file. I use StreamWriter which is a nifty little tool included in the System.IO library of the C# library.
That pretty much does it for going through the gameplay. This log took a lot longer to complete than I originally thought because of life, general busy-ness, and common laziness, but it is done! I just turned in an audiovisual prototype last week and in four (short and terrifying) weeks the polished product in all its glory will be waiting for all to download and play. So thanks for reading and hopefully I'll have a log explaining the early audiovisual work up before those four weeks are up.
See ya!
P. S. Here's the massive list of everything I got done with this prototype:
Hello! I've been sitting on this update for a while because generally I like to spend my time making the dang game instead of writing about it. But writing about it is important because it helps me reflect on what I've learned and focus on what needs to get done. The irony of not wanting to write about a game about making you want to write is not lost on me. So here we are.
During this second prototype of the game I spent 3 weeks developing and iterating upon the audiovisual tapestry of the experience. Basically the goal at the end of those 3 weeks was to have at least one near complete area so that the mood could be set for the rest of the areas. This is what I ended up with.
I'm very happy with this initial mood setter. I'm not the most gifted artist and even with the simple aesthetic, it took a lot of work for me to make it look exactly the way I wanted. I came pretty close to what I envisioned. I knew from the start that the look would be minimalist and colorful. The term I had in my head was "flattened polygonal." You'll notice that there are no curves anywhere in the scene and that's on purpose. I didn't intentionally start off with that principle, but I tried putting a circular sun in the sky and everything just looked strange. So no curves.
Apart from the obvious environment/character art, I also did some work on redesigning the UI and fonts. The images below are of the journal menu and dialogue popups.
I'm happy with the way the buttons look. I added the slant in the dialogue buttons because even though I don't want curves, plain rectangles are getting sorta boring. The font I'm less happy with. I'm using Chremsel Serif by Daniel McShee from dafont.com . It's a fine font, but it has a few design things that I'm not happy with and it doesn't fully represent what I want to convey. The two big issues I have with it are that it's too curly/curvy and that the periods are too tiny. So I'll have to keep looking.
The other part of this prototype was creating an aural texture to the place. At first, I was completely against the idea of having music in the game, but when I put an atmospheric track in the background I decided that something felt missing and that some music put here and there would be good to break up the experience. So I made a 30 second track using Bosca Ceoil (thank you to Terry Cavanagh for the tool and Mark DeNardo for showing me around + advice). I decided to place the track (which you can listen to below) in at the moments where there are what I call "zoom outs." Most of the time, the camera is pretty close as you can tell from the dialogue screenshot, but in the screenshot at the top of this page the camera is zoomed out so that you can see the whole vista. I decided this was where the most appropriate place to put the music.
That's pretty much it for this prototype. I'll post the list of things from trello that I got done for it, but it's not completely representative of everything that was done because somethings are stuck in checklists that are still waiting to be finished. Basically I did all things on the list plus a bunch of prep work on the other scenes. Thanks for reading and I'm going to go edit the next devlog right now.
Hello! Just like the audiovisual prototype devlog , I've been sitting on this update for a while. The polished prototype was finished at the beginning of May and since then I've been working on the game, getting situated back in California, starting my summer job, and otherwise generally procrastinating on doing anything for this website. But here I am. I just pressed “publish" on the audiovisual devlog and I've edited and added to what I already had written in May. I've decided to include the build for this prototype not only for this prototype, but for all the prototypes. So check it out. and lemme know what you think. Back to the 'log.
In the polish prototype, I went from a loose collection of mechanics and art to making an actual, functional experience. From what I understand, the polish prototype could be called an alpha. There isn't a great way to separate the things I did for this prototype because there are just so many of them. It included finishing visuals/audio, creating a start screen, adding juice/feedback, adjusting some design some stuff based off of playtests, and fixing bugs. I'll run through those and post the list of smaller things at the bottom. Here we go.
First up is the audiovisual. Most of this included just maintaining the design principles I set for myself in the previous prototype. I also had to think more about the scope of the game. Ideally, I'd like a zoom out for each of the 5 scenes with accompanying music. What I ended up doing was one more zoom out and reusing the music. I definitely want to get some more music, but I'm still debating how many zoom outs I actually want to do. We'll see. Finally, I added some creek sound effects to the creek scene and some wind effects to the overlook scene. Oh boy- atmosphere! It was pretty much me just trying to grind out the art so I could focus more on the things that I really like doing.
Next was creating a start screen. From the initial conception of the game , I had this great idea for a start screen. It opens on a city block, with the title fading in. Once you click, the door of an apartment opens and you walk out the door. To the left is a brick wall with credits. If you walk to the right, the street gives way to green land, which then leads you the main game. I like this setup for a lot of reasons. It means the game doesn't being until you figure out how to move. The whole block is made of squares and you can only move in two directions which contrasts nicely with the main game where the shapes are more abstract and you can move in multiple directions.
For the juice/feedback portion of the game, I added a click feedback thing so there's a marker and a noise. The marker pulses! So satisfying! I also added a sound effect for when the player opens the journal. This part isn't that interesting to write about on a surface level because it's the kind of thing that should fade into the background of the experience. Of course there should be a click marker and different sfx for different buttons, but there's not much more to say than that they are things that exist now.
So anyway... I did a lot of playtesting! Mostly with other kids in class with me. Based on their feedback and just my own observations watching them, I added a couple things. I added a nice signpost as a visual indicator for a zoomout. There are also particle effects at the exits of all the scenes. I added some controls hints in the form of UI overlays. There are only two: one on the start screen that tells you to click the mouse and one whenever you do something that I think would prompt you to write. I need to change the frequency and the urgency of the second one because right now it feels like it pops up every friggin second. Finally, I lowered the word minimum and made the actual text box smaller to get rid of "blank paper anxiety."
So yeah. I did all those things. Plus more! I'll post a list at the bottom. Here's the link for the prototypes if you'd like to play them. I'm not going to publicize that they're here a lot, but you can play 'em if you want. I've been working (ever more slowly since my summer job started) on creating a build that acutally has everything I want so that'll be the build I publicize, but for now this'll be a fun way to put it out. Check them out! This'll probably be the last devlog until I have the complete version done so keep it cool til then.
Play now!
About
I Dream of @dril is an exploration into the psyche of a man who may not even exist but makes really, really funny tweets. We have translated those tweets into digital physical form, so that we may all experience @dril's truth in all of its glory. You finally get to experience first hand what we can only assume is Twitter's most popular funnyman.
I Dream of @dril was originally made as part of Robert Yang's Intermediate to Game Development class in Spring of 2017 at NYU with Simon Pettigrew, Gabe Rush, and Molly Weaver. I did a lot of the programming an level design of the game, but also contributed to the models.
About
This is a game about my experience being injured as a runner and the sort of cyclical hell that comes out of that. The idea behind the mechanic was that the more you run the more your body would fall apart.
A Game About Injury was originally made as part of Robert Yang's Intermediate to Game Development class in Spring of 2017 at NYU.
The biggest problem for me during the development was finding the right mechanical way to express my experience. I started off with a complicated physics thing that didn't really work and then moved to a more simple to button system. At first it was more rhythmic which I felt was more true to what running feels like, but didn't feel good to use. The system I settled on is just button mashing, which feels really good and gets the point of the injury across.
If I had more time, I think I would try to put some more time into the art and make it look a bit more coherent. The high poly hair and low poly environment/body doesn't really match, but I'm ok with it since I'm just learning how to model. Overall, I'm pretty happy with how this turned out.
Press
Rock Paper Shotgun : "Yes, these are small games, but they’re a snapshot of young designers thinking about setting, mechanics, atmosphere, control, UI and storytelling."
Technically Brooklyn : "The games are thoughtful, and, divorced from sales pressures, deeply personal, showing games as a form of self-expression."
Screenshots