B EN H ADERLE

Hi. I'm a game designer and programmer from Northern California.

Currently, I work as a Unity developer at Create Neptune. I graduated from NYU in 2019 with a BFA in Game Design and a BA in Computer Science and from USC in 2021 with an MS in Computer Science with a specialization in Game Development.

I mostly work in Unity, but I have made projects from scratch in C++ and Java and using Unreal, Godot, Pico-8, and Processing.

I am most interested in using computers for humans and making interesting textures of play.

Apart from games, I ran cross country and track for 11 years. I enjoy backpacking and being outdoors.

If you want to chat, here's my email.

Please peruse my projects below or head on over to my itch page.

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 :)

Get it on Google Play

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

Prototypes

These are two videos made from assignments done in my animation programming class at USC.

Motion Capture Interpolation

The first one is from an assignment where the objective was to showcase different methods of interpolation between frames sampled from a mocap animation sequnce. The three methods I built were a bezier euler interpolation, a linear quaternion interpolation, and a bezier quaternion interpolation. That is also the order in which they produce best results as compared to base mocap sample. I use a sample rate of 40 frames so you can see some hiccups where the fixed sample rate can't keep up with the amount of movement happening in the mocap. I would need to build out a way to have a variable sample rate to accurately capture sequences of high movement while not "over-sampling" sequences of low movement in order to gain accurracy while keeping the sampled data small.

IK Solver with Skinning

The second one is from an assignment where we were given a model and skeleton and were asked to apply skinning transformations and write an IK solver for moving handles located at the feet and hands. I implemented linear skinning which results in some unwanted deformation in the chest of the model in the video; this could likely be improved by implementing a dual quaternion method. The IK solver is a damped least squares implemenation.

About

The idea behind this game was to make a freeform, easy to use block placement thing. The size of a block is just determined by how far away the player is looking when they place it. After building out that interaction and the player movement, I made the materials for the blocks and the ground using Aseprite. I like the idea of placing all these concrete-metallic blocks out in the desert. After, I borrowed some scripts I had from other projects to do some visual effects like the skybox, layered fog, and block shader. I messed around with the colors for a while, and eventually had to settle. It doesn't feel quite the way I would like it to feel. Finally, I made some sound effects using bfxr, but I don' think they feel like the right tone either.

It loosely falls into line with a couple prototypes I've made when think about city builders and urban planning. I'm trying to think more about "mistakes" in city planning and how they organically exist in an urban environment.

About

This was a project made by Molly Weaver and I for Robert Yangs Level Design Studio class in Spring 2019. We made a short platforming game through a level inspired by the Altes Museum in Berlin.

In the Museum level Molly and I made, there's a small hub and spoke design. The player starts in the hub and must explore the east-west spokes in so that they can unlock the last spoke. In the each of the east-west spokes, there's a key that moves stairs in the dome room when collected, allowing the player to get to the end. In order to get to the first key, players have to jump across a gallery area bounded by crates to get to another room. There, they are blocked in by crates on wheels, which they do not yet have the ability to push. So they have no option but to climb the tower of crates where they can find a glove that gives them the power to push crates. The they can push the crates to get the first key and then return to the hub. Once at the hub they can push some crates to get the second spoke and make their way to the second room by pushing more crates. In order to get the second key, they have to push a box into a certain position in order to over come a wall of crates. Once they have the second key, the player can go back to the hub, climb up the dome, and enter the ending area.

For me, the process began with playing through Molly's gray box and thinking about what models we would need and how we could rearrange the layout a bit. Something that was helpful to me in thinking about the layout was how we could separate spaces using some of the ideas from ch 5 of Form, Space, and Order. We added more orthogonal planes using either explicit walls or using glass to help separate sections out. I made the crates, floor, walls, and display cases in Maya. I actually enjoyed modeling that stuff a lot more than I had enjoyed modeling before. After playtesting, we realized that we needed a better sense of direction and a better sense of cause and effect. For the direction, we added more vertical areas, so the player can climb up and see areas that they might want to go to and that we've lit specially. For the cause and effect we tried our best to put the first key more in front of the door it effects and moved the glove into an area that you can't get out of without pushing a box.

About

This was a greybox I made in UE4 for Robert Yang's Level Design Studio in Spring 2019. I based my greybox off the Armory Track in NYC. I tried to show the multiple lives of the building, first as an armory, then a track, then a homeless shelter, and finally a track once again, but I don't think that I treated the history with the reverence that it needs. Still good practice for laying out the space. Below is a playthrough w commentary and a slide show I gave on the process.

About

