All the Zeldas Pt. 1: The Legend of Zelda

On a whim last weekend, I decided to sit down and replay The Legend of Zelda (1986). I didn’t expect to play through the whole thing in two days, but after 35 years it’s still as fun and engaging as it was when I first played it in the early 90s.

I guess it shouldn’t surprise me that the first game so perfectly captures the essence of the series, but I had half expected it to feel dated, or to lack some key element from later entries. But it doesn’t. The movements feels great, there’s a surprising sense of exploration and discovery as you explore the map, and the puzzles are (mostly) intuitive and rewarding; albeit often little more than variations on “find key, unlock door.” Of course, getting away from the “find key, unlock door” model of puzzles (even if the “key” is a raft, or a flute, or whatever McGuffin) is still something that modern games struggle with, so it’s hardly a glaring fault.

The few puzzles that weren’t intuitive, were usually cleared up by reading the manual. This definitely dates the game (since most games don’t have manuals any more, let alone expect you to read them), but it’s not the worst. Learning that “spectacle rock” is specifically a reference to “two huge rocks high on Death Mountain” is not much different if you read it in the manual or read it on screen, as long as you know that the manual is there, and that you need to refer to it.

While reading the manual I also learned that, on the original console, if you didn’t hold down the reset button while shutting off the console, you’d likely lose your save progress. This finally explains why I lost so much progress playing this game growing up. Unfortunately, I learned it about 25 years too late.

Of course, that was down to technology of the time, and reading more about the technical limitations of the NES, it’s amazing that this game even runs. The graphics look simple today, but they’re still vibrant and evocative. And most importantly, they communicate clearly to the player.

Some visual affordances I expected were missing however. For one, bomb-able walls don’t have any cracks or visual cues. There are hints at this throughout the game though (one is an NPC telling you to “Go to the next room” at a dead end, and there are also “dead ends” where you can see another room on the map). I’m not sure how easy it would have been to figure out as a kid, but the trope of bombing walls is so ingrained now that it’s hard to separate from my prior knowledge.

Aside from the puzzles, there were also some unexpected spikes in difficulty in the dungeons. My expectation is that the balance and difficulty curve smooth out in later entries in the series. But it makes me wonder about differences in game making methodology, and how far the industry has come in the last 35 years. And then it makes me wonder how much further we have to go.

As a last thought, the game (the “first quest” anyways) took about 10 hours to finish, which is honestly a great length for a game. It can keep you busy for a weekend, but it doesn’t overstay its welcome. I honestly wish more games landed around this running time.

And I guess that’s that. The Legend of Zelda is still a fantastic game after 35 years. On to the next!

All the Game News I Forgot to Announce Here

So I’m realizing now that I’ve consistently forgotten to update this blog with announcements for the various games that I’ve released over the past several months.

The most recent was Escape from the Camp on Murderhaus Island. It’s a short prototype mixing survival horror, rogue-like, and text parser adventure game mechanics. I’m pretty happy with it, and it’s definitely one of the prototypes I’m considering expanding into a full game. If you haven’t already, I would be thrilled if you checked it out over on And if you have already checked it out, thank you! You’re the best.

Go play it over on!

You can also see all the other prototypes I’ve made on my profile page. Going forward, I’m going to aim for more regular, smaller, more casual updates here. If nothing else, I figure I should get in the habit of getting some stuff up here, and shouting from the rooftops every time I launch something.

Also, for anyone who missed this on Tuesday, let me take this opportunity to shout about the new video series I tentatively launched earlier this week, What have I been up to?, a weekly look at all the prototypes, mistakes, and catastrophes that I’m creating.

Thanks for stopping by!

What have I been up to? Indie Dev Diary | EP 0

Writing blog posts takes too long, so I’m going to spend much more time making videos, I guess? Here’s a test episode, where I go over some of the things I’ve been doing for the last six-ish months.

If things go according to plan (do they ever?) I’ll be posting one of these every week. Hopefully the next one will be properly in focus 🙃

Every week?!

