You’re tearing me apart: A 4 year Ludum Dare postmortem

I don’t write these often (in fact, I’ve only ever written one, about three and a half years ago). But, Ludum Dare 37 marks my fourth year without missing a single jam, and it’s been a wild ride.

Lets consider this a mega-postmortem.

Some Background

On December 16th, 2012, I submitted my first ever Ludum Dare game, Sammich-Napper. I was only 15 years old, and this was the first time I had ever made games in the public eye. I’d been messing around with little side projects here and there for about a year or so beforehand, but nothing ever publicly available.

Sammich-Napper, my first ever Ludum Dare submission

It wasn’t pretty, it was a boring platformer, and it was probably buggy. But, I made it.

There are aspects of Sammich-Napper I’m still proud of today, like the glass shattering effect, and the unique main menu level. Plus, it laid the groundwork for my next Ludum Dare submission, Fog, which went on to win the 2013 National STEM Video Game Design Challenge.

After Fog, long-time friend and talented artist, Pamela, and I worked together on many Ludum Dare submissions. We also began working with really talented musicians and game audio people in the community.

Our submissions started placing top 50, top 10, and even top 3 in many categories in the case of OMNI, possibly our most popular submission to date.

OMNI, our very popular submission for LD31.

The past year

In 2015 I graduated from high school, and enrolled in a collegiate game design program. I kept up my Ludum Dare streak while in college, met some awesome people (including my teammate, roommate, and best friend, Aidan), and made some really great projects. But, I started losing the motivation, passion, and pride in my work that I had always felt. I was living my dream career, but I wasn’t terribly happy about it, and I couldn’t figure out why.

In the spring of 2016, I submitted my first failed LD game, Clothes. A lot of things went wrong, and the submission was reviewed worse than nearly any of my other submissions had been before. This was a strong final blow to me, having already really lost my passion.

After wrapping up my first year of university, I spent a lot of time trying to figure out why I wasn’t passionate about games anymore. That was the beginning of a much longer journey, which led to the start of my first long-term project, Noah and The Quest to Turn on The Light

The Light has taken me to a lot of awesome places, and unlocked a lot of doors, but that’s a discussion for another post (I’ve covered this a bit on my personal blog).

Fresh from the cathartic exercise in design that The Light has been for me, and at the start of my second year in uni, I hit Ludum Dare 36 with full force. Working with my roommate, as well as talented musician, Joshua McLean, we made an awesome four-person party game, Bro-Mag Arena. I couldn’t have been more proud of this project. I had more energy and passion then than ever.

Ludum Dare 37

Ludum Dare 37 marks my fourth year without missing a single jam. Not only that, but it was timed very well with a lot of personal and professional development over the past year. As such, I wanted to really test my skills, and join the compo for the first time in a long time, to see how far I’ve come. As it turns out, I’ve come very far.

You’re tearing me apart is a game inspired by the American classic film, The Room. In the game, you play as the character Johnny, a distraught lover caught in a fit of rage over apparent betrayal from everyone around him. In the film, Johnny tears apart the living room of his apartment in his anger, much like his lover and friends had torn him apart.

What went right?

Everything, really. This is the first time I’d ever done 3D artwork for myself in a jam game, and I was really pleased I was able to flex that new skillset.

I have a habit of scoping my jam projects such that I have *just* enough time to finish everything I’d like to, assuming I work nonstop the entire weekend, sleep 4-6 hours a night, and run into no issues. That trifecta rarely worked out, and I often found myself finishing the jam, but very burnt out, and less pleased with the final result than I should have been. This jam, I really tried to focus on keeping the scope really tight, and leaving room to experiment, polish, and enjoy the jam. Most of Sunday was spent playing around with the scoring system, making a pretty page, and recording foley/VO (something I’ve always wanted to do, but never had the time for). By the end of the jam, not only was I super happy with the product, but I was happy with the weekend, and ready to face the world (and finals week) on Monday.

What went wrong?

