Global Game Jam VIII, January 29-31, 2016

Another year, another Global Game Jam!  One of my favorite events of the year.  This time was different in that I came to this one with a team already prepared.  We had met a few weeks prior in preparation of the Cartoon Network Game Jam (much more about that later!), and we were looking at the GGJ as a practice run for how well our group would work together.

This year's theme was "ritual", which is an awesome word to build around since it can be interpreted many ways.  We opted to go with a more traditional interpretation, where the player would perform a series of small rituals/tasks.  From the set of diversifiers, we focused on not using any dialog or cutscenes within the game, and creating a non-violent game.

What resulted is Life of Lumby, where you guide the titular character through various stages of his life, performing a set of rituals to aid his community and gain favor with deities.  

Download and play the game here!

On the positive side, the game looks and sounds great.  It was an interesting challenge to have created a kind of game that's more of an "interactive experience"/story-based game than anything technically complicated.  As such, we didn't really have much experience telling a story through game, so our design was a bit disjointed and required us to take some time during lunch on Saturday to flesh out some of the specifics.  Additionally, while we managed to get all of our minimum design requirements in and (mostly) working by the end of the jam, our cohesive story and overall vision didn't quite make it through.  For example, one idea we focused on was to have Lumby ascend and reincarnate once he's completed his rituals (and his life)...that's only hinted at with the white-out at the end of the game.  We realized we could have done more to incorporate additional ideas - such as more NPCs - even if they would have been programmer art.  

Overall, I'm pleased with how everything turned out.  I'm particularly glad how well our team has gelled over the last few weeks - be on the lookout for more great stuff from us soon!

Ghostly Garden and PIGSquad Summer Slow Jams 2015

This summer, PIGSquad hosted a series of game jams.  Dubbed Summer Slow Jams, since they lasted a week as opposed to the 48 hour format I'm used to.

The goal of the first jam was to encourage people to make a game that they could easily present in the many events PIGSquad hosts, akin to a convention or festival.  The idea was to, in addition to the game, create flyers, cards, Twitter accounts, and other similar promotional materials.  The creative themes were taken from the themes of OMSI After Dark.  I met some guys during the kickoff event, and our team started brainstorming with the theme of "Explosions".  As we continued, the focus moved away from that as we incorporated the themes of "Seed" and "Spirits".  We ended up with our competitive gardening game, Ghostly Garden, which you can download for yourself here.  It was very encouraging to go from "barely tested controller input" to "we ran a full single elimination tournament among the attendees" in a matter of hours at the jam showcase!

The second jam was to utilize the tools used by Pixel Arts Game Education (a local non-profit that runs game creation camps and classes for underprivileged youth).  The tools are free and browser based, and the goal was to show the students what was possible with these tools from experienced game developers.  The creative prompts were educational concepts and various social issues, distributed from a random generator using said tools.  My prompts were "Projectiles and Trajectories" and "Air Pollution".  I worked by myself on the project to come up with Calamitous Cleanup!

The third jam was intended to create 4-player local multiplayer games to put onto Flint and Tinder Studios' Tinderbox, an arcade cabinet prototype to showcase locally made games.  In addition was their public rollout of ProgFrog, a blog where anyone creating any kind of project can post updates of progress - plus it was an easy way to pull the latest jam builds onto the Tinderbox.  Our team decided to use the time to polish Ghostly Garden up from the first jam (and we had build it as a multiplayer game to begin with knowing this jam was on the horizon).  So there is a 2 vs. 2 player mode available in the game.

I presented Ghostly Garden at the Portland Mini Maker Faire this past weekend at OMSI, and we're planning on adding more features and more channels of distribution.

In the meantime, I've also been working with someone else on a mobile puzzle game prototype.  I'm not quite sure what I'm at liberty to share, but I think we're close to opening it up for alpha testing - so keep an eye out for more information about that!

Global Game Jam VII, January 23-25, 2015

There have been some changes in my life recently, the chief one being my move to the greater Portland, Oregon area.  But that doesn't mean I was going to miss out on another Global Game Jam.  It was through GGJ that I was able to find the local Portland indie game community PIGSquad.

