Hey! I just won second place in a contest to make a serious game about dating violence! It’s called Little Things, and I’d love it if you would try it out on the contest holders’ website here.

Little Things was the result of about two-and-a-half months of on-and-off work. The first stage entailed a fair amount of research and organization around what elements of dating violence I thought could be expressed well in digital game form.  I found that previous contest winners tended to take a fairly direct experiential approach to presenting their content, so I used that as a guideline in how to approach the subject. <I’d like to note here, though, that Power and Control, the 3rd place winner from 2011, doesn’t exactly fit this mold, though is easily my favourite in terms of how it uses game mechanics (rather than simply textual content) to communicate aspects of dating violence. Well worth checking out.>

In considering many aspects of the topic, I particularly liked the idea of highlighting how innocuous certain dating violence behaviours can seem, and how as a result they might be going on unnoticed all around you. Setting the game as a series of online conversations allowed me to weave stories that the player could connect with and engage in to whatever extent they chose, but in doing so would gradually come to recognize some of the signs of dating violence through observation.

I initially wanted to incorporate more aspects of social media into the game: picture sharing, event invitations, “likes”, etc., but ended up reducing player interaction to limited dialogue choices. This streamlined play, but reduced the amount of meaningful input the player could have on the proceedings of the game. It was a necessary concession to stay on target for the submission deadline, but it would have been interesting to go beyond simple dialogue trees and into the realm of hidden variables and dynamically-triggered responses. Alas! Another project, certainly.

The element I’m most choked up about not being able to include is allowing the player to choose their character. If they’d been able to select an avatar, preferred gender pronoun, and which other character they’d be interested in dating, I think the game would have carried a much stronger universal message, that of the potential for dating violence to emerge in all sorts of relationships. Without this, the story is one of a single character that the player may or may not have any particular investment in or resonance with. It’s something that will bother me for a while, surely, but again: there’s always another project.

At the end of the day, though, I’m still pretty happy to have created something that explores serious subject matter through my chosen medium. It’s not the world-changing masterwork I hoped it might have become, but it’s absolutely valuable practice for my next attempt. Even just engaging with a more educational objective changed the way I approached the game: I was suddenly accountable to a body of information, responsible for representing it accurately, thoroughly, and in an accessible way. I feel that, at the very least, I accomplished this, even if the mechanics of interaction could have been further developed.

So! Forward. Another educational game, maybe? Or further exploration of interaction space? I suspect Collegia might be just the chance to refine these skills…

cut cut cut

Super Rock-Paper-Scissors was not the game I intended to make. On and off over the last month, I’d been attempting to pour my efforts into a larger project, one with a good handful of complementary mechanics, a cohesive and evocative theme, and the potential to hold a player’s interest across multiple play sessions. Something that might serve as a stepping stone out of freeware and into an ad-supported web portal game or maybe a mobile title. And I was getting there! Dabbling in some more complex code and doing fairly well for myself, it was thoroughly rewarding to be implementing my long list of nuances one line at a time.

But sometime around the 30-hour mark, I realized I’d constructed a palace that only I could ever enjoy. My primary mechanic (four keys, input in sequences of three, with the first two determining what unit to make and the third where to make it), though intuitive in concept, was unattainably far from that in execution. Essentially, I’d have been asking the player to commit to memory 64 different key combinations before they’d be effective at playing the game. Though I had some patterns in mind when designing these combinations, it was a far cry to expect any player to (intuitively!) recognize and sort these patterns in the same way I had. And, given that the game was intended to be played out in real time, the player would have to be able to apply these patterns rapidly, responsively, and on an almost constantly ongoing basis! Yuck.

It was time for me to take a step back. I realized that the core of this game was built around two mechanics: dynamic combinations and multiple-purpose inputs. I think both are neat ideas, and I intend to explore each of them further, but I’ve learned that they’re not very well suited to each other, or at least not under time pressure. So I decided to break things down and take just the idea of multiple-purpose inputs out for a stroll. And so Super Rock-Paper-Scissors was born.