Look at me, writing regular blog posts (as we all know, the month is the smallest atomic unit of time, so there is no way I could have written a follow up to July’s post sooner than this moment, right now). Just over a week ago I stumbled across a fantastic GDC talk by Bennett Foddy & Douglas Wilson called Game a Week: Teaching Students to Prototype. I was mostly watching it in the background, while working on a game. But when the talk finished, one of the final slides included links to the course syllabi. So I took a break, and a quick browse, and found that one syllabus actually included the prompts for each of the 11 projects students would complete for the course. I read this for a bit, thought it was cool, but then went back to work.

But my mind didn’t completely go back to work. It kept thinking about the concept in the background, and before I knew it, I had an idea for the first prompt, “10 seconds or less.” So I made it. And then I made another game, because hey, why not? And also because the first idea I had was really grim, I wanted a more lighthearted counterpoint. You can play both games right now, in your browser, over on Check out Happily Ever After, and You are Dead.

I won’t claim that either game is good, but I have already learned so much from making them, and I’m hoping to learn more as player feedback trickles in. So what have I learned so far?

1) Don’t have deadlines on Friday nights

I have friends, and we like beer. I’m also a procrastinator, and like to work up until the very last minute. If I have a due date at midnight on a Friday, something’s going to give. The solution? Midnight on Monday due dates. We’ll see if that moves a little more after the long weekend.

2) The feature creep is real

For You are Dead, I had a very simple idea, and executed it quickly. But as I worked on it, I kept coming up with ideas about how I could expand it into a full game. Then, when I started working on Happily Ever After, I foolishly started out building it in a way that would be easily extensible into a full game. So I designed, and started to build an easily extensible CSV file importer for building different scenarios, I worked on a syntax for the CSVs, I worked on a character designer, and plans for different level designs for different types of level (ex. castle, forest, town, etc.). Needless to say, this was too much to make in a week, especially when I’d already used up half the week making a different game. So I hardcoded a single scenario (ditching the other scenario I’d written, and the CSV import), I changed character creation into character randomization, and I only used a single level, for a single type of area. I’m not sure how to avoid this mistake going forward, but I’m definitely going to watch out for it.

3) You’re not a software developer anymore, god dammit!

This ties into the above, but I really need to watch the tendency—taught to me by computer science—to over-engineer my code. This is doubly true for these tiny prototypes, but even on larger projects, I should make sure a feature actually works, before building it into a robust, extensible bit of code. The CSV file idea is the most glaring example of this. Especially since I’d never handled CSV I/O in C#.

4) But still code in a consistent style

That being said, I still need to make sure I follow a consistent coding style. When I was quickly going back to replace the partial robust code with hacky quick fixes in Happily Ever After it would have been a lot easier if things were already in decent shape, instead of a mishmash of different styles. This is mostly just me transitioning from working mostly in Python at my previous job to working in C# in Unity, but it was still an important lesson to learn.

5) Don’t make too much art until you’ve got a test in the game

I made this mistake twice, once for each game this week. In You are Dead I made too many animations, and then ended up not needing all of them once I actually built the game. I wasted work by putting too much effort into the art pipeline before knowing exactly what I’d need. Oops. I partially learned this lesson for Happily Ever After, stripping out unneeded frames from the base sprite sheet I was building on top of, but made a brand new mistake along the way. After drawing several different layers of clothing, hair, etc. on top of my (modified) base sprite sheet, I finally added a bunch of them to the game (creating animations, prefabs, etc.) and then implemented character movement in a test world. It was at this point that I realized that the sprites I’d created were slightly off center, which caused a physics error when the character would change direction next to a wall (phasing through the wall, and sometimes shooting off into space). I compensated for this in the engine, but it would have been easier and better if I’d caught it before putting so much work into a faulty art pipeline.

So that’s a lot of learning. Pretty much a lesson every day, taught to me by my own mistakes. I can’t wait to see what I screw up this week! I read the next prompt last night, and my next game (only one this time!) will involve, “Find & click.” In the meantime, you can check out this week’s games, along with everything else I’ve made, over on my profile.