I’m not good at foley (yet!). I’m hoping I can dedicate more time in the future to gaining an intuition about what combination of sounds produces what effect.

Future plans?

I’d like to spend some time polishing up You’re tearing me apart. It’s a really nice little piece, and there’s definitely room for improvement. Perhaps I’ll spend some time working on it during The Room Jam. I’d like to add more stuff to the room, as well as play with the scoring mechanism a bit.

It’d also be neat to have a few more callbacks to the movie in the game, other than just the VO, and the file cabinet drawer full of roses.

Ludum Dare in 2017

The past four years have really been amazing. This year, I gave talks across the country on a game I wouldn’t have started without Ludum Dare, and I’ve made great connections with amazing people through that.

Next month, I start a full time job working as a game designer on a research project at my university, as well as a part time position on a research project with game designer, Global Game Jam co-founder, and professor Ian Schreiber. Without my Ludum Dare projects, I wouldn’t have gotten either of these jobs. Those projects make up the large majority of my portfolio. Plus, being able to say that I can make a game from scratch in less than 48 hours, and still want to do it again in 3 months is a pretty large leg up in interviews.

I’m not stopping anytime soon with Ludum Dare. I’m really curious to see how high this year counter can go!

Happy jamming in 2017.


This is a lightly edited copy of a post I wrote on my blog for the Ludum Dare game jam website. You can find the original post here.

GDEX, GDC, and the Importance of Networking

The most crucial tool for anyone trying to get a job in the games industry is their network. As a games student, networking is especially important, as you have little to no industry experience to pad your resume. More often than not, the only way to land that first games job is through someone you know in the games industry. Although there are many ways to make industry connections, there’s really nothing that builds your professional network faster than games conferences.

This past weekend I had the opportunity to show my current passion project at the Game Developers Expo (GDEX) in Columbus, Ohio. This is the second major games expo I’ve attended, after going to the Game Developers Conference (GDC) in San Francisco, California earlier this year. In this post, I’ll be comparing and contrasting the experiences of attending a games conference, and showing a project at an expo.

I’d like to first acknowledge some differences between GDEX and GDC. GDEX is a locally organized event that showcases regional game developers, and is open to the general public. Attendance at GDEX is generally in the thousands, making it a small to mid-sized event. GDC is an industry organized event aimed mainly at professional development and networking, and has attendance in the tens of thousands. Although the expo floor is open to the general public for part of the conference, tickets are fairly heavily sought after, and are also somewhat prohibitively expensive. As a result, the average attendee at GDC is generally more industry-oriented than the average attendee at GDEX.

GDC, being the largest conference in the games industry, and my first ever conference, was quite daunting. However, all the networking I managed to do on and off the expo floor was astonishing. I handed out and received many business cards, had lots of awesome lunches, and made many connections I was able to follow up on after the conference, keeping in touch throughout the rest of the year. Those connections have, and will, come in especially handy when it comes to moving my career forward. One big constant at GDC (as well as many other industry conferences) is the parties. These events, while fun, are also huge for networking opportunities, as they provide an opportunity to converse in a more casual setting. However, many of these events are also fairly exclusive, and being a first time GDCer, it felt like I was often out of the loop. Luckily, those connections I made at the last GDC will come in handy for keeping me in the know on further networking opportunities.

GDEX was a lot smaller than GDC, but that’s not to say the networking was any less impactful. I should include a disclaimer about GDEX: as I wrote in my last post, one of the most helpful things for me when it came to networking at GDC was the connections I already had established via my involvement in various online communities. I am lucky enough that GDEX is organized by the local game developers group in my home city of Columbus, so I was on a first name basis with not only the organizers, but many of the other developers exhibiting that weekend. Having this network coming into the expo opened many opportunities for me that I would not have otherwise had. This just highlights how incredibly important networking really is in our industry.

