The game at its core is a stealth game (think original metal gear). You play a pig that is trying to get into the Barn Ball (like the things that fancy English people go to). To do so you need to sneak past farmers. You can pick up cloths to look less like a pig (and be less detectable). The trend of these kinds of posts seems to be to just list the good and bad things that happened. Thats the easiest way to break it down so I will be no different.
What Went Well
The people were great/talented
It was really a treat to work with some great talent. To be honest I was scared I was going to be in a team that I would have to spend most of my time keeping together. This was not the case. I was able to fully code the entire time. This was due to some great project management done by Abe and others. The other coder on the project, Alec, was also very easy to work with. I was surprised to hear that he was only a sophomore at MIT, I guess those guys are smart ;-). The artist, sound guys and designer created some great stuff (check it out for yourself below).
The game's core gameplay was simple
There was so many things that got designed for the game, but we were able to focus on the core. The core being: move around a scrolling world, farmers see you and try to turn you into bacon. I learned from this game jam that core gameplay is about all you should plan to get done.
We had fun with it
The theme, style and premise of this game is obviously silly. This made it really fun to work on and kept motivation high throughout. I would not have had as good of a time if the game had a serious tone to it.
From the start we used perforce (which I some how never ended up using before). Everyone knew how to use it besides me so it really worked out great. This kept us from having to worry about integration too much, as well as losing work.
Developing a game quickly in Flash is very easy. This was the first game I made (hacked together) completely with Flash. Not only can everyone enjoy the game with relative ease via browser, but I know that we wouldn't have been able to integrate assets so quickly (within the final hour) without it.
Nothing catastrophic happened
I was very paranoid that something crazy would happen. Art would not get delivered, sounds would be lost, or even complete gameplay functionality would be lost. We luckily didn't have anything like this happen.
What Wasn't so Hot
The game's scope when we began development on Friday was huge. This wasn't a terrible thing because we only really focused on the core stuff. However I can't help but wonder if the game would have been different if we would have tried to make a game that was more focused. It may have been better if the core gameplay was all that we wanted to do. That way any extra time could be spent actually polishing that core (as opposed to just adding more "stuff").
Flex is a great way to program AS3, unfortunately I had little experience with it when starting the project. Why did I program in Flex? The other programmer was used to it, so that helped get more done. I am used to programming AS3 in the Flash IDE with the timeline etc. With Flex, the code is a bit less integrated with the assets. So I spent a little too much time trying to do things that I thought should work, but didn't work the way I expected in Flex. I would say I wasted a good 4 or so hours on learning how to use the tech the right way (or rather the way that worked :-D). That could have been used actually making the game better. I may go into the details in a future post, because I figured out some important things post-GGJ2010 which make me actually like Flex better.
Getting down to the wire
We did a lot of things last minute. These things made the game a lot more presentable, but also caused some major bugs (as they should have). Thankfully we were able to get through the presentation by being careful, but I definitely fixed up some things afterwards so that I would be comfortable linking it to friends (or writing a post about it).
Early playable available
The game was playable pretty much the second day. Unfortunately we did not set up a system for others on the team (besides programmers) to play the game and provide feedback. This feedback would have no doubt helped define the game a bit better before completion. Although a part of me actually thinks this might have been a good thing, because we (programmers) didn't have to deal with getting feedback (only the small, evil part though I promise ;-) ).
Didn't utilize enough known tech
This wasn't really the worst thing, but I would have liked to utilize PushButtonEngine a bit more. I did integrate it a bit, but only for its sound manager, input manager and interface to Box2D. Those helped me out a bit, but it would have been nice to ONLY have to worry about gameplay. In the end I do believe we did the right thing and went with what was known at the time. There isn't too much time for learning how to use tools at a game jam. There is barely enough time to actually make a game.
As a whole I had an awesome time at the Global Game Jam. I participated at the MIT site which had lots of great people working at it. And of course when good people and game development collide there are always sweet results. Check it out for yourself!
(My personal favorite is "RunRunRunJump")