MIT Cardboard Jam, May 3-4, 2014

That's right, another game jam for me!  It appears as though the MIT Game Lab is looking to run game jams more often during the year, and of course I had to take the opportunity while I could.

A couple interesting quirks about this jam compared to others I have attended.  First of all, there were quite a few people who showed up who have either never done a game jam before, or weren't really part of the game industry.  I suppose I've been so used to working with similar people, but it's refreshing to see people who just like games come together and try something new.  Secondly, the jam organizers spent a lot of the first morning running through rapid-prototyping workshop exercises, something I hadn't experienced before. 

For example, one exercise involved using Grow-a-Game cards, where everyone spent 15 minutes in groups coming up with a game design based on a few concepts, and slapping together a prototype for another group to play.  I particularly enjoyed this exercise because it's just fun to discuss game ideas with some constraints to focus your mind.  The trick was, you want to flesh out an idea enough to be able to explain it to someone else and have it be moderately fun and/or interesting, but the fast turnaround time didn't allow for much of that.

Our Game - Green Team Revolt

The theme for this jam was "cooperation".  Simple enough, I particularly enjoy the cooperative style genre of board games.  A couple of minor constraints where to avoid the over-tread genres of sci-fi, infrastructure, Euro-game conventions that a ton of board games have already done, and to avoid "quarterbacking", i.e. avoid having one person dictate the actions of the other players.

With that in mind, I worked on a project we called "Green Team Revolt".  The idea is that the players are the Planeteers, working together to stop a rogue Captain Planet from his rampage while simultaneously protecting the environment.  It's a goofy enough concept to be fun (even if it's a little copyright-infringy, but it's a game jam, who cares), and there's plenty of room in the game design for us to try out lots of ideas.  The central game mechanic is that everyone plays a card in order into a queue, which when it's resolved, ends in a certain amount of damage against Captain Planet and, depending on the type, causing some collateral damage on the current location of the players based on a separate deck.  The idea is to defeat Captain Planet before either the environment or any of the players are taken out.

As we left it, there were plenty of ideas we could have tried to see if it would make the game any more fun and/or difficult.  The players tend to win after a few rounds, but at a significant cost to the environment.  We hit that point of the game where we're needed to come up with a whole bunch of cards to fill out the decks, which is time-consuming and would require a lot of playtesting to weed out all the bad ideas.  Still, I think it makes for a fun game.

Check out our postmortem presentation here (our group is first, starting at 3:54):

Global Game Jam VI, January 24-26, 2014

Once again it was back to MIT for my sixth year participating in the Global Game Jam.

This year, the theme went back to phrases with "We don't see things as they are, we see them as we are."  I can see how such a vague phrase opens up creativity, as opposed to the last couple of years (an ouroboros and a heartbeat).

The logistics worked slightly differently as well.  We were back in the same old familiar classrooms in building 26, though the big change this year was that not all meals were provided.  This makes some sense, as there's usually a lot of leftover food anyway and I'm sure they're trying to save money.  Still, walking back to Kenmore Square to find lunch in the bitter cold was something I would have preferred not to do.

I ended up on a team where the pitched idea had to do with two players navigating a maze, where one player could see objects the other player couldn't, and vice versa.  We spent quite some time talking over the design, figuring out what there was to do in the maze.  For example, one idea early on was to have a player-monster chase the other player, but the cameras were attached to the opposite character.  (Luckily that idea was dropped...thinking about it, that probably would have been a horrible experience to play.)

The idea coalesced into what we named A-Maze-ing Co-Op (brilliant, I know).  The artistic theme we were aiming for was this kind of temple exploration, one player was a human and one was a robot - we ended up with only the floating robot due to time constraints - the human could be hurt by traps he couldn't see but was the only one that could disarm them due to his opposeable thumbs.  The robot's job is to seek out and mark the traps so the human knows which areas to be cautious around...and the robot can't see the trap keys, for whatever reason. The traps and keys take the form of pedestals with certain shaped holes, of which there is a matching key elsewhere in the maze.  The idea is to disarm all of the traps and then both players need to exit the maze together.

What went right: The scope of the actual gameplay was kept fairly small, so we were able to get a functionally-complete game done by the end of the weekend which was moderately fun to play.
Our original plan was to have each player on their own client, with the games connected over the network.  I was trying to get a very simple server-client model set up in Unity, but by lunchtime on Saturday, whether it was faulty code or the inexplicably slow MIT network, it just wasn't in the cards.  Thankfully the gameplay did not require separate machines, and I'm glad we made the decision to alter the game into a single-machine split-screen game with each player using their own set of controls on the same keyboard, that we could focus on the game and not trying to get network code to work.

What could go better:  Source control was a huge headache for us.  We opted to use GitHub, since free is good, but we only had a small amount of experience using it between us.  Git doesn't provide a lot of useful intuitive information when it's performing its actions.  We wound up with 3 repositories, 2 of which were false starts just trying to get a mostly empty project established for us to share.  I believe in source control, and I know how it works fundamentally, but I'm going to need to work with Git some more to get comfortable with it.

What to do different: Perhaps another half-day would have been nice to give the game some polish, and had some other people playtest it.  We had one of the audio designers ask us if we wanted sound for our game - that would have been nice to have, given some better planning or a dedicated sound person on our team.  One of the projects I'd like to work on coming away from this is to develop a procedurally-generated maze in Unity, since this and last year's project would have benefited from that from a replayability perspective.

Links:
The project page on the GGJ site
Play the game here!