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

Kicking Creativity Into Gear: Settling on an Idea

When I was a teenager and aspiring filmmaker, I quickly learned that if I ever wanted to film the screenplays I was writing in my spare time, I needed to work within the creative constraints imposed by my limited resources.  I couldn’t film car chases, or gun fights, or include stunning aerial shots of urban environments, or even the suburban enclave to which I was confined.  While at first these limitations were frustrating, I came to believe that some degree of limitation forces creativity to thrive, leading to a better final product than offering unlimited resources to a creator.

Now as an adult and aspiring game developer, I don’t need to worry about procuring period costumes for a medieval epic, but a whole new batch of limitations guide my decisions about which projects are worth my limited time as a developer.  I’ve sketched out a number of ideas over time, looking for something which strikes a good balance between feasibility, novelty, creativity, and commercial viability.

Of those four facets, I care the least about commercial viability.  I’d rather make something interesting, which never sells, rather than something unoriginal which sells like gangbusters.  This is helped immensely by the fact that I’m currently a student, not a professional whose financial future rests on the commercial success of the games I work on.  I also figure that, in the worst case scenario, whatever I create will be a useful portfolio piece when I try to market myself to software companies of any stripe.

I probably care the most about novelty.  I want to create something that doesn’t exist in the world, because I want to create games that I’ll want to play.  My target audience is me, because I know exactly what I like, and what I don’t.  I don’t have any interest in creating a game that already exists, because if the game exists, I’d rather be playing it, rather than painstakingly recreating it.  Game development is fun, but it’s not that fun.

But enough about the nebulous factors that influence my creative choices—your mileage will vary dramatically, depending on your own priorities—let’s get to the practical considerations that constrain my choices.  First, and most obvious, I’m just one person.  I also have no budget.  This means I can’t do things like hire artists, or musicians, or anyone to help with production.  Some of you might say, “But couldn’t you offer someone a share of profits, or exposure for their work?”  In short, no.  This project is so far removed from profit, that an offer of profit sharing is indistinguishable from asking someone to work for free (aka. “working for exposure”).  So at the start of the day, and the end, I’m just a single person trying to make a game.

This is obviously a constraint in and of itself, but also means that I need to consider my specific skill set, since it will determine all the work that I can accomplish.  I’d put my relevant abilities at roughly 60% programmer, 20% game designer, 10% writer, 9% graphic designer, and 1% artist.  This is an incredibly rough heuristic, and probably wildly inaccurate, but it’s the best guess I’ve got at my own abilities.

So based on those abilities, any game I develop on my own should be systems heavy—focused on designed mechanics and their implementation in code—with less of an emphasis on writing, and minimal requirements for fancy visuals.  I have exactly zero background in 3D art, so while I could comfortably code a 3D game, I shouldn’t develop one on my own, since I have no idea if I would be able to create adequate 3D assets.

You’ll also note that my abilities don’t include music.  For that, I’ll have to rely on the public domain, meaning any game that can reasonably use music published before 1923 will have access to a significantly larger body of work, compared to a game that would rely on works released to the public domain (or on a commercial-friendly Creative Commons license).  If you don’t intend to release a game in the United States, the year where works enter the public domain might be more recent than 1923.  Of course, you’d be cutting yourself out of the single largest game consumer market, so…

The public domain, and Creative Commons, also provides a significant resource for game art, so even someone with zero art skill could scavenge all their art assets online.  However, more so than with music, this does present a challenge in creating a coherent visual style (I’m sure a musician would tell you that creating a coherent, freely sourced audio style is just as challenging, I’m probably just revealing the depths of my ignorance here).  Regardless, the 1923 rule of thumb holds true for visual art as well.

As a corollary to the code-focus mentioned above, I also decided I should focus on procedural generation, rather than bespoke content.  While procedural generation isn’t easy, a good systems focused game with randomization can theoretically offer infinite playtime, with finite content creation.  The same can never be said of a linear, narrative focused game.  This isn’t meant to devalue linear, narrative focused games as experiences, and if your own abilities lend themselves to the creation of that type of game, go for it!  But in my case, I can punch above my weight as a lone developer if I focus my efforts on systems based games.

That being said, my time is a finite resource, and as much as I enjoy a game of staggering complexity like Dwarf Fortress, I’m not ready to commit to a single project as my life’s work.  I also enjoy the challenge of finding heuristics with which complex interactions can be simplified.  This ended up cutting short several ideas which required a multitude of interconnected systems, all operating at the same time, in order to satisfactorily simulate the game world.

After dabbling in 3D development of bespoke content for a game jam, I quickly recognized that my abilities would create a lackluster experience of insufficient length to be worth playing (or purchasing).  Eventually the constraints mentioned above kept leading me back to the idea I finally settled on—a 2D, document focused, procedurally generated detective game, utilizing music and art that would fit with a 1930’s timeline (when it would be conceivable that art and music from the 1910s and 1920s would still be in circulation, much as people still enjoy the creative work of the 1990s and 2000s today).  This still has challenges, especially in the random generation of interesting crimes, which a player can solve.  But these challenges are fascinating ones, which I look forward to tackling, even if they ultimately result in failure.  They’re also challenges which I’ve evaluated as easier than many of my other ideas, which often quickly grew to Dwarf Fortress levels of complexity.  And succeed or fail, my work on these algorithms should, at the very least, look good on a resume, or as part of a portfolio.

So there you have it—a somewhat rambling look at the thoughts, considerations, and creative constraints that led me to grab onto this particular game idea, and hold onto it for at least a couple weeks of exploratory development.  And with that, it’s time to move past this self-reflection on my thought process (or, dare I say, procrastination and navel-gazing), and get down to the dirty business of making this idea a reality.