Near the end of October, a blog post from GitHub caught my eye, entitled: GitHub Game Off.

In short, GitHub was running a competition for game developers to build their games, host their code on GitHub, and have it loosely based on a git concept (forking, branching, etc). We were free to build it however we want as long as it could be open source. As a life long gamer, it’s always been a dream to build my own game, and that’s a dream that’s been also shared by awesome guy Wayne Sang.

We had been toying around with the idea of building out a game idea that Wayne had several months ago, and before Game Off, we had decided to build something smaller to get us acclimated with each other’s style and capabilities. GitHub Game Off presented itself as an opportunity to finally make this happen with real deadlines and actual work needing to be produced.

That game? Octocat Attacks.

You can view the source code here, and the playable version of the game here.

Most of the rest of this post is going to talk about the development side of things, as there were quite a few things I learned along the way.

Creating the Concept

When Wayne agreed to build a game for the competition, we sat down and hammered out a concept pretty quickly. I suggested that we use Flash, as it was probably the fastest way to get up and running with a game especially with established libraries already available, and that we make a puzzle game because “it’s far easier to build a silly puzzle game than a full blown action game!”

Just for the record, I was going to eat those words.

We sat down for several hours to hammer out the concept: it would be match-3 style puzzle, it would be about a giant alien attacking Earth, and various countries coming together to build separate parts of a robot to defend against the alien. The loose association with git was that each country was essentially working on its own “branch” of the master robot repo, and completing a level was that particular country “pushing” their part toward the final product. Each round was timed, and your score affects the quality of the piece that is created, with three different possible tiers in quality, which also affected your final battle with the alien.

I also did some research around the best Flash library to use to build games, and I landed upon what seemed like the most developed and easiest to get started with: Flixel.

There were a handful of other engines available, but Flixel was really far along in development and actually powered games I had heard of (like Canabalt!) and so I ran with it. Just as a side note, once you start using it, Flixel really feels like it was built more for twitch-based games rather than puzzle games, I was lucky to find the Flixel Power Tools set which extends the capabilities of Flixel even further, allowing me to take care of some of the issues I was having with sprites in Flixel.

Starting to Code

Once my environment was set up, I began to write a few test games just to get a feel of Flixel and Actionscript.

Have I mentioned that I haven’t really touched code in a serious way since 2009? Have I also mentioned that I haven’t touched ActionScript since 2005?

Granted, I was very familiar with programming in the first place, so the learning curve wasn’t very steep for me, but it was one thing to be figuring out what I can and can’t do with Flixel, and it was a completely different beast trying to do it while learning ActionScript 3.

However, I got a prototype up and running relatively quickly. According to my records, we started brainstorming on October 27th, and I had a prototype with a 5×7 board full of temporary game pieces that could switch places on October 31st. I was rapidly iterating on the first prototype, creating 90% of the game mechanics by November 12th: puzzle piece generation, piece movement (swapping places), match checking and clearing, and empty space refilling. Nothing was 100% as it should be for a completed game, but it was a very quick start.

Around this time, Wayne chipped in with his awesome pixel art, and the game was finally starting to come together.

Refactoring Mania

Regardless of the level of stability, I was rather unhappy with how game pieces were being moved around and being checked as matches, so I spent a good week refactoring everything. And I mean everything.

Suddenly the game became less jittery and resource intensive, I had created a queue for the checking and clearing of pieces, but I was still being plagued by my code to animate the refilling of pieces on the board. It was a problem that I am still having trouble with to this day, and I feel like I’ve smashed my head against it enough times that I may need to refactor the entire thing to provide a different approach.

Oh well, that’s what branches are for, right?

The important lesson I have is that, and I didn’t know this because I am a complete newbie, Flash and ActionScript 3 runs code synchronously (I think.) This was a problem with the initial way I was refilling pieces, because I essentially had a for loop that would check every single spot on the board, and if there was no sprite within that spot, it would start the animation to move all pieces above the empty square downward to fill the empty spot and create the new piece. However, if you have two (or more) empty squares on top of each other, the new piece creation happens simultaneously and you have stacked pieces in the same square.

As you can tell, I am not very experienced with puzzle game animations!

Octocat Emerges

On November 19th, Wayne sent me an email where he sketched out the alien: he had taken the Octocat, of GitHub fame, and turned it into the alien monster attacking the Earth. It shot lasers from its eyes, it was adorable, and I think it gave me a bit of extra motivation to see this project go all the way.

Aw, aren’t you a horrible little creature?

Final Stretch

It feels like I’ve left out a lot of details, but that’s because the entire month felt like a blur. I was constantly trying to fix our animation problem while building out the HUD (score, timer, etc) and the functionality to power the HUD. Wayne was churning out all of the necessary art assets for the game, and it was starting to come together.

Eventually, we decided that we weren’t going to complete the game in time, and we were alright with that. We were both willing to continue working on the game at a more leisurely pace after the deadline had passed, and that’s one of the side projects I am really looking forward to.

At the end of the day, the v0.1 build of Octocat Attacks, as in the one we’re submitting to GitHub Game Off, is a very incomplete game. We have an incomplete puzzle engine, no audio, and our content is far from complete.

However, we got it out there. We took the effort to start our project and bring it this far, and we’re continuing to push on. I’m very happy with how the game looks right now thanks to the hard (and amazing) work that Wayne has put into his pixel art, and our game is functional, which is a lot more than I expected when we started!

It’s been a really fun and educational experience to build a game from scratch, and you better believe that Wayne and I are going to continue developing games.