Showing a game at an expo is a lot different from attending an expo. For one, I found myself locked to my booth nearly the whole weekend. As much as I wanted to peruse the expo floor and talk with other developers, I just didn’t have the time to, with a near constant stream of attendees at my booth. But, that doesn’t mean I didn’t find a way to network. Although GDEX had a lower percentage of industry-oriented attendees when compared to GDC, there still were many professionals in attendance. As an exhibitor, these professionals found their way to me, and I was able to show them directly what I was working on. I was able to exchange cards with many people who were clearly interested in my work, and I even made a couple contacts that could aide in getting my game into other showcases. As a whole, I’d say that due to the smaller and more intimate nature of GDEX, although I made less new contacts overall, the connections I made were deeper and more meaningful than those made at GDC. Additionally, I was able to catch up with local developer friends, and show them what I’ve been working on. I even ran into a friend whom I had last seen at GDC!

The two experiences, although different, have many similarities, as well as many individual perks. GDC was great for blanket networking, and building my network very rapidly, which provides a great entry point for deeper networking outside the expo, and at the next conference. Showing my game at GDEX allowed me to make more intimate connections, as I was able to spend more time showing my work to–and talking one on one with–professionals in the industry, especially those who will be able to directly advance my career or at least my game. I believe that attending as many local conferences and expos as possible do nothing but good for your career, as they at least provide practice for GDC, and might even yield connections that will have great impact on your career moving forward.

Note: This is a lightly edited duplicate of a blog post I wrote for the RIT Interactive Games and Media student blog. If you’d like to read the original, you can find it here.

Big changes and betas

After the last update, I started working in a prototype of  The Light, returned to university, and pitched the idea at a couple game dev meetups. After getting back to school, progress on the game stagnated, but I kept talking about it. Every time I talked about it at a meetup, someone would ask how I planned to end it. I didn’t have an answer. This wasn’t something that worried me too much, as I figured I would come to how I wanted the game to end eventually.

After putting the game on the back burner to focus on school for a bit, I came back to it and realized there were a lot of things wrong with the prototype. For one, the transition between canvases and the dark worlds wasn’t very intuitive, and it seemed to break the flow of the game. The idea had originally been that the dark worlds and puzzles were just content to keep the player engaged and interested in the game, but they were ultimately distracting. Additionally, I the mechanics of the dark worlds had started distracting me as well. I spent more time iterating on mechanics in the dark worlds than I spent working on the parts of the game that really mattered to the narrative. In fact, those parts were largely unimplemented.


So, I pivoted. I dropped the dark worlds and instead moved their simple terminal based puzzles to the canvases in the gallery. Observers still stand next to completed pieces and pass judgement on them as the player progresses, and the player still works to unlock wings of the gallery by solving puzzles. The game became a uniform experience that takes place in one room. I also developed a narrative arch for the experience.

The pivotal moment for the player is given the option to seal back off a wing after they have entered it, blocking observers from entering and passing their harsh judgement. If the player sealed the wing, they are presented with two options upon completing the wing: open the door, or exit the game (exit remains an option regardless of the state of the door). The player has the option to allow the observers to return and pass whatever judgement they may, or just exit the game satisfied that they completed the puzzles.

After making these changes to my design, I prepared another prototype for a local meetup and held the first playtest. I also collected emails for a closed alpha group. Over the past month, I’ve been working with the alpha group through to get a build ready for the Game Developer’s Expo (GDEX). The game has really come a long way from it’s inception nearly 5 months ago.

This past weekend, at GDEX, I ran the first public build of Noah and The Quest to Turn on The Light Beta. (More on that soon!)

During the beta, this blog will see more updates with insights into development on the project, so be sure to keep up to date!


Game Jams 101

Earlier this year a peer and great friend of mine, Joshua Landman, wrote an awesome blog post on passion projects. I absolutely agree with him in that working on projects outside of class-assigned work is incredibly important as a games student. Not only do personal projects look great to employers, they also provide the opportunity to experiment and develop your skills. But, taking on a long-term passion project is daunting, and there’s many barriers to starting. What do I want to make? Where can I find a team? What skills can I bring to the team? Game jams provide the answer to all of the above.

What is a game jam?

