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. 

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

"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!