Global Game Jam, January 27-29th 2012

This was the fourth annual Global Game Jam, and I've been lucky enough to attend every year - it's an event I look forward to.  Aside from the usual "achievements" (optional restrictions to help focus your game designs), this year's theme was pretty simple: an ouroboros.

This year's theme. This exact thing.

Luckily, an image such as this can be interpreted several ways, and the game pitches reflected that.  The team I ended up on took the theme a bit more literally, borrowing a concept from American folklore: the hoopsnake.

What Went Right

Our goals for this project were to build on what has been successful in previous years: keep the game simple, and keep the humor high.  In that regard, we did quite well.

Hoopsnake! is a side-scrolling platformer, utilizing only one button as the game mechanic.  The hoopsnake constantly grows larger; grow too large and he'll fall apart, Game Over.  Press the space bar for him to take a bite of himself to get smaller; go too far and he eats himself out of existence.  You want to be small to fit through narrow passages, and you want to be large to be able to catch yourself on ledges after being propelled up by spring-coil copperhead snakes.  Eat all the doughnuts on the level to continue.

The humor is best exemplified by the soundtrack.  When you hit a spring-snake and are propelled upward, the game goes into a bullet-time state, and a bit of The Ballad of the Hoopsnake plays (also available as a separate track).  The overall goofiness of it earned us a standing ovation during our presentation.

What Went Wrong

Our team of programmers (myself included) didn't feel particularly strongly about a game engine, so we tried to pick something that we could all share.  Ultimately we settled on Java, using MarteEngine.  We made it work, although it's not the best engine for the design we had.  Most notably, MarteEngine is a tile-based platformer engine, where something like Hoopsnake! may have better benefited from something smoother or vector-based, like Flash.  As such, we had to get around this weird problem of the hoopsnake effectively falling down stairs, instead of rolling down a hill.

I felt the art could have been crisper, as well.  MarteEngine uses sprites, and one of the issues I worked on was making the animation of the hoopsnake work.  There was a lot of futzing with sprite animations and scale percentages, and ultimately we couldn't get it to look the way we wanted - but it doesn't matter so much because the hoopsnake rotates so fast that you'd barely notice the animation anyway.

As is usually the case with these projects, it would have been nice to have a bit more time at the end to polish what we had and focus a bit more on level design.  I feel it looks a bit clunky and rushed, but then again, it was only built in a weekend!

What to Improve

I think the successes of Hoopsnake! outweigh its shortcomings.  I only wish I had the time and money to learn several game engines to be better prepared for working with other programmers, or to invest into a single game engine, take the lead on the project, and be able to teach others.  But, that's more of a personal problem, and I enjoy tackling this problem with more game jams.

Download the Hoopsnake! project at this page.

Cardboard Jam II, October 8-9th, 2011

Back at MIT for another Cardboard Jam (board and card games).  The theme chosen for this jam was "occupy" - this was in the middle of all of the "Occupy Wall Street" business going on at the time.

Our group's initial brainstorming included expanding on multiple definitions of the word occupy, such as occupation (jobs) and occupying space, which is the direction a lot of other groups went in.  We moved toward a more current-event angle, the genesis of what we uncreatively called "Occupy Boston Game Jams".

An early iteration of our game.

The idea behind the game is that the players are leaders of an "Occupy" protest movement, and you have to balance between recruiting new people to the cause, keeping everyone engaged and fed, maintaining a positive public image, and not getting dissolved due to apathy or police intervention.  It's a cooperative game and the players have roles with certain bonuses.

We hit a snag early on where the gameplay simply wasn't engaging, and we weren't quite sure how to fix it.  So, in a bizarre move for a game jam, we opted to abandon the project for a majority of the weekend.  I think the idea was to "sleep on it", and hopefully have a kind of epiphany like you do after a good night's sleep or when you're in the shower.  Luckily for us, that's what happened!

In the interim, we spent some time futzing around with some other prototype ideas - one being a game where the battle mechanic involved poker hands.

A playtest.

One of the big changes we made when we finally decided to give the game another try was switching the dice that determine success/failure from d20s to d12s.  Partly because you rarely see d12s used, but it helped with the overall statistics. 

Overall I think the project was a success, despite the actual development time spent on it was about half of what it should have been. 

A (little more than a) Year in Review

So, obviously, the website and blog have endured a bit of neglect.  And I'm updating it now, which indicates something major has happened which prompted me to make such updates.  So, here's an outline of some of the major stuff that happened since the last time I updated the blog:

• The last post I made was in April of 2011.  I didn't mention it here, but I was let go from QUICKHIT that previous February.  So the jam occurred as I was looking for new work.
• I found such new work at 38 Studios, in July of 2011.  Hooray!  Again, I worked in QA, for their Digital Presence team, on their websites for their game Kingdoms of Amalur: Reckoning^TM  (released in February 2012) and the expanded lore site Amalur.com.
• Another Cardboard Jam was held in October.  I'll be making a separate post about it.
• The Global Game Jam was held in January of 2012.  Again, separate post.
• 38 Studios was hit by some financial troubles which, if you follow game industry or New England news, you might have heard about.  I'm not going to go into detail about it (I'm not even sure if I could), but I felt this article on Gamasutra provided a mostly fair synopsis of the events.

So, as of this writing, I'm currently looking for a job again.  The website and my resume have been updated with current information.  I'm fairly optimistic I won't have to wait too long for my next job.  In the meantime, I guess I've got plenty to write about.

Cardboard Jam, April 9-10th, 2011

We had another Boston Game Jam this past weekend, this time focusing on board and card games. A bit of a departure than our usual video game creation, and it really had a different flavor because the weekend was all about game design. Jeff Ward wrote a quick write-up that highlighted these points, so I'll point you there instead of stealing/paraphrasing him.

Our Project

I worked with Gabe Warshauer-Baker, Kevin Jackson-Mead and Nick Troy on a project that Gabe had pitched. The concept was "Other People's Tools", with the inspiration coming from a mechanic from the game Caylus - the idea being that you gain some residual benefit from letting other players use "tools" that you own.

First Prototype

Here's a sample of cards that represent our first stab at creating the game. For resources, we played with a set of Looney Labs' "Icehouse" pyramids because, well, we happened to have a set.

The white cards are the tools, and the yellow cards are the objectives a player has to meet in order to win. Each player was dealt a hand of 3 tool cards and given 1 objective card. The players presented their tools to the group all at once, and play went around to each player, where they selected which tool they wanted to use. When the round ended, if a player happened to fulfill their objectives, they won and the game was over.

We started with the tool cards on the left, which came to be known as the "gather" tools. They consisted of taking the appropriate number of "triangles" from the resource pool at no cost, and the tool's owner received a triangle for their trouble as indicated on the bottom of the card. We found quickly that there wasn't a lot of strategy in which tool you offered the others - you picked the tool that gave you a benefit that matched your objective, and hoped that the others would provide a tool to help you along, as well. Often you had a choice of three tools that didn't really help you in any way, so the choice was kind of "meh". Players were focused more on meeting their objectives instead of providing helpful tools (which we meant to be our core mechanic).

