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!
Tuesday, April 12, 2011
Monday, January 10, 2011
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. :)
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:
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.
Subscribe to:
Posts (Atom)