This spring, I'm taking Bennett Foddy's Pixel Prototype Studio class at the NYU Gamecenter. We use PICO-8 to make one prototype a week, due every sunday at midnight. I'm going to try my best to post them as I make them. Enjoy!

Week 13 - Threeble

Of course, my last prototype was the one that's completely broken. The prompt this week was to make a game that would make 1 million dollars. So I thought about what kinds of genres were popular on mobile and decided to try and combine a match 3 game with a word game. So basically it's a match 3 where you're trying to make 3 letter words. The reason it doesn't work on a technical level is because I tried to get fancy with how I structured my table of letters and my dictionary (Lua/PICO-8 has no built in dictionary feature). I ended up breaking some stuff and not having enough time to fix it. So I guess that goes to show you that time tested lesson, just because you take one algorithms class doesn't mean you can try be fancy in a week. On a design level, I think this idea also needs changes. For one, I took the list of vaild 3 letter words in Scrabble and used that as my check. However, that list is really lenient and really long (~1200 words). It could definetely be shortened which would help with the next problem which is board generation. One problem that I ran into was that every board I generated had a lot of words already in it. My generation was an inverse function of how many points each letter was worth in Scrabble, but I think I would have to do some more analysis on the valid list of words to determine what the best generation algorithm would be. I still think this is a good idea, it just sucks that I couldn't get it to work on time.

Week 12 - Ladders

This week's prompt was to steal an idea from one of our classmate's previous games. I took an idea from Gabe Rush. He had a game a couple weeks ago that was a little unfinished, but the general idea I got was a ladder climbing game. I started off trying to make an infinte ladder climbing game with similar climbing mechanics to the ones found in Crazy Climber, the 1980 arcade game . I quickly abandoned that idea thoug beause PICO-8 doesn't really have the graphical or control fidelity to make a system like that. So I made the simpler cimbing system that's in the game now with the addition of the jump mechanic in order to overcome the occasinal lack of options stemming from procedurally generating the ladders. Overall, I'm pretty happy with how this prototype came out. It seems like it has some potential to be developed into a nice, classicly-styled arcade game.

Week 11 - Blue

This week's prompt was blue. That's it. We actually voted on the prompt after each submitting one and we ended up with blue. You can read about that absurd voting process here. Anyway, I ended up making a game inspired by Threes. Instead of mixing numbers to get a high multiple, in my game, you mix colors to make the whole board blue. The whole thing with this was that it kinda opned a whole can of worms. Color mixing/color theory just isn't that intuitive to us and it made it hard to think ahead about solutions to the puzzles. I don't know if it's just a matter of giving players a long onramp to internalize the rules or if it's just something that our brain is bad at doing. After making this I think it would be pretty hard to devise a ruleset around mixing colors that is easy to teach players to internalize and use effectively. All in all, good experiment, but it ended up jsut opening a whole can of worms. Maybe one day I'll take down that can, worm by worm.

Week 10 - Plane

This week's prompt was to make a one button game. Feeling a little devoid of ideas/creative energy after my exhausting city builder week, I looked through some old prototypes I had made to try and think if one of them could be fitted to be a good one button game. I came across a clone of Luftrausers I did for class last semester and thought I could make a good version of the controls using only one button. So in my game, you play as a pilot who's plane is falling and spinning. You have a limited amoutn of fuel and the goal is to slow down before you crash into the waters below. The spinning happens automatically and you can use the up button to lock rotation and boost in that direction. Once you let go, you continue spinning. This game isn't too fun on it's own. It turns out when you just have control over the boost of a Luftrausers plane, it takes away a lot of what feels good in that game. I could see this being a good interlude in some other, bigger game about flying a plane. To be honest, after the intensity of last week, I was also erring on the side of picking an easyish project for a break. Coding parallax clouds was nice and relaxing after being locked on the grid.

Week 9 - City

This week's prompt was based off random retro videogame boxart that we were given with the title removed. Mine was this:

Naturally I decided to make a city builder. There were a couple reasons for my choosing this. First, after last week I was feeling kind of burnt out on making games really focused on gameplay and interaction mechanics and wanted to try something new. I've never really made a simulation type game and typically don't make numbers heavy games even though I enjoy playing them. So making a city building sim seemed like a great way to try something completely new. Second, I am from the Bay Area and try to keep up with the ongoing housing crisis going on there. Bay Area rents are the only US rents that make New York look reasonable. I've been reading a lot about on how the construction of houses cannot keep up with the rate at which new jobs are added in the Bay. So, I decided I wanted to make a small scale city builder that focused on the dynamic between adding jobs, adding housing, and maintaining transportation infrastructure. Sounds easy for a week, right? Turns out that's a lot of work especially if you've never built a sim game before and are trying to make it in a 2d game engine. So this week was the first week I undoubtedly overscoped. I spent a lot of my time this week just building the technical infrastructure around placing buildings, rendering them correctly, and making stats go up. I really enjoyed working on that stuff amd learned a lot. I would start off completely different next time. Unfortunately, this left me with no time to balance or test the systems I had devised or define a lose state. The game is basically a grpahical clicker at this point.