We played around with other changes - making the objectives private knowledge, more diverse objectives, even adding an "Apples to Apples"-style system of presenting the tools anonymously. By the time we got to adding the "conversion" tools - which we knew we needed - the prototype was dying. (Notice that there aren't any benefits listed on the conversion tool cards in the middle column above.) The biggest problem was that of divergent goals. It boiled down to "I want to help you win (by giving you a tool you want to use), but I don't want to help you win (because I'll lose)." So, back to the drawing board.

The Game Takes Shape


Our goal for the second prototype was focusing on the basic premise - to provide the most useful tool to the other players (and be rewarded for it). So, the tools became the resources, with their value determined by the core "elements" they provided and by what the other players bid on it to claim it, poker-style. Players cannot bid on their own tools (it is forbidden among gnomes), but this was balanced because they were holding the auction and gaining income. At about this time we were also trying to add a bit of flavor with a story, which we settled on a group of gnomes in a silly, steampunk setting. So each tool provides one or two of four elements: whack, hole, cut and fuse. A basic hammer provides 1 whack, where a hammer-saw could provide 1 whack and 1 cut. And so on, up to the Semi-Automatic Blade Pipes and such.

The singular objectives were gone, and now the players were using these tools to build "projects". The projects were priced such that a player would need to use at least two tools to claim it, and they provided additional income. The economy was changed to a single currency (coins, since we were using pennies). Whoever had the most coins at the end of the game won.

At first, we determined the end of the game simply by exhausting the project card pile. But, then we added a lot more projects, which would have dragged the game on. We tried stopping the game when a player built their fourth project, but an interesting wrinkle came up during playtesting. One player had 3 projects and was poised to built a fourth, but he didn't have enough money to win the game. So he declined, postponing the game further until someone else could gather the tools to end the game. Game time was already averaging an hour, so to curb this unnecessary prolonging of the game, a "Game Over" card was added randomly toward the bottom of the project deck (Tourist Season, when the humans flock in to buy up the gnomes' projects).

What's Next

And so, we are left with our game, Gnome Economics. We plan to complete the cards by adding all of the names and flavor text, and get them set up in a file with graphics that can be printed.

Overall, I think the project was fairly successful. I'm not much on bidding games, but the series of checks and balances inherent in our auction system (created almost by accident) keeps the game from favoring any one particular strategy.

If there's anything that "went wrong" during the game's development, it's that the game is too long for us to get a lot of iterative game testing done. The mechanics of the game are simple, so a lot of our adjustments were minor value tweaking. And an hour-long game isn't too shabby, considering that about how long most modern board games are expected to last. But we found that playtesting among ourselves was slow, because we were discussing the game as we played it, and playtesting with others was slow because they were analyzing the game, trying to figure out the optimum strategy and calculating expense versus returns (which is to be expected - this was a room full of gamers, after all!)

Keep an eye here, I'll make an update when we get the files finished so you can try the game out for yourself!

HTML5 Tools Jam

On the weekend of January 8th and 9th, Darren Torpey and Darius Kazemi hosted the first Boston Game Jam of 2011. Which is a bit of a misnomer, since this was a tools jam. The idea was to spend some time working and collaborating on a bunch of tools using HTML5, with the idea being not only to learn about this relatively new technology, but to make some ready-to-use tools in the upcoming Global Game Jam.

This was an intimate affair, with only about 10 people participating, and once again held at the Singapore-MIT GAMBIT Game Lab in Cambridge. The projects were interesting - it's really cool to see this technology work "in browser" instead of going through the rigmarole of compiling and various file types and stuff. I can't claim to be an expert in HTML5 or even Javascript, but I'm learning, and the potential here is really exciting.

My own project was inspired by the Akihabara engine, specifically the "toys" that are built into it, which provide the framework to create various arcade games. My goal was to build a similar toy to create card games - partly because card games are easy and cool, and partly to share since people will have the opportunity to create card and board games at the Global Game Jam this year. Darren and Darius quickly talked me out of that, since there's a lot of overhead into learning and using the Akihabara engine. So the project evolved into creating a Javascript library, with the cards being displayed in browser using CSS3.

By the end of the day on Saturday, I had most of the framework written, designed and tested out, and Darren had a crude card system working early on Sunday. The goal was set to put together a solitaire game to make sure the system would handle most everything that someone might expect it to, and by the time presentations were due, most of it was in place.

There are a few things left that I'd like to get done before I call it finished. One, finish up the functionality. Two, clean up the code and make sure things can be written easily (more for my own benefit, especially on the CSS side). Three, make sure it's all documented. Then, at least, we should be able to write card games with a standard poker deck.

My ultimate goal is to make the library more extensible and abstract, so that someone could write any kind of card game. This goal kind of got in my own way...I had grand plans for this project, when in reality it isn't all that complicated. But at the very least, I'll have the libraries to work on my own games. I'll be sure to post again when I've got something ready to show.

Special thanks to Darren who worked with me on the project on the second day, to Darius for his occasional help with Javascript and Git, and to Jonathon Myers for letting me use his spare laptop. :)

New Year's Post

It is lame for me to make New Year's resolutions a week into January?

Yeah, probably.

Either way, resolutions seem so final, which is perhaps why people rarely follow through with them. So here are a few of my plans for 2011 - and the nice thing is, plans can change.

In 2011, I plan to:

• Update my website more often. Hence this post. I know I've been slacking for the last few months.
• Learn Unity. Like, really learn it, and not just keep saying I will. The makers of the Unity 3D engine had a contest where they'll give a Pro license to 4 winners to create an idea they tweeted about. I doubt I'll win, but it's still a noble goal. I was even a little reluctant to share - afraid someone would steal my multi-million dollar idea, of course - but since it's now a matter of public record, here it is.
  
• Make a game I can share. The machinations for this one have already begun, which I will outline shortly. I want something tangible and recent, and not just half-baked game jam games or inaccessible student projects.
• Continue being awesome.
  
• ...okay, plan to BECOME awesome.

That's good enough to start with, don't you think?

"Immigration Jam", August 20-21, 2010

This weekend was a game jam even put on by Alex Schwartz and Darren Torpey, as part of Boston Game Jams - a group seeking to foster a sense of community among local area game developers. We met at the Singapore-MIT GAMBIT Game Lab for a weekend of game development fun.