Three inputs, two purposes each. A 3×3 interaction space built around well-understood relationships. Seems a little more manageable, with the real-time nature of the game providing the necessary pressure to make it challenging. And it turned out pretty well, I think. It’s not hard to beat the computer, surely, but there’s an interesting cognitive tangle that comes up when you’re attempting to process A: what icons are coming at you across the board, B: what icons defeat those icons, and C: the sequence of button presses required to respond ideally. I’m not sure it’s “the most fun,” but it is interesting.
(I can’t believe I was going to attempt this with a 4x4x4 interaction space.)

I feel like this particular design arc afforded me some really valuable experience with iteration and mechanic refinement. Given the huge imbalance between the amount of time I spend on technical implementation and the time I spend actually working with game design, having this opportunity to recognize design problems and then address them and iterate upon the resultant ideas has been really refreshing. That’s the sort of space I’d like to play in more often: take an idea and test it out, then change the shape of that idea again and again not in pursuit of similitude to the original, but of optimal gameplay. Swallowing my pride and recognizing that things often get better when I let them diverge from my initial vision.

Ah, pride. You’re really one to watch out for.

marking progress

Thinking over this last month about how best to proceed in my game development, I drew significant inspiration from Rami Ismail’s recent Gamasutra post. In it, he highlights the necessity of trying and failing multiple times, of running through the game development process again and again until you start to find what works (for you and in general). I’ve realized it’s not so much that I need to spend longer on design, rather it’s that I need to focus more on getting something playable up and running as soon as possible. Doing that lets me get to the heart of a game right out of the gates and the answer to the critical question of whether it’s fun or not. I find it really easy to fall into the trap of searching out music or working on art assets before I’ve built anything tangible: working on the finishing touches before I’ve even started to make the thing.

Working toward yesterday’s release of Huntsmark (submitted as my February One Game a Month), I didn’t spend a meaningful amount of time more explicitly working on design than I did with Candysnake, I just distributed my working time in a better way.  I began by working out the basics in my head and on paper, then built an ugly skeleton framework as a proof of concept. It worked! And I was glad. So I committed the rest of the time necessary to polish it up and more or less complete the idea. It’s not perfect, but it’s a step on my way towards being able to smartly select and organize projects. Additionally valuable to my process this time was a one-on-one playtesting session with Andrew, which exposed quite well which aspects of the game didn’t quite stand up to my imagining of them, and prompted a number of critical changes. I’m tempted to think this session might have been better scheduled earlier in the development process (it fell roughly at hour 10 of 15), but I did quite appreciate having a fully playable experience in place as something to base future development possibilities on, rather than just the far away floating possibility of a game that might be fun.

And this is what Ismail is getting at: bringing something out of the realm of ideas and into reality is the only way to know its worth. I have a hundred odd ideas that “might make good games,” but whether they will or not is completely up to how they’re implemented in reality (subject heavily to my own limitations as a developer). And my experience lately has shown me that meaningful (and relatively quick) exploration of what’s fun and worthwhile is not out of reach.

So! Onward into March, with the possibilities of the Cyberpunk Jam, 7-Day Roguelike Challenge, and Procedural Death Jam looming large on the horizon. Will I make a game a week for the foreseeable future? Maybe!

too much candy

Earlier this year, I signed up for the One Game A Month challenge: a low-pressure community-supported personal commitment to make 12 finished games by the end of 2014. I thought it would be a good way to keep myself trucking along and fresh with new energy, with many opportunities for skills development and learning along the way. And so far it has been! But my experience making Candysnake has led me to think I might be going about this the wrong way.

The Candy Jam was in my mind as I pondered whether or not my existing January project could become a game in time for the end of the month. After a dream about a snake orthogonally moving through a field of wheat, I decided instead to attempt a hybrid match-3/snake puzzle game. So, with about 10 days until the deadlines for both the Candyjam and #1GAM, I began cobbling Candysnake together. The project was great for the development of my coding ability; I’m a whole lot more comfortable with arrays than I was when I began, and feel like the way in which I think in terms of sequencing and concurrent functions has advanced a fair bit too. I was proud of myself as well when, mid-week, I recognized that the code I had written up to that point was a patched-together mishmash of not-particularly-complementary processes that wouldn’t stand up to a strong breeze. So, with the idea of what I wanted in mind, gained by cobbling that previous mess together, I rewrote everything from the ground up. And it was so much better! With one cohesive thread running through things, everything hummed along in a way that I had never before achieved in a project of mine. I’m really happy with that; Candysnake stands at this moment in time as my greatest technical achievement. But is it a good game? There’s the rub, and my reason for this present doubt.