The good thing is that I still think this idea has a lot of potential. The bad thing is that I think any potential version of it would need a larger development team than just me or even me and a couple friends. There's a lot to be done in the city building genre and to be completely honest I'm a little surprised that there aren't more projects in development. Maybe I just haven't hear of them? A politically conscious city builder would definitely be an ambitious project and I hope I get the chance to work on that in the future.

Week 8 - Dad?

To be completely honest I don't have a lot to say about this week. The prompt was to make a game about our worst nightmare. Because I'm an obsessed fanboy, I thought about David Lynch's Eraserhead and my own fear of being a father. Not exactly a nightmare, but close. I don't really excel at narrative things so I tried to think of a way to represent that fear via mechanic. Along the way there, I was also thinking about a recurring nightmare I have where I'm the foreman of a factory and all my workers are ant sized people. They start getting mad at me and yelling before they all crawl on me and their weight takes me down. This nightmare + my fear of being a father + the wish to represent those thigns mechanically congealed into what the game is. The result does not capture the fear of either of those things- in fact it's kind of cute. But I guess I just think this prototype is kind of boring. I could reuse the mechanic somehow and complicate it in some way, but I think I'm willing to just drop this entirely. Ironically for a game about my worst nightmare, I feel like I stuck too close to my genre comfort zone this week and I want to take more risks in the next few weeks.

Week 7 - Depart

I'm back after a week break! This week our prompt was to make a game based off of one of three songs that Bennett made for us. I'm not going to try to describe the songs here, but you can here the one I picked in the game for this week. The song made think of the melancholy of leaving home and that's what started my thinking. I was also thinking about taking spring break off and spring coming in general, so I kind of combined those two ideas into one. My idea was for a game that was about preparing your igloo for spring. Originally I was going to make it about building a shell of sticks and mud and stuff around it so that it would stay up, but then I thought it would be cleaner + cooler if the igloo was on a glacier and you had build a boat because everything was melting. I then thought about what materials there would be to build a boat that could be found on a glacier and I guessed there might be a couple large fish bones lying around on this particular glacier. So basically the game is about collecting the bones of dead animals before your glacier melts and you have no home. I didn't realize how dour this was until I showed it until my girlfriend pointed it out to me.

The biggest thing I was trying to test was the boat creation. I wanted players to have freedom and ownership over the design of the boat and I think it works well in that regard. To be completely honest, this was kind of a low productivity week for me and there's a lot of polish and little things that I wish I could have done. The prototype is very barebones. If I were to flesh this out further, I would fix those little things and also focus on making collecting the bones more fun. I do think that I did a better job focusing my prototype this week.

Week 6 - Fish Fillet

This week our prompt was "food". Inititally, I wanted to make a game about stories my parents had told me about their experiences in culinary school. Specifically, the stories that came to mind were the ones about getting up at dawn to trudge through snow and go cut fish in a walk-in fridge or bake bread and get yelled at by the teacher. At first I thought I was going to attempt making a narrative style game with light conversation mechanics and the like, but I don't really enjoy making those types of games since they are typically art and writing heavy, both of which are not my strong suits. So I tried to come up with a way to represent the feeling of learning a new skill and getting a negative reaction mechanically. That's how I came to cutting fish. I think my representation is only partly succesful. For one, there isn't a lot of room for different skill levels; it's kind of an easy task. Two, I feel like there's a more accurate way to represent the sensation of cutting fish; mine doesn't feel as close to 1-to-1 as I'd want it to be. Three, there are some techincal bugs with the way I process button inputs and the system is really easy to cheat. I do like the way the fish moves as you cut it and I do like how no matter how well you cut the fish, you always get a negative reaction. That shows the player that their opinion matters more than whoever is giving critique. I wish that the game was a more complete experience. One of my classmates commented that they wished there was a scene after the fillet where the character walked back across the snow so that the game was cyclical and I think that's a pretty good idea. It would also make it structurally similar to my game A Game About Injury . The two are already pretty similar in message. Overall, I don't think this idea is crap, it just needs a lot of reworking and expansion. I wish I'd had more time to work this week, but I've been traveling for track the past couple weekends and felt a little burnt out.