If a long-term passion project is a marathon, game jams are the 100m dash. Game jams are events in which game designers, developers, musicians, and artists work together or alone to develop a game based on a theme in a short span of time. The game jam ecosystem is incredibly diverse, but most jams follow this rough format:

  1. Participants get together either in person or online (depending on the jam), and spend some time getting to know each other.
  2. At a pre-announced time, a theme for the game jam is announced. Games made for the jam should revolve around the theme in some way. Upon announcement of the theme, the jam officially begins.
  3. Participants break out into teams and begin brainstorming ideas. Sometimes participants come in pre-formed teams, or prefer to work alone. However, larger in-person game jams, like Global Game Jam, encourage collaboration and making new friends at the jam.
  4. Participants begin to work on their games. During the brainstorming phase, teams generally work out the strengths and weaknesses of each member, and tailor their roles to match.
  5. The length of a game jam can vary greatly, with some as short as 1 hour, and some as long as a month or more. But generally, jams run the duration of a weekend. As the jam’s deadline draws nearer, teams begin to wrap up their games, and submit them to the jam’s website.
  6. If the jam took place in-person, there will generally be time for teams to show off their game, and get feedback from the rest of the participants. If the jam took place online, there will often be some way for participants to rate and provide feedback on other games. Participants take time playing other games from the jam and provide feedback on them.

Why would anyone want to put themselves through that?

Game jams are generally fast, and pretty high-octane. But, they’re also incredibly fun, great for levelling up your skills, and provide invaluable networking opportunities. The limited time-frame forces participants to work quickly, solve problems quickly, and think outside the box. It’s great having a week to muse over that bug in your game you just can’t quite fix. But, when you’ve got 10 hours to the deadline and you just can’t figure it out, you and your team might have to come up with a creative way to integrate the issue into your game. “It’s not a bug, it’s a feature!” is a common expression heard at jam sites.

Jams are also low risk. Participants are able (and encouraged) to break the mold and experiment in terms of design. If your project goes sour, you’ve really only lost a weekend, and you’ve probably at least learned a whole lot of what not to do. Due to this low risk factor, participants may also choose to try something new, like a new game engine, or a whole new specialty, like taking a sound/music role for the first time. Again, if your game doesn’t succeed, you’ve still succeeded in learning more than you can in a weekend anywhere else.

If your game does go well (and it will!), you’ll have a really cool prototype of a design to start with when you start that long-term passion project! Plus, you’ll already have a team that’s just as engaged with and in love with the project as you are. Many incredibly successful commercial games have come out of game jams. Surgeon Simulator, and Johann Sebastian Joust, are just two examples out of hundreds.

Finally, the connections you make at jams will follow you throughout the industry for life. At Global Game Jam, I jammed with somone who ended up a peer and great friend of mine in RIT’s game design program. This year at GDC, I was able to meet up with former teammates, as well as community members of various online game jams who recognized each other by their projects. These meetups opened opportunities for further networking opportunities, and made a massive conference like GDC feel a little smaller and more welcoming.

How do I get involved?

There are many game jams going on all the time. For online jams, the only barrier to entry is signing up on the jam’s website.Ludum Dare is by far the largest online game jam, with thousands of individual developers and teams participating every few months (that’s right, Ludum Dare is a quarterly event)! Websites like, Game Jolt and Indie Game Jams also provide great aggregation of many of the jams going on at any time.

In-person jams are a little less frequent (although many online jams may have physical meetups during the jam). The largest in-person jam by far is Global Game Jam, which runs yearly in January. This event takes place in physical meetup locations across the world, with all teams working on projects focused around the same theme in the same weekend. Check the GGJ site for a site near you!

The only way to get involved is to get started! So, go register for a jam that sounds appealing to you, clear your weekend, and put together a rad development playlist. Happy jamming!

Note: This is a lightly edited duplicate of a blog post I wrote for the RIT Interactive Games and Media student blog. If you’d like to read the original, you can find it here.

Noah and The Quest to Turn on The Light: Coming out of the dark

I’ve been working on something pretty personal for the last month or so.