Rather arbitrarily, I started logging the time I spent on game development back in mid-January. I split things up by what project I’m working on and what aspect of that project I’m developing. This proved incredibly telling when, after I’d finished Candysnake, I found this breakdown:

  • Coding: 18 hours
  • Asset development: 13.5 hours
  • Design: 1 hour

One hour. One hour?! Yikes. This would seem to be the reason why, while I’m wholly satisfied with Candysnake’s transitions, aesthetic, and overall presentation, I don’t feel like it’s in any way a noteworthy game (despite the attempt at a novel mash-up of mechanics). It’s just not that well designed, and as such it doesn’t have much of a hook or any real staying power. And this is a bit of a pattern with my games. With my abilities being where they’re at, every game jam I’ve participated in has found me, down to the very last minute, pouring my time into just putting the technical parts of the game together. I know I can make better games (and I know that the only way to get to that point is to just make games, period), but I wonder what would be the best way for me to approach things going forward. I see two options:

  1. Choose simpler jam projects and spend proportionately more time refining their design. This is a good idea in concept, though I’m not entirely sure of my ability to stay motivated about a game that’s too simple. Ah, but that’s not fair either. I’ve played plenty of games that all the more satisfying for their simplicity. Perhaps I just have a hard time generating such elegant ideas for myself. I do like the constraint that a jam provides, and pushing myself to finish something by a hard deadline is doubtless good for refining my abilities both to scope appropriately and then to deliver on that idea.
  2. Commit to spending a longer period of time on any idea that looks like it might have legs. Rather than packing it up as-is and calling it a finished jam game, take it further, to the point where it has value beyond a momentary distraction. Could Candysnake be a full-fledged game? I think so, but it would require a total and thorough rethink of its basic mechanics. Do I like Candysnake enough to do that? I don’t think I do. The trouble here is enthusiasm fatigue, but if I never work through it, I’ll never make it to points beyond.

I’m not sure which path I like more right now, or even if I have to choose one over the other. But in order for me to make the jump from single-play disposable freeware to something that drives a longer-term commitment in the player, I’ll have to carefully consider how I approach my future projects. There’s value, certainly, in spending time working on a game in any way, but for me to find satisfaction with the work I’m producing, something has to change.

Reflections on a midnight joyride

I made Teenage Midnight Shopping Cart Joyride TURBO last week for the most recent Charity Game Jam and feel really good about it. It’s clunky and frustrating and simplistic, but as far as similarity to my original vision goes, I managed to get pretty close. I feel like its particular brand of rough edges suit it, somehow. It is an ugly baby of my very own.

I’m most happy with the degree of feedback I was able to provide the player. Though it’s definitely clumsy, the cart handles more or less like I’d expect a shopping cart to, and the addition of proper sound effects really place it for me (again, a million thank yous to @80P_Thompson for some late-night parkade Foley work). And falling over repeatedly amidst a heap of VHS is what everyone wants to do, right? I’m proud of my sloppy trophy system; every player I’ve seen stumbles into it organically and, if they stick the game out until a round’s end, they’ll know there’s more to do.

This was the first time I used a FSM manager plugin for Unity called Playmaker, which, after a few days of learning and apprehension, became a pretty valuable tool to me. At first I wasn’t sure how capable it would be; that it might fall completely short before the might of raw scripting. Then I flipped and worried that it might invalidate the year I’d just spent learning to code. Then, after working with it for a while, I found it a good niche. It can’t do everything, but it does some things beautifully. No more state conflicts like I had in Spacefaust. And it opened up a world of movement and animation to me that had long seemed inaccessible; now I could tweak iTween parameters to my heart’s content without tripping over my own thumbs.