On a related note to burning out, I feel like the past two weeks have been less focused prototypes than my first original week. I'm going to try to be more focused in my goal next week.

Week 5 - Lost?

This week we had Monday off for Presidents' Day, so Bennett delivered our prompt in the form of a ruthless cryptic, but fair game with a puzzle to solve. You can play it here! Anyway, the theme ended up being "lost or confused", so I made a game about drawing maps. The idea for a game is this: you're the first person on an island and you have to map it out. The problem is that you have limited time and limited space to complete your representation. I was interested in seeing how people would choose which details were important to preserve and how they would draw a space that isn't necessarily in proportion to the canvas they're drawing on. Tech-wise, the game isn't that complex. A player can walk around a 3x3 island for 2 minutes and at any time they can open up their map and draw with the mouse. After time is up, they are given a score on how accurate the map is. There was a little finagling to get PICO-8 to recognize the mouse, but it wasn't that hard. To do the check for accuracy on the map, I just drew my own version and check against it tile by tile when time is up. It's not an ideal check, but I think that it gets the point across for the scope of the prototype. Ultimately, I like the map drawing and exploring mechanics, but I dislike the context of being under very short time pressure and being graded on accuracy with a number. I think those machanics would be cooler if put in a game where the player/other players/NPCs had to use the maps you drew for some function. It was a useful experiment with the idea.

Week 4 - ZXC Skiing

This week the first week of making a game from scratch from a theme. The theme this week was "Olympic Games". Since I'm ski obssessed, I made another skiing game this week. The difference is that this week I made a cross country skiing game rather than a downhill skiing game. My goal was to try to represent the act of cross country skiing in a tactile mechanic. Therefore there are two actions you can take as the character: move your legs back and forth and lift each heel up. The internal movements of those two things affect how the character as a whole moves. The hardest part of this week was tuning that interaction just so. Overall, I think it's a good representation of what it actually feels like to cross country ski. If you just shuffle your legs, you will move backwards! I also like how because of the way the character velocity is set up, it's actually easier to go faster backwards rather than forwards. If you pass through a certain number of screens it will save your time and restart. I like the pause after you finish where you just have to watch the silent snow fall on the trees. I'm pretty happy with the way this turned out.

Week 3 - Horace Goes Skiing

This week our assignment was to clone one game from another list of 70s and 80s arcade/PC games. I chose Horace Goes Skiing by William Tang and Beam Software released in 1982 for the ZX Spectrum, Commodore 64, and Dragon 32. Play the original here! There wasn't anything particularly challenging to program in Horace, rather the scope was pretty large for a week and 1982. The game begins in a Frogger-clone where the player has to navigate across the street to the ski shop and before they can actually go skiing. The original game actually has a fairly good car AI so that faster cars can manuever through traffic so I did a rough implementation of that which mostly works. I had to learn how to check for collision with all the procedurally generated cars and all the obstacles in the skiing portion. The skiing mechanics definitely could use more work in order to feel more like the original. Currently, it's just not that fun to ski. Overall, development went well, but programming the basic functionality and doing the neccessary sprites took so long that it kind of burnt me out and I didn't have motivation time to do music. However, I think it succeeds in being a functional clone of the original Horace Goes Skiing .

As a side note, I did read a little more about William Tang (the creator of Horace), but couldn't seem to find where he is/what he's up to nowadays. I would love some closure to that so please reach out if you can find anything....

Week 2 - Arcade Volleyball

This week our assignment was to clone one game from a list of 70s and 80s arcade/PC games. I chose Arcade Volleyball by Rhett Anderson released in 1988 for the Commodore 64. Play the original here! The hardest aspect of this was writing collision and tuning player speed and ball speed to match the original. My collision is still a little off, but it didn't take that long to write because it's hardcoded, not a system. It's just such a simple game that it didn't really need it. I learned how to do a basic collision system and 2 player input in PICO-8 and made a faithful clone of Arcade Volleyball .

Week 1 - Desert

This week our assignment was to make significant modifications to one of four prototypes Bennett provided for us. The goal was just to get familiar with PICO-8. I chose a narrative, western themed game and made it a resource management survival game. I was trying to see if I could represent my experience hiking through the desert in Southern California. I think it was fairly successful. I learned the basic ins and outs of PICO-8 and successfully tested a design idea.

About

Hook Climbin is a 2D action game about climbing a tower using a grappling hook.

It was prototype as an assignment for Gabe Cuzillo's Action Game Studio in Fall of 2017 at NYU.

