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!

Global Game Jam V, Jan 25-27, 2013

Once again, it was Global Game Jam this weekend!

I was again jamming at MIT, though now that the MIT Game Lab has dropped the GAMBIT part and moved onto the main campus, the logistics were a bit different this year.  The presentations were held in one of the auditorium-classrooms, and everyone jammed in some of the classrooms in building 26.  They were pretty lax about the food, which was nice, compared to the Boston FIG Jam which was held in the same rooms.  The funny thing is, I've only been to MIT a handful of times, but every time has been in these same classrooms - despite the large campus, I'd think these were the only classrooms available in the entire school.

The theme this year was another simple one - a heartbeat.

I had brainstormed a bit with one of the sound guys there, and ended up with a game pitch where sound factored heavily into gameplay, because of course.  However, he decided to go with another project, and I ended almost by myself, though awesome sound designer Dan Perry opted to join the project.  I had worked with him a couple years ago on the Punk is Dead project.

Sound Maze

Yes, a rather uncreative working title.  The game is a first-person maze/labyrinth navigation game.  It takes place in two parts - the first half where you maneuver around normally, as you might expect with any videogame.  When you grab the icon in the center, the game shifts to the second phase, where you have to find your way back out in near-total darkness, using your sense of hearing to guide you.

There are two mazes here, so finding your way back out is not as simple as retracing your steps.  The original pitch included the idea that the "visual" maze remained visible while you had to navigate the "audio" maze - open passageways might be blocked, and you could walk though some walls on the screen.  Luckily, the overall game design was simple enough that the prototype was finished fairly early on Saturday, and we were able to playtest it.  We had found that our progress in teaching the player to navigate by sight was negated by literally changing the rules midway through, and it was very frustrating and confusing trying to push in certain directions fruitlessly.  So, we changed it to darkness, where your sense of sight was instantly disabled.  The goal object in this half emanates a heartbeat, which gets louder as you approach - this came from a thought I had about not approaching a sound, but rather you hearing your own heart beating in your chest as you approach the end.

A lot of the tweaks from there on involved adding hand-holding for players.  None of the feedback systems (player movement, sounds when approaching walls, sounds when hitting walls) are terribly robust, so a player can get lost or frustrated quickly.  So, the "sky" was set to a very dark gray rather than black, so there is a little bit of light available.  We also added lantern flashes, crudely added as the walls lighting up, to give the player a brief glimpse of where they are.  We also found, with the mazes I had slapped together, that reaching the goal in the dark half required the unintuitive task of moving away from the heartbeat (where the goal was) before rounding a corner and heading back.  This was fixed by altering the hidden maze a bit to avoid backtracking.

What Went Right: Thankfully the design was simple enough that I felt the game was adequately complete early on, allowing for time for tweaking rather than trying to get it to run at all.  Since I decided upon a 3D first-person perspective, I felt Unity was a good engine to develop in.  While I don't have a lot of experience developing in Unity, I know the basics, and I felt this was a great opportunity ti dive in and have a "trial by fire".  And because I was the only developer, source control wasn't a great concern as everything was saved on my machine.

What Could Go Better: That being said, ideally I would've liked at least one other person, familiar with Unity, to have been on the team.  A lot of really basic things probably could have been solved early on (and special thanks to Michael Carriere and Alex Schwartz for helping me with such issues) that could have left time for more feature development.  An artist of some type would have helped too, whether it was by making the game not look so ugly, or perhaps helped with the lighting to aid gameplay and provided a better sense of atmosphere.   One of my stretch goals was to include randomly generated mazes, which might've happened if someone else was there to share the burden of development.

I'm really pleased how the game turned out, though, despite the prolific "programmer art".  Further tweaks that could be made are cleaning up the movement and audio feedback, sound optimization, and the aforementioned random mazes.

Another nice thing about programming the game in Unity - not only does it run on PC and Mac, but you can export a web build!  So you can play the game right here - like I said, the sound needs optimization, so it'll take a while to load...please be patient.

Boston Festival of Indie Games - September 22, 2012

Quite an exciting time this past weekend as MIT was host to the inaugural Boston Festival of Indie Games.  The festival was an effort put on by us Boston Indies to showcase the development talent available in this area.

I was asked to be part of the curatorial committee, which I was flattered and quite pleased to be a part of.  It wasn't much - just playing some of the submissions and deciding whether or not they should be included in the festival.  Unfortunately, I didn't get to see much of the festival proper, since there was a Game Jam to participate in!

The theme was "independence" (since it was an Independent Game festival, after all).  The group I worked with created a game we called Choice Blocks.  Effectively a Tetris-clone, but the idea was to include an "independence of choice", by allowing the players to augment their gameplay by choosing which blocks were included in the game.  After some amount of time, a selection window would appear, and players would select from some randomly-generated pieces using the points they've earned, much like the deck-building mechanic of Dominion.  These pieces, while awkward to place, would earn more points.

The game was written in C# using the XNA framework.  I worked on the piece generation bit, as well as the user input and state transitions.

The festival was only one day, which meant the game jam was only one day.  Even then, we were presenting at the end of the night, so we had at best 8 hours to create a game.  This was a blessing and a curse.  The biggest issue was that we didn't have time to implement the "choice" part of the game, so in the end we remade Tetris but a randomly-created piece will occasionally fall.  It turns out that even then, it throws an interesting wrinkle into how you play Tetris.

What Went Right: The time constraint helped because we really had to keep the scope down, and we didn't introduce a lot of risk with complicated, untested features.  I was actually a bit surprised that all of the groups made a mostly functioning game by the end of the jam, which I can't say about other jams I've participated in.

What Went Wrong: This isn't so much "wrong" as it is "somewhat disappointing".  Of course the big thing is that we didn't "finish" our game, at least enough in my opinion to distinguish it from regular  Tetris.  I think with the extra day of the usual game jam we could have finished our basic vision, added some sound, and cleaned up some stuff like the sticky controls and scoring system.  I suppose it was a good thing that we Googled "open source XNA Tetris" to get the ball rolling quickly, but it feels a little hollow that we didn't really create anything new.  I mean, creating a platformer is one thing, but Tetris by itself is a well-established game.

Another problem, one that we couldn't really do much about, was the logistics that we were in a random classroom at MIT, and therefore couldn't have food or drink.  We plowed through the day with only a short time set aside for a couple slices of pizza for lunch out in the hall.  It just didn't feel as fun and relaxed as other jams.

That said, I'd do it again (you know I'm a sucker for jams), and I'm looking forward to next year's FIG!

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.