The whole project, actually, was a big step forward for me visually. I finally learned some general Blender proficiency, which I used to make a whole handful of clunky models. It’s not that I aspire in any way to do game art, it’s just that being able to do so on a basic level gives me a lot more flexibility in design; I’m no longer restricted to Unity primitives without proper texture maps. And though I haven’t touched animation just yet, the aforementioned tweening work lets me move things in ways other than through direct input or physics forces. But these elements take a lot of time, even for the rough products I’m able to assemble. It’s time I’d much rather be spending on design, but the same could be said of all the technical work I do, too. They’re necessary parts of any project, and as long as I want to work on my own, they’re up to me.

That said, TMSCJTURBO feels to me like the first real point of convergence I’ve hit between my design aspirations and my technical abilities. It’s not pushing any boundaries, it’s not advancing games as a medium, but it’s enough, at least for me, to write home about. Another step on this path o’ mine.

onward to Rome!

I woke up this morning to some very good news from the Bundle-in-a-Box blog:

“The Indie Strategy Bundle Indie Dev Grant goes to Collegia!”

This is really exciting. To witness this upswell of support from friends, family, and some completely unknown corners of the internet has been very encouraging; there are, at the very least, a good handful of people who would like to see Collegia made. To them I say that we would very much like to make it. And though the grant isn’t a colossal amount of money, it is something tangible. A start, a call to arms, a launching point. Tinder, perhaps, from which we will build a roaring flame. I’ll keep you posted as we start making sparks.

And so it begins.

spacefaust post-mortem

After a long and fruitful discussion with the Trifecta about how to best enhance Spacefaust for a game portal crowd, Andrew approached me with an alternative. He put forward the idea that, rather than pulling Spacefaust well apart to implement a whole mess of new things, that I instead take what I liked about it and apply it to some future project. I’ve been very actively considering this thought and have found that it rings truer than any other for me right now.

What do I like about Spacefaust? The idea of boasts. The idea of elective challenge, of hubris and consequence. But these ideas could easily be applied to any other skill-based game, one that could very easily be more satisfying to play than Spacefaust is. And that’s where Spacefaust looks less and less like the best vessel for this idea. The shooting is jittery, the impacts are unrewarding, and the feeling of pressure and challenge is largely artificial. In order to improve the overall feeling of the gameplay, I’d need to rebuild several parts of the game in some pretty fundamental ways. It would begin to approach the boundary of what constitutes a series of improvements and what is, more realistically, a new game using some of the same assets. So I’m going to hold onto the seed of what excited me initially with the hopes of someday applying it to a more exciting gameplay framework I’ll develop further down the road.

That said, it’s hard to let it go. It’s hard to see the potential of where things might end up and willfully close it off. I want to make a good game. I want people to enjoy playing it and look forward to playing it again. I want to prove my game design abilities to the world. But that’s just it. They’re not quite there yet. I’m new at this; I can’t expect to succeed without a whole lot of practice. And with every project I work through, I improve my skills. So onward! To more projects! To developing satisfying gameplay before high-concept notions!

a vote for Collegia is a vote for Rome

Just a quick note to say that Collegia, my ongoing collaboration with Hadley and Alison, is a contender for Bundle-in-a-Box’s Indie Dev grant! If you pick up their strategy game bundle, you can vote on a game to receive a share of the proceeds! You can read the summaries of all the potential recipients over at their blog, but I’ll just leave Collegia’s here for your convenience:


Rome, 1st century BCE: In a time of transition, the inner workings of the city are left to its people, many of whom have united into syndicates called collegia. As a collegium leader, carry the community to prosperity, whether by gaining the admiration of your countrymen or by working in the shadows to undermine your opponents. Seek wise counsel in your dealings, be they above or below board, but keep a sharp eye out lest one of your advisors decide they could do a better job.

Know that every decision will have consequences beyond your sight and that history shan’t unfold the same way twice. When a mighty warrior is brought before you, rumored to be a legendary Amazon, will you take her in and leverage those whispers for greater notoriety and underworld influence? Or will you put her on display in the gladiator pits, for huge crowds and even bigger profits? And who’s to say this Amazon won’t have her own plans?

Your every decision will send ripples out across the face of Rome, whether so slight as to pass unnoticed beneath a paper boat or of such gravity to topple a nation.

