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!