Hook Climbin' really only came together in the last couple days of development. It started off as a stealth game about grappling above your enemies and suprising them. The grappling hook felt really bad and to build everything else would have been outside the scope of the assignment, so I decided to focus on just trying to make the grappling feel good. That turned aout to be a hard problem to solve. I kept looking at the game Floating Point and trying to reverse engineeer the physics of it. I tried a lot of things, most of which were very messy, but ended up with a realtively clean implementation. My implementation also allowed me to make the grappling rope elastic which greatly improved how the game feels. After I was satisfied with how the mechanic funtioned, I made a simple level to show off how it could be used. With this game, I think that it mostly needs a lot of level design work to explore the mechanic further.

Screenshots

About

Expander is an arcade game where you try to capture weak enemies in your blast radius to set off an explosion that can destroy stronger enemies.

It was made over a couple weeks as part of an assignment for Gabe Cuzillo's Action Game Studio in Fall of 2017 at NYU.

I made Expander out of my desire to create an arcade game with a unique mechanic. In the past year, I got really into playing obscure 70s and 80s arcade games and I wanted to make a game in that style. Many of them have unique mechanics comapred to games from today since genres weren't as strictly defined then. I think I succeeded on the unique mechanic front and overall, this prototype is a solid base. If I were to continue with this project, I'd want to find a way to scale difficulty better, probably by adding different enemies besisides the "popcorn" chasers and the strong bases.

Screenshots

About

Luftcloners is an attempt to clone the movement of Vlambeer's Luftrausers .

I originally made it as part of an assignment for Gabe Cuzillo's Action Game Studio in Fall of 2017 at NYU.

Luftrausers was an interesting game to clone because when you're not trying to disect how the movement works it feels very intuitive. However, once you start looking deeper, parts of it actually function in an unintuitive way. Rotation and thrust work the way the you would expect them to. The effect of turning the plane is just an effect. The camera was the trickiest part. It takes into account the velocity, position, and direction of the ship. I had to observe all three of those things and balance out how they affected the camera in order to accurately mimic the game.

Screenshots

About

Planet Jumper is a prototype, gravity based 2D platformer.

Felix Szczesny did the art and I did the programming. We made this at the June 2017 Berlin Mini Game Jam. The jam was 7 hours long and our prompt was "the sun is too hot".

Planet Jumper works as a proof of concept for a game that could be made. Clearly there would be a lot to be done before this could be fully featured. Just to begin with, the physics needs to be tuned to me more forgiving and communicable. Beyond that some twists on the main mechanic would have to eb introduced before you could make a reasonably sized game out of this. I'm happy with the work Felix and I did in 7 hours.

Screenshots

About

Rainbow Run is an infinite runner where you must match each platform's color in order to survive.

It was made over a couple weeks as part of an assignment for AP Thomson's Procedural Generation for Games class in Spring of 2017 at NYU.

The mechanic for Rainbow Run came to be by accident. I needed a way to know if the platforms were spawning while the player was moving. I was too lazy to get a background so I just randomized the platform color. From there, I decided it would be cool to try and match the color. I think that more mechanic is pretty strong, this game just needs some more refinement and additions. The level generator is based on how many colors the player has. After each gate which gives a new color, there is an array of premade level chunks that are randomly put down before the next gate. Additionally the color of the platforms are generated such that a jump will always force the player to change color while a solid stretch will never change. I would like to refine the chunks I already have, make new chunks, and change the level generation after the player has all the colors so it stil gets more difficult. I also want to redo jumping physics, add a bunch of juice, and add things like pickups that would add a multiplier to your score. I envision this as a mobile game, as most infinte runners are.

Screenshots

About

Achiever is an arcade style game where you attempt to eliminate all the enemies as fast as possible.

This is one of the first games I made and the first one that I can still run on a computer. It was originally made as part of Charles George's Introduction to Game Programming class in Fall of 2015 at NYU. Uunlike many of my other games, Achiever was made using Processing rather than Unity.

There are a lot of things that I dislike/are incomplete in the game. The font and colors are all pretty bad. Just the whole idea of getting a low score is unintuitive. The controls need work, the enemy AI is uninteresting, and there is a lack of audiovisual communication for anything. There are some salvageable pieces of it though. I like that all bullets are treated the same, whether they're shot from the player or an enemy. I also like the simplicity of the single screen experience.

If I went back to Achiever I would probably start by making the enemies more interesting since their behavior would strongly influence which direction the game would take. I would like it to stay close in spirit to the arcade games of the 70s and early 80s. From there, I could fix player movement, juice the game up, clear up how the goal is communicated, and maybe design more levels.

All in all, I think that this could be a fun little game, maybe for the PICO-8 or something similar.

Screenshots