And remember: fortes fortuna iuvat!

Pick up the bundle (and vote for Collegia!) here.

spacefaust perimortem

The creation of Spacefaust traced a curious arc through my life and I wanted to make a few notes here, to myself and the world, to reflect the process I went through this time around.

Kicking off the project through participation in a game jam provided an interesting constraint I’d never previously experienced. Given two weeks, come up with an idea, scope it properly, and carry it through to completion. I started out feeling pretty good about the concept and only felt better as I started to put things together. It’s a wonder, really, how much I can get done when I really put my nose to the grindstone. Towards the deadline, I pulled a 36-hour straight burn wherein I gutted most of my code and rebuilt it from the ground up (twice, because “lots of work” != “good work”). It didn’t hurt and I didn’t regret it; it settled on me just as something I needed to do. I don’t know that I’ve ever worked so hard, in so focused a manner, on anything in my life. I wanted to get it done and I wanted it to be everything I’d imagined. There really wasn’t any room for compromise. Of course, I ran into a web player issue the night I was to submit and, given that a web deployment was a requirement of the jam, I had to withdraw. A shame, especially given all the fabulous things that are going on right now with the other entrants, but at that late an hour I didn’t have a choice.

It’s funny now to think that I had convinced myself, in those final hours, that the game was “just about ready to go.” It’s a funny place to be, and I teetered there, purgatorially, for the three weeks following that deadline. Nearly every morning, I woke up with the thought that I would finish things up that day. And though I focused and worked on it pretty solidly, each day ended with still more to do. An important lesson there about all the details necessary to bring a project to completion, and one only learned by attempting to do so. So I’d say now that I’ve a better sense of what I’m capable of and how much time it takes me to handle it, but also where the edges of any project more realistically sit, and just how many gaps need to be filled out.

And so it’s felt good, this weekend, to let it all go. To leave things where they are, with almost all of my initial ideas implemented, and tidied up enough so that players ought not run into any major bugs. But there’s still further I could go. This began as a jam game and finished (albeit late) as one, but it’s not hard to imagine a thousand possible enhancements: to the gameplay, to the backend, to the visuals. And as much as I’d like to close the lid on it and jump back into Collegia, the fellow who served as my primary contact for the jam (Dan Boutros of Skybound) planted a suggestion in me that I just can’t let lie. His words: “I’d recommend tweaking the controls to work better on a laptop with a touch pad (you’ll get more players that way), but otherwise, I think you should submit it to Kongregate. You could probably make a few bucks off it every month.”

Whoa. Huge consideration for me. Make money off a game? Hosted on a high-traffic site? Huh. Suddenly the project has been blown wide open once again. I’d really like to do this, which means adapting the controls, integrating the Kongregate API, and tweaking the gameplay to better scratch that arcadey web game itch. A few adjustments and I’ll have something I’m even prouder of. Hoom. I think I can do it. I’m going to do it. Hoom.


I know I’ve been quiet lately, but it hasn’t been for no reason. Presenting:


An exploration of pride and capability, set against a backdrop of endless space creeps. Take on boasts to challenge your abilities, but know well your limits — overconfidence may very well be your downfall.

Play it here.

Originally made for The Walking Dead “All Out War” game jam, I ran into some eleventh hour difficulties with web player deployment and didn’t make the deadline. Ah, but what a blessing a little bit of extra time was. Room for a little bit of polish and several realizations of gross programming errors. Should be fixed now.


You’ll see by its watermark that Spacefaust was made with the trial version of Unity Pro, for which I would like to thank the organizers of that game jam. I used bfxr to create the sound effects, Spacescape to generate the skybox, and FreePD.com to find some public domain music (ended up with Spacial Winds by Kevin MacLeod). I used Blender very lightly to make my islands and Adobe Photoshop to do my image manipulation. And I am immensely grateful to the Unity Answers community for helping me out again and again along the way. And a I’d like to thank especially my fellow Trifectants Andrew and Chris, as well as Cameron Kunzelman for some excellent feedback.

Get to playin’.

<Requires Unity Web Player; will prompt to install if necessary>