There were a couple major changes to how PIGSquad runs their game jams over how I'm used to them being run in Boston.  First of all, our jamming space at the Art Institute of Portland was open for the full 48 hours, whereas in Boston we were encouraged (and required) to leave at night for sleep.  Thankfully, I live fairly close to Portland, so I had no problem commuting back and forth.  The last couple jams in Boston required me to venture back and forth for an hour's drive each night.

When we used to form groups, we would get the jam theme, come up with ideas, and then pitch them to the entire group.  We would then form groups based on who wanted to work on certain projects, making sure each group had an appropriate spread of disciplines.  This was great for starting off with a relatively clear vision and being passionate about the project you're working on.  The tradeoff here was group members, with varying degrees of experience, sometimes struggled in finding a common technology to work with.  In Portland, we started off forming groups first, and the theme was presented to us afterwards for each group to then come up with their own idea.  I can see how this can be an advantage to some people, who already know who they like to work with (if they like to work with anyone at all), and you can form groups around the technology being used.

It was this group forming first that I think my group hit a bit of a snag.  The diversifiers (optional constraints to use on your project) for this year's jam were released early, and one that interested me the most was "Chimera", to make a combination digital and non-digital game.  It was relatively easy to start rounding up the people who expressed an interest in creating a board/card game, but since the computer component, and the design of how the pieces were to interact, was so up in the air, we recruited quite a few more people for the computer part than was ultimately necessary.  It's not that everyone didn't contribute in some way; I just personally felt we could have been more efficient as a group.

Our game -  Space Goats: Galaxy to Galaxy

The board game half of the group ended up designing most of the game, and the name must have sprung up as a kind of joke and ended up driving a lot of the aesthetics.  The game is presented as a card game for 2-6 players.  You draw Resource cards to boost your defenses, and Action cards which help you earn more Resources or redistribute what you already have.  Starting with the last player, at the end of your turn you then use the computer component (we designed it as an app, so a mobile device could be easily passed around between the players), where you set off a bomb with a timer to explode after a certain number of turns.  The bombs can either destroy a certain type of resource, or destroy half of your total resources.  There are also options to delay the timers of the bombs already in the queue.  If you don't have a particular resource available to destroy, you can substitute 2 of any other resource to make up the difference.  If you don't have any resources you are out of the game; the last player remaining is the winner. This results in a very fast paced game, as the longer it goes the more likely it is multiple bombs will explode on a given turn.

What we did right: I'm glad we ended up with a overall simple game. It's quick and has a goofy charm, with Space Goats and Rocket Chickens and such.  While there can be a bit of strategy involved, particularly with small number of starting players, the real joy is bombs exploding and reacting to the consequences.  While modern game design eschews eliminating players from participating, the game is fast enough that the next game is never too far away.

Looking back, it's probably for the best that our digital component is as simple as it is.  When I first heard about the diversifier, I was trying to brainstorm ideas on how to incorporate a board game into a complex digital game (like an FPS).  We talked to some people present during our recruiting phase about the possibility of augmented reality or code readers.  Even early in our design phase, we discussed ideas about two simultaneous games, and how the digital players could interact with the board game players and vice versa.

What could go better: As I mentioned before, we didn't start with any kind of pitch or vision, so we overbuilt the team.  I'm happy to include first-time jammers, and certainly you're going to get varying levels of experience.  I guess I was just a little disappointed that the digital component could easily have been completed by one competent person in an hour or two.  I think I was expecting more from the digital side, but that might have jeopardized the project as a whole.  It's a learning experience, and good to remember when team-building for next time, if anyone wants to do a hybrid game.

I also would have liked a bit more wider coverage of the distribution of the digital component.  we designed it and worked around a 1080p resolution Android device.  I would have liked to have seen it on an iPhone (I didn't realize you needed an actual Mac to get that far; something I probably should have learned long ago), and the screen gets funky when trying to run the stand-alone version.

Check it out for yourself here!

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!