For the love of blob

If you’re like me, and you dearly miss Google’s adorable blob emoji, then I have a teeny bit of good news. While I can’t tell you how you can keep using squishy gumdrop emoji in your everyday texting, thanks to the magic of git, you can download the full set of source images right now.

Look at this adorable rapscallion

They’re available in both SVG and PNG format in the official noto-emoji repository on GitHub. It took a little bit of time to navigate the commit history, but I managed to track down the final version of the 7.1 and 6.0.1 versions of the cute little blobs.

If you want to preview the different emoji sets, you can go to Emojipedia and take a look at version 7.1 and/or version 6.0.1.

You can download everything for a given version by clicking the “Clone or download” button. The emoji are in the “png/128” and “svg” folders, not the “images” folder, because naming things is hard. I believe the emoji have a pretty permissive license, but please don’t misconstrue this as legal advice because I am not even remotely qualified for that. That being said, I am 100% planning to use all three versions of these emoji in the game I’m currently working on, and I’ll update this article immediately if Google tells me I can’t do that.

For anyone with a little git-fu who wants to pull the relevant commits directly, 6.0.1 is 7c0d24f2 and 7.1 is e4566541.

November DevLog

What went right?

40 hours & 18 minutes of development time. That’s a personal best since I started tracking my time spent working on games in September 2016. Most of that was spent on a project which I’m calling Judgment Day, with a smattering of work on Radio & Seed (two closely related games). A big part of my plan going forward is to build games with underlying frameworks which can be reused as the foundation for future games. For example, Radio currently has 3 possible variants on paper and Judgment Day could, similarly, serve as the foundation for at least one other game.

What went wrong?

Not enough blog posts, and not enough videos. I started writing two additional blog posts this month, but never managed to finish either. I also spent several hours working on video content, but was never satisfied enough with the results to post anything. I’d also forgotten how long it takes to record & edit videos. Since I want my primary focus to be game-making, I’ll need to figure out a lightweight solution to both blogging and videos if I’m going to produce bi-monthly blog posts and monthly videos.

What’s next?

The plan for December is to keep working on Radio (specifically a variant which I’m calling LHP 820), but I am obviously not super strict about sticking with a given project, and my inspiration frequently shifts. I’m also trying to zero in on a format for some video content, and will be running more tests, with the goal of releasing at least one video update this month. I’ll also be returning to the more promising of the two blog posts I started in November, aiming to publish mid-month.

A plan

Bearing in mind that a plan is just a list of things that don’t happen, here’s my plan from now until June 1st:

  • ☐ Make games for at least 5 hours every weekend day
  • ☐ Update this blog twice a month
  • ☐ Video updates once a month
  • ☐ Release 1+ game(s)
  • ☐ No debt
  • ☐ 18 months savings
  • ☐ Safety net

Who did no game work in July?

I did no game work in July.

Well, technically that’s not true. Technically I spent 5 minutes writing down ideas. Other than that, I was distracted by work work. You know, the thing that pays the bills.

I’m two-thirds of the way through a long weekend right now, and hoping to spend some time on a longstanding game idea tomorrow.

I sure hope I have better news next month.


June was going pretty well. And then I got promoted. The back half of the month was pretty slow when it came to making games, while I tried to adapt to the changing landscape of my professional career. Still, total productivity for the month wasn’t bad.

Astute readers will notice minimal overlap between the projects worked on last month, and the projects worked on this month. Making games is hard. And what’s even harder is scoping a project down to the point that I can finish it sometime this millennium while only working on it part time, by myself. I’ve got some prototypes which I think are promising but… we’ll see.

I’d also really like to start doing development video diaries, but it’s hard to justify the time when I can’t even find enough time to make games. Maybe once I settle into the new position at work. Or after I finish a game. A game jam scenario would probably be ideal for some video content, but first I need to find 48+ uninterrupted hours. But that’s enough musing for tonight. To bed, to dream of games. And then, this weekend, to make them.