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 itch.io. 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 itch.io 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.

Sickness & Changes

TLDR; ~13 hours of game dev in March; two weeks of sickness; and work stress.

A couple bumps in the road over the last month interrupted what little routine I was starting to get into, so despite a couple good bursts of productivity, the month overall was kind of underwhelming. To cap things off, I’ve been brutally ill for the last two weeks, barely able to function enough to keep up at work, let alone find the time and energy for spare time game development. There have also been goings on at the office, which has caused a fair bit of stress at work, which has leeched into my free time as well.

So not a great month for game development.

But as my health returns, and and things settle down at work, I’m hopeful that the back 3/4 of April can see me get into a groove. In that spirit, I’m going to keep this short, and try to sneak in a little game making before bed.

See you next month!

Hello Again

TLDR; I graduated, got a job, moved, played around on Unity, participated in a game jam, and am working on several different projects, hoping to find something that sticks. Planning monthly updates here in the future.

It’s almost a year to the day since I last posted here. That’s too long. So what have I been up to?

I graduated from Carleton University in April 2016, starting work as a software developer the Monday after writing my final exam. Between adjusting to a 40 hour work week, walking about 8km a day to commute, and trying to find time for relaxation and socialization in between, I didn’t have the energy for any prolonged bouts of creative hobby work for months. That only started to turn around in November.

Somehow, I made time to complete two games for Wizard Jam 4, a game jam created by the Idle Thumbs community. You can find those (and any games I might make in the future) on my itch.io homepage, accessible through the new Games link to the left (or hidden in the menu, if you’re viewing this on a mobile device).

After the rush of finishing the game jam, I’ve started a half dozen different projects, trying to find a game that’s small enough in scope that I can complete it as a hobby, in a reasonable amount of time. I put north of 30 hours into this task in January, creating a couple early prototypes, but only managed 5 hours in February. I’m hoping to get back on my game this month, with early work on yet another prototype starting over the last week.

I have no idea if this project will be one that I stick with. But I’m going to try and start chronicling these things here. Right now, I’m planning to treat every month as a self-contained chunk of development time, following it up with a detailed retrospective penned and posted here. I’ve got the event in my calendar, with notifications set up. Let’s see if I can stick with it.

I’m aiming for 40 hours of development time every month, a target I haven’t hit yet. I’m using Toggl to track my time spent working, Unity as a game engine, and Twitter and this blog to report on my progress (or lack thereof).

But enough procrastinating by writing this blog post. It’s time to get to work.


I really ought to keep this thing more up to date.  Despite the silence here—or perhaps because of it—I’m making progress on development. Contrary to the post before this one, I changed direction last minute and settled on a slightly different idea. Many of the points on my decision process still hold though, and this new game is still 2D, with simple art requirements, and a significant mechanical focus.

Random character generation, with placeholder art by Jeff Preston.

After spending January and February on design and coding various abstract objects, I’ve finally started work on UI.  With university quieting down after midterms, I’m hoping to have a playable prototype by the end of the week.  I’ll try to post more regular updates here, assuming progress continues at pace.

Anyway, if I want to stay on schedule, I better get back to it.  For those keeping track, in the screenshot above, the “People” tab is implemented to prototype standards.  That’s one tab down, four to go.