One Game a Month 2013 Retrospective

In 2013 I joined Christer Kaitila's challenge to release one game every month. It seemed like an impossible task. In the previous two years I had produced one lousy game and one promising prototype. I needed something to kick me into gear, and this challenge looked just right.

I met the challenge and released twelve game(-like thing)s last year, and I actually made several more that I didn't feel like releasing. Since I'm also raising three small children and working full time, it took an enormous amount of work and dedication, not to mention all of my free time.

I'm proud that I was able to finish, but was it worth it? I now have confidence that I can turn out a game in a relatively short period, but I don't know if that's because I've gotten better or just lowered my standards. I now have a relatively large portfolio of games, but is it work that I'm proud of? Generally no. In some ways, I think my year would have been better spent focusing on making four solid games instead of rushing out twelve. However, in attempting that it's just as likely that I would have ended up with four unfinished prototypes rather than twelve games that range from terrible to barely decent.

One thing I'm sure is positive is that I met a number of amazing game developers on Twitter last year. Seeing how others deal with the challenges of our quixotic hobby has changed my perspective, and helped me to see what really matters. While I wasn't able to collaborate with anyone this year as I wanted to, I hope that I can continue to participate in this community.

I'm going to go over each game from last year, and then write about what I learned from the challenge. Here is a summary of that in case you don't want to read the whole thing.

  • Churning out games won't make you better at game design unless you take time to review what you did.
  • Feedback from random people on the internet is useless. Join a group of peers and learn their points of view.
  • Nobody cares about what you're making. This is good and bad.
  • Jam games get more attention.
  • You can make graphics with enough practice. It's probably not worth the time.
  • Polish can make a good game great, but only makes a bad game mediocre. Practice this skill, but don't rely on it.
  • Too much polish can kill the soul of a game. Be careful and don't try to substitute polish for confidence.
  • Don't impose deadlines that interfere with other people in your life.
  • Make room for experimentation, exploration, and failure.

Games

January - Yet Another Brick Breaker

As the title suggests, this was a basic brick breaking game. I made it to learn how to build a game in an unusual language called Haskell. Haskell is a pure functional language with strong, static typing and type inferencing. It's an amazing language that compiles to native cross-platform binaries with great performance, and I can still be incredibly productive in it. The only problem is that it requires completely different solutions than an imperative language, so doing something simple like updating a game world with user input was pretty complicated.

Functional reactive programming (FRP) is a technique being developed for solving problems like that. The idea is that rather than having variables which you modify at each time step, you create values that evolve over time and then sample them at each screen update. It's a weird way of thinking, and I spent most of the month dealing with things like "time leaks." I used an FRP library called netwire which I highly recommend.

The game itself is nothing special, I was really just trying to figure out this new platform which I thought I'd be switching to. It turned out to be too much work for too little reward. I loved making a game in Haskell, but it will require an enormous amount of work to make a framework, so I don't see myself doing it again. As I discovered later, Haxe has a lot of the same features I want and is already tooled for cross-platform games.

February - Fretwork

Fretwork is an art deco themed puzzle game. There is a grid of wheels, and each one has four connectors attached to it. The wheels share connectors with their neighbors, so you can move the connectors around the board. The point of the game is to connect ports on the side of the same color with a chain of connectors. You get more points for a longer chain.

This game ended up being a huge disappointment and really killed my motivation to continue the challenge. I thought that it looked great, and the mechanic is something I haven't seen before and had fun playing with. It turned out to be a huge flop.

I see now that I didn't do enough to explain how to play the game, and there's not much game in the game anyway. It needs a tutorial and the gameplay should be more directed with specific challenges.

I'm still fairly proud of the graphics, although the menu screen needs to pull some elements from the game screen to fit in better.

March - Spin

This is the game that started it all. I made a prototype of this game three years ago, and it was the first game I'd made in years. My friends liked it, and it reminded me how much I wanted to make games. I should have released it then and moved on to another game, but I didn't have the confidence to do that. Instead, I tinkered with it for a long time and ended up cramming in every new thing I thought of. By the time I released it the Flash market had started crashing, so I missed the boat by trying to make it perfect.

I was proud of the graphics at the time, but playing it again I see how uneven and cheap it looks in places. The pixely particle explosions are nice, and I still enjoy the mechanic.

It's my best performing game, with over a million plays and my only site license. I think of it as a flop, though, because of the amount of time I spent on it.

April - File Your Taxes

After the disappointments of Fretwork and Spin, I just started making whatever I felt like without worrying about polish. While I was doing my taxes I wondered if I could make a game that communicated that same feeling of boredom, frustration, repitition, and arbitrary tasks. I think the game succeeds in that goal, but it's honestly embarassing to have people play. The kernel of the idea is there, but it's ugly, buggy, and I consider it unfinished. I tried to write my own collision system, and it has some bugs that can prevent you from finishing the game.

May - Shmup

At this point I had been writing my own Flash component-entity based game framework in Actionscript, and this was a test to see how to write a vertical-scrolling shmup. It doesn't have an ending, or points, or lives. It does have a really nice flexible, behavior-based AI system that I'll never use again. This game was the last thing I made with this framework.

I made the ships for this game in Blender, which was a lot of fun. I got pretty good with Blender, and I ended up spending some time making a Clockwork Magpie Studios splash video in Blender. That didn't appear in a released game until Frumulous Snarp.

June - Fluyo

In June I rediscovered a language called Haxe, which has strong, static typing with type inferencing and compiles to Flash, C++, and HTML5. I first worked with it years ago when it could only compile to Flash 8, but it's come a long way since then.

