The theme for this year was "deception" and "abstraction", as well as the local constraints of "rain, plain and/or Spain". The project I worked on was called Define Yourself. The original pitch was that you started out as some abstract avatar, and your actions at the beginning of the game determined how the character was defined until you were much more fully realized. We were throwing back and forth ideas as we discussed game design on Friday night, when we developed the core concepts of an exploration space. Eventually concepts crept in borrowed from fellow programmer/developer Darren Torpey about an idea he had about a Facebook college simulation game. The game, as it stands now, is more that as a freshman entering college, you are very loosely defined as a person (abstract, if you will), and the choices you make in college - which classes you attend, how often you socialize, etc - define who you are by the time you graduate.
I think I'll move onto a list to outline what went right and what went wrong in typical postmortem fashion, but it's not to say it wasn't fun, that it's not a bad game, and that these aren't in any particular order or importance. I am not placing any blame on anyone for any perceived failures; I'm just mentioned who worked on what on the team.
What Went Wrong
- The initial design. Of course, with a game jam game, with the time constraints and the limited options you're given, either you come up with something simple and you do it and that's it, or you come up with something vague, and the design can go in multiple directions. Ours was the latter. One of my ideas early on involved nurturing a creature Pokémon-style in order to solve puzzles (hell, I still may make that game). Honestly, the Friday night design session is one of my favorite parts of the Game Jam, and game development in general. I would have loved to spend all night taking several ideas and molding them into basic game designs. But, unfortunately we only have two days to make a game, and we can't afford to "kill our babies" and run through several prototypes.
- Over-designing. Once we came up with our idea and we started hunkering down on the technical parts of it, our original pitchman Dan Roy and consultant Ravi Purushotma continued to make further designs. It's great that they nailed down the details of some of the things we planned to build, but they also added some features that weren't discussed during the initial design. So it got to a point where we were like, "oh, okay...guess we'll have to build that as well".
- Technical difficulties. For some reason, Darren had a hard time getting Visual Studio working for him on the MIT computers. I wasn't familiar with the repository system Darren set up for us (not that it was difficult, it just took a while to set it up, plus I'm prone to making mistakes. I'm still not used to working with repository systems :P). All told we were really kind of spinning our wheels until Saturday afternoon, so we had a lot of ground to make up. Additionally, some of the things I was working on were really simple things that I shouldn't have had problems with, and are really probably quite easy to fix, but with the deadline looming there just wasn't enough time to worry about it. Specifically, I'm thinking about the sound system. I don't know what kind of crazy format XNA expects its WAV files to be in, but apparently we couldn't figure out which magical settings it needed in time.
- Didn't meet all the constraints. This is a minor issue. We can make up arguments/excuses as to exactly where it is in our game that shows "deception" (and I think there were some good ideas thrown around in the design session), but the rain/plain/Spain kinda got left off to the side. Plus there were additional optional achievements, such as using all organic sound effects or using only 16 colors. But, we felt that these were more guidelines than rules, and there really more to spark creativity than to hold us to some arbitrary game conditions.
- Choice of platform. We chose to develop the game in C# under the XNA format, and specifically AngelXNA, which is an open-source port of the Angel prototyping engine developed by Darren and Jeff Ward. Now, I haven't programmed in a while (and never really in C#), so it took me a short while to get reacclimated. And since I was learning a new system, I was bound to make some rookie mistakes. For example, Darren questioned why I bothered to communicate within the game using AngelXNA's messaging system when I could have much more easily done a method call. And the answer to that was, well, I was mentally stuck using the messaging system since that was how it was reading keyboard input, and the sparse documentation didn't help to break me of that mental lock. However, it's still in its infancy, but the system made it much easier to build systems that would have taken us hours to build ourselves in XNA...which, of course, is the whole point of AngelXNA.
- Art and Music. Our artist Dan Salsberg came up with some great art with a nice visual style. And I have to both thank and apologize to our musician Alex Liberatore. I really do admire the Berklee students that attend these Game Jams, and game audio designers/engineers in general - it's really an under-appreciated aspect of games. He wrote some nice music and sound effects, and he and Dan Roy designed some really cool ways to implement the music as a function of the gameplay...but unfortunately you won't hear them because I couldn't get the sound system to work (see above).
- Complete prototype. It may not have sound, and the controls are a little sticky (for Darren, for some reason - they were working fine for me), some features were dropped, and it might not be terribly fun, but we accomplished the core concepts of the design, and it works. And for something that was only built in 48 hours, that about all I can ask for. Plus it looks good.
- It was fun! It was great meeting old friends and making new ones, and it's wonderful to go through the whole creative process of making a game.
What I'd Do Different
- Simplify. Maybe it'll take a bit more practice, but I'm slowly learning what kinds of things make for successful Game Jam games. First, come up with a simple yet specific "elevator pitch". Make sure the design is locked down by the time we leave Friday.
- Prototype, playtest, iterate, repeat. Make sure we've gotten a prototype done by Saturday afternoon, and a first playable by Saturday night. Sunday should be for polishing and fun-making, not "oh yeah, we should probably put all of the pieces of the game together and make sure they work before we need to upload our final game to the website in an hour".
- Get the sounds working in the game early. It's one thing if I'm using clunky sound effects I've borrowed from the Internet, but I don't want to waste another audio engineer's time again if I can help it.
- Don't forget the small stuff. If I were producing, for the first-playable I'd dedicate at least one hour to make sure we have a title screen, end screen, credits, and all other the other little things that tend to get forgotten that end up being slapped together.
That being said, it was a wonderful weekend and I can't wait to do it again next year.
We had a lot of other great games made at MIT:
RunRunRunJump: a platformer with text cues. Looks great in 3D Unity (even if it is mostly text in blocks).
Quest for Stick: a platformer where you can alter the platforms. Great visual style.
Jumble is Trademarked: a word jumble where the solution is not what it seems. My second choice when we were organizing.
The Hunt Alone: first-person shooter where you're a visually-impaired hunter caveman. Had they gone with their original idea of "blind caveman", I can't help but think, with some tweaks and more innovation, it'd make an interesting Daredevil(tm) game.
The Last Bullfight: first-person perspective where you're the bull. I think given a little more polish time, this would have had a real emotional impact.
Press X to Not Die: Flash game that's all quick-time events.
Pigmalion: action-stealth game. Worth playing if only for the opening cutscene.