The reason the theme was immigration was in honor of fellow WPI student Yilmaz Kiymaz, who's looking to come back to the United States since his student visa expired. So, many of the games developed had to do with immigration, ranging from the satirical to the tangentially related. Keep an eye on the Boston Game Jams site to see them and the presentations!

Fun fact: This particular game jam had an exceptionally large number of participants dealing with audio. Usually it's the audio people that are the hot commodity; this time around it was some of the artists who were juggling their time between groups. So at the very least, this was a very good sounding jam.

I ended up in a group with Greg, another WPI alum, as well as three Berklee students, Leah, Kristen and Lawrence. The original proposal was a combination of two similar ideas, one featuring plants in garden, and one about the Chinese Rhino beetle (I think he meant the Asian Longhorn beetle). Both ideas had the central theme of balancing an ecological system, with the idea of migrating species presenting a challenge in maintaining the balance. I added the suggestion of styling it more as a strategy board game. For lack of a better name, we've dubbed it "I-Migration".

We chose to use the Akihabara game engine, which is a relatively new system that's essentially a set of Javascript libraries to access the Canvas element of HTML5. In short, the entire code of the game is on a webpage and runs in-browser. (Well, except Internet Explorer, but that's because it just sucks.) Darren gave a talk about it at last month's Boston Indies meeting, and has been working with Darius Kazemi to provide documentation and tutorials for the engine.

I felt the decision to use Akihabara was a good one. Because it's basically Javascript, it's fairly easy to pick up and learn (despite the lack of in-depth documentation, although Darius and Darren's efforts are a good start). Because it's HTML5, compile time is negligible, and we can use things like Firebug to get real-time debugging information. Also, adding art and audio assets isn't complicated either. At the last Global Game Jam, I mentioned one of my great regrets was not being able to get sound working in our game. This time, music was one of the first things we had working!

There was a bit of a learning curve where the two programmers of the group were essentially learning a new game engine, and as such the initial struggles were getting the game to load art assets, and yet most of the game came together within the last few hours. The other problem came because I shot myself in the foot. Despite the fact that we were working in the GAMBIT Game Lab, we didn't have access to their equipment, so the jam was bring-your-own-computer. And I don't own a laptop, so my role on Saturday was mostly relegated to that of design and support. And while I love the design aspect of it, there comes a time where you can't tie up the people actually creating the product. Thankfully Greg was able to secure another laptop for me on Sunday. But even if I had a system to work on the whole weekend, another issue was source control. It wasn't a big problem since it was effectively one programmer working on one file, but there was a headache when I was able to contribute code and it was a matter of hunt-and-peck-and-copy-and-paste. But that's understandable, given the short time span and jam-mentality of "throw everything in a bucket and just get it to run".

I'm pretty proud of what our group was able to accomplish at the end of 36 hours. It's effectively a vertical slice, offering one round of play. It has some awesome art and sound elements, thanks to our talented Berklee members. But, due to time constraints, it's not as complete a round as originally designed. And it's not as automatically as I'd like - there's a lot of hand-holding, and even then the user doesn't really have an idea of what's going on unless they pay real close attention. But hey, given the ease of development, we may still poke at this some more, and move closer to a complete game.

Another interesting twist to this whole weekend was the food. Vickie Wu, Darren's fiance, had a one-woman "food jam", making a variety of snacks and tidbits for us through the whole weekend, which was great because otherwise the official "meals" were all pizza. Delicacies included berry smoothies (yum), peanut butter/banana/yogurt smoothies (more like "thickies", way too sludgy - the only real misstep of the weekend), Waldorf salad in lettuce cups, two different kinds of hummus, freezer pops and ants on a log (reliving childhood!), microwave s'mores (marshmallows need to be fire-roasted, but they still tasted good), frozen coffee mocha drinks, and strawberry/mint soda spritzers (I could have done without the mint - too earthy and not minty enough, plus the cup full of tiny leaf-chunks is off-putting). I'm not entirely sure why she did this (other than "she wanted to"), but I'm glad she did! Plus, Yilmaz brought some honest-to-goodness real Turkish Delight. I had heard the closest thing to it was jellybeans, which it was, but a little chewier, but not as chewy as say, candied fruit. It's also flavored like almond and had almonds in it (though there was a mint variety), and completely covered in powdered sugar or coconut. Of course, the only time anyone's ever heard of Turkish Delight is from The Lion, the Witch and the Wardrobe, so it's neat to actually try some.

In conclusion, as much as I love game jams, I'm not 100% sure at this time if I will participate in the next Boston Game Jam, unless I can definitively secure a laptop to work on. I think everyone did a great job and I had a fun time!