This month's game was a sample game using HaxeFlixel, a port of the Flash game framework Flixel to Haxe and OpenFL. The game is a version of Puyo Puyo with local multiplayer using blocks from opengameart.org.

I fell in love with Haxe and OpenFL this month. I've used them for every game since then.

July - Frumulous Snarp

Since HaxeFlixel is a framework for making platformers, I figured I should make a platformer. This was helped along by finding this amazing platformer graphic set on opengameart.org.

I don't really like platformers, but this was a lot of fun to make. It's a joy to work with graphics that are actually good, and I learned a lot by designing the levels in Tiled. I'm happy with how the title turned out, I think I accomplished the "faulty neon sign" look I was going for. This game also has the logo splash video I made in Blender.

At this point I was tired of not being able to track mentions of my games because the names were too common, so the name is just two nonsense words that didn't bring up hits in Google.

August - Gem Words

In August I was reading a lot about the HTML5 game market, and wanted to try my hand at a mobile-friendly casual game. OpenFL's HTML5 build worked well, and the game was even playable on my ancient Motorola Droid. The only notable thing about this game is the gem tiles I made in Inkscape, which I reused in September's game. Over the year I became very skilled in Inkscape, and it took me almost no time to make the graphics for this game.

September - Hex Match

This is a hexagonal match 3 I made after seeing a video of Puzzle Quest - Galactrix. This has been surprisingly successful, given that there's no ending or goal. I think it turned out well graphically, and there's something satisfying about how the tiles move and explode.

October - One By One

In September and October I was going through some serious personal crises, so I didn't have time to make a game. Instead I used the game I made for Ludum Dare in April. I had planned on expanding this game for an entry, but I didn't get the time.

November - Witch/Dogs

For most of November I was making an adventure game adaptation of Hamlet, but that project turned out to be bigger than I estimated. Witch/Dogs was a really quick game I whipped up as a joke clone of a friend's game that was a joke clone of Watch Dogs. This was fun to make, even though there's not much to it. I liked pixeling the dogs and hats, and I tried (and failed) to make a pixel version of the sun and moon from Soul Eater.

December - Beaver and Snake

I spent a lot of time studying pixel art on The Spriters Resource this month, and was impressed with the simplicity of the whip animation in Castlevania. I wanted to try it myself, and the result is a beaver that uses a snake as a whip. My pixeling skills have come a long way, as bad as they still are, and I was happy with how this game turned out. I don't know if I'll turn this into a real game or not; it was more fun to build than play. I think the interesting part of the game is the absurdity of it, which is a one-shot joke that probably doesn't deserve a full game.

Conclusion

Out of the twelve games I released last year, I think I'm happiest with the ones where I just did something quirky that made me laugh: Beaver & Snake, One By One, File Your Taxes, even Witch/Dogs. In the future I need to focus on games like this, that pull something weird out of my head and splat it on the screen. I feel an urge to make things very polished and stoic, but I think that's not a true expression of myself and I should resist it.

Here are the things that I learned about making games last year. Some points may seem contradictory.

  • Making and releasing games isn't enough to get better at designing games. Releasing them isn't even necessary. What's important is thinking about what you made, what went right and wrong, and how to do better.
  • Join or build a small group of people that are doing the same thing. The point of releasing a game is to get feedback, but feedback from random people on the internet is essentially useless. You want feedback from people whose perspective you understand and who have experience in what you're doing. I still don't really know how to go about forming a group like this other than paying to be in a class or living in a large city with a thriving game dev community.
  • Nobody cares. It's vanishingly unlikely that anything you make will be played by anyone, even your friends and family. Unless you're getting paid (up front) to make it, you're making it for yourself. So make sure it's something you enjoy.
  • Nobody cares, so don't worry too much about being embarrassed or being less than perfect. Nobody you know will see it anyway.
  • Games entered in a game jam will get orders of magnitude more attention than they would otherwise. These are also likely to be your worst games.
  • Making mediocre art is pretty easy once you get the hang of the tools, but mediocre art is almost worse than no art at all.
  • Polishing is a skill that needs to be practiced, but polishing a bad game makes it mediocre while polishing a good game makes it great.
  • Too much polish can kill the soul of a game. Be careful and don't try to substitute polish for confidence.
  • Imposing deadlines on yourself can be demoralizing if you have other people relying on you. Unless you're getting paid to do it, don't make yourself choose between meeting a deadline and going to your kid's soccer game. That's a bad situation to create for everyone. Deadlines can help motivate you to finish things, but recognize if it's better for you to have flexible goals.
  • Experiment. Leave room for playing with a new mechanic before you settle on a direction. Explore that graphic effect that sort of looks cool. This was my biggest mistake last year. All of my interesting ideas have come from seeing how far I can push a mechanic, but I didn't have time to do that each month. Instead I haphazardly picked a mechanic that seemed good enough and tried to build a game around it. Even when I came up with somewhat novel mechanics, like Fretwork and One By One, I didn't take time to explore them and the games suffered for that.
  • Leave room for failure. Experimenting with a new game design might not work out, and it was hard for me to take that risk when I knew it could leave me starting over three weeks into the month.
  • Track everything you can. It's hard to predict what will be popular, and if you wait until you've noticed something taking off it will be too late.

Even though I completed the challenge, I think I violated the spirit. The idea was to get better at making games by making finished games, but in several cases I turned in incomplete or barely complete work. To make matters worse, I spent most of the time experimenting with technology rather than game design. This was the exact habit I hoped to break with this challenge. In a lot of cases I fell back to tried and true game designs just to test new technology, or get something out fast when my first idea didn't pan out. In the end, while I learned a lot about making games, I didn't learn much about making games good.