Before we talk about what I’ve been working on, you’ll need some history. I should also preface this post with the fact that I’m pretty sure I’m not a narcissist, and I’m not trying to fish for attention/pity.

Some history:

I’ve been making games for about 5 years, and sharing them publicly for a bit over 3 years now. I started sharing my work by participating in Ludum Dare, and then eventually Global Game Jam. I got bit hard by the jam bug, and started doing gamedev pretty much exclusively for game jams. I found quite a bit of success within the Ludum Dare community, with my games making it into the top 25 rankings, then into top 10 for many categories. In December of 2014 my game, OMNI, placed 2nd in Innovation and Theme, 6th Overall, and top 100 in all but one category. This was a super exciting time in my life. The amazing feedback from the Ludum Dare community paired with such high rankings was super validating for me as a designer.

But that elation dissipated quickly. During 2015 I was unhappy and incredibly critical of everything I made or conceived, and my work showed it. I quickly stopped showing my projects to others. By early 2016 my self-criticism had led to full-blown creative block.

Noah and The Quest to Turn on The Light is a game about why I think that happened.

When I started designing, I was doing it for me. I wasn’t showing my work to anyone more than close friends or family occasionally. I was in early high school, and just making games for fun as a hobby. That’s the attitude I had when I hit the jam scene. But as I learned more, and my projects started receiving more and more praise, my internal motivation shifted from “because it’s fun and I want to,” to “because it’s nice to receive praise.” External validation had become my primary motivator.

I stopped showing people my work because I didn’t feel it was worth showing off. It wasn’t as good as OMNI, and I was afraid they’d realize it. They’d realize that it was just a fluke, and that I’m not actually that good of a designer. They’d tell me my work was bad. Impostor syndrome paired with my fear of negative feedback kept me from making anything to even receive feedback on.

I started working on this project to explore reliance on external validation and its affect on creators.

I’m done talking about myself now.


Noah and The Quest to Turn on The Light (referred to as just The Light to maintain my sanity moving forward) is a game about a creator’s struggle with external validation, and how that external validation can lead to one being overly self-critical.

In The Light, the player navigates dark worlds solving a series of terminal-based puzzles in order to collect fragments of an image of a lit lightbulb. The fragments are to be deposited on a canvas in the world, in order to light its grey bulb, and illuminate the world.


The player begins in the Gallery, a large room whose walls are adorned with framed pictures of unlit bulbs. Each frame serves as a portal to a unique unlit world. Upon lighting of the world and return to the Gallery, the player will find the bulb in the frame is now lit.

Over time, figures begin to appear in the Gallery. These observers comment on the lit bulbs, positively at first. As these observers increase in frequency, they begin to appear in the unlit worlds, offering encouraging commentary to the player.

Eventually, an observer makes a negative comment.

Criticism floods the Gallery, and the unlit worlds. The Observers present at each terminal to criticise the player as they attempt to progress.


The idea here is that over the course of the game, the player gradually stops solving puzzles for the sake of solving puzzles, and begins solving them in anticipation of the feedback from the Observers. When that validation is replaced by criticism, the player must face the discouragement to continue to progress. How they handle the validation and subsequent criticism is completely up to the player. The Light tries to only provide the environment in which the player must face these things.

So that’s the state of things. I’ll periodically post development updates here, but the most up-to date log will always be Twitter. Feel free to reach out to me there or by email with any thoughts about The Light.

Rainbow, Factorial Algorithms, and You

In mathematics, a factorial represents the product of all the positive integers less than or equal to n. This is written as n!

So, n! = n * n-1 * n-2…

Generally, this operation can be implemented very simply with a recursive function such as:

int factorial(int n) {
    if(n != 1)
       return n*factorial(n-1);

However, this implementation is quite inefficient (plus Rainbow doesn’t really have any concept of functions or recursion). In Rainbow, a more reasonable solution would be to set a new variable, s, to the value of n, then create a loop that subtracts by 1 and sets s to the product of and n, finally breaking the loop when n equals 1. In our pseudo-C representation, it’d look something like:

int factorial(int n) {
    int s = n;
    while(n > 1) {
        s = s * --n;
    return s;

Thanks to labels, lookaheads, and lookbacks, basic logic like this in Rainbow is pretty simple. Here’s a factorial calculator in Rainbow:


This representation isn’t terribly helpful though. Let’s break it down by each hex string, as the RainbowVM would.

0x300101 ;in at 0x00, len at 0x01
0x101100 ;set value of 0x01 to value of 0x00
0x5000F0 ;label with const 0xF0
0xB00001 ;sub 0x00 by const 0x01
0xC01100 ;mul 0x01 by val of 0x00
0x700100 ;lookahead to val of 0x00
0x500001 ;label with const 0x01
0x201101 ;print 0x01
0x000000 ;exit
0x500100 ;label with val of 0x00
0x6000F0 ;lookback to const 0xF0
0x000000 ;exit (unreachable)

The first line, 0x300101, instructs the RainbowVM to take input, put the value of the input starting at 0x00, and the byte length of the input at 0x01. We don’t expect numbers greater than 255 (especially as 6! is 720, which is much higher than our memory cell limitation of 255, and would result in undefined behavior within the RainbowVM), so we only expect the first address, 0x00, to have the value of n. We don’t care about the length of the input, so we put it in 0x01 arbitrarily.

The next line sets address 0x01 to the value of address 0x00. Here, we’re essentially establishing address 0x00 as n, and 0x01 as s.

Next, we set a label with the constant value of 0xF0. Any value would be applicable here, 0xF0 is just an arbitrary constant. This is effectively the start of our loop.

Then, we subtract 0x00, or n, by 1, and multiply 0x01, or s, by 0x00.

Now, we see a great example of simple logic in Rainbow. The line 0x700100 instructs the VM to lookahead until it encounters a label with the value of address 0x00, or n. Immediately following is a label with the value of the constant 1. Were 0x00 to be 1, the VM would begin execution here, printing the value of 0x01, and exiting. However, if the value at 0x00 is not 1, then the VM will continue looking ahead until it reaches 0x500100, which is a label with the value at address 0x00. The instruction following that label is a lookback to our constant 0xF0, which completes our loop.

The last instruction, 0x000000 is unreachable. It’s there simply to make the program 12 instructions long so it makes a nice 3×4 bitmap image.

So, now that we know how the program works, let’s walk through the calculation of 4!.

First, address 0x00 is set to 0x04, and address 0x01 is set to 0x01 (the byte length of the input). Then, address 0x01 is set to the value of 0x00 (4). Next, the value at 0x00 is subtracted by 0x01 and becomes 0x03. Now, the value at address 0x01 (4) is multiplied by the the value at 0x00 (3), and becomes 0x0C (12). The VM now looks ahead until it reaches a label with the value at 0x01 (4). It finds the label 0x500100, and begins execution at the instruction following the label. The VM now looks back until it reaches a label with the value of 0xF0. It finds the label 0x5000F0, and begins execution at the instruction following the label. We’ve completed our first iteration through our loop.

Now, we start again. The instruction following 0x5000F0 dictates that the value at 0x00 (3) be subtracted by 0x01. It becomes 0x02. Then, as before, the value at address 0x01 (12) is multiplied by the value at 0x00 (2), and becomes 0x18 (24). The VM looks ahead for the value at 0x00, and again finds 0x500100 then looks back until 0x5000F0, completing the loop once more.

We’ve reached our final iteration. The value at 0x00 (2) is subtracted by 0x01, and becomes 0x01. The value at 0x01 (24) is multiplied by the value at 0x00 (1) and remains 0x18 (24). Again, the VM looks ahead for the value at 0x01 (1). But, this time it finds 0x500001, a label with a constant value 0x01, first. The instruction following the label, 0x201101, is executed, printing the value at address 0x01 (24), and the program exits.


If you are interested in learning more about Rainbow, check it out on GitHub.