Flixel Jam Postmortem

Phil's second Flixel Jam has come to a close. It was a lot of fun and I hope to see everyone again for another Jam. In the six hours, we managed to pull together a simple game about falling from the sky. Dubbed Terminal Velocity, the game is far from perfect: it's too hard and it needs about a weeks worth of polish. However, that wasn't the point. In six hours we organized a team of ten developers- many of whom had never met before- and created a proof of concept for a simple mechanic. The result of those six hours can be seen here. For those interested, here are links to our source code as well as our current build of the game.

Here are some things we've learned:


Data sharing

We needed to share art assets and code, but we did not come up with a simple way to do it before hand. For art we debated whether to use DropBox or to set up a network share directory on someone's hard drive. I personally preferred DropBox, but using it would've required an email from every person in the room. They would've also needed to download the DropBox client and set up accounts on the website. The large amount of people and late arrivals made all this inconvenient. So we went with the network share. Once the person hosting the files set up a directory to share files, we only had to share the name of their computer. However, the speed of a network share- especially in the library's WiFi- left much to be desired.

For code, any kind of group programming demands source control. Git seemed like a shoe in, since me and Phil had been using it for a project of our own. However, asking a ragtag group of developers to learn such a command line oriented program would've taken up too much of the Jam's time. The source control had to be fairly easy to use with a public, remote repository we could set up quickly and for free. Subversion and Google Code hosting offered the perfect solution. Tortoise SVN for Windows users is almost a no-brainer to learn and SVN comes pre-installed on Apple computers. With Google Code, we didn't have to set up our own server. Once we started, the speed of our coding impressed me. The source control allowed us to all work independently without stepping on each other's toes.

Information sharing

We decided to use a Meebo.com chatroom for sharing the links to the repository, the network share computer names, and other things. The chatroom was easy to set up, but it became a distraction when it momentarily went down with our library's WiFi. Again, we would have to share the room's information with late arrivals. Next time, I'd like to try using a white board to communicate information everyone needs to know.

Working with artists

We had five programmers and four artists working together. As a career programmer, I'm pretty familiar with working with a team of other programmers. However, video games add the challenge of communicating requirements to artists. While the artists did a great job on music and graphics in the little time they had, their efforts could have been more efficient if we had been better communicating with them. Because we hadn't given them enough direction, they ended up running on their own. At the end of the day, too many music tracks and graphics were created and only a small percentage were implemented into the game. For the next game jam, I'd like to try using the white board to write down specifically which game objects we need assets for.

Conclusion

Looking back at this Jam, the challenges we faced remind me of the challenges Agile programming methodologies try to solve. We had to tackle how to manage a large team of developers all working in tandem. We had to find the proper technology for communicating in an efficient manner. In essence, creating a concept game in six hours is akin to making a scoping-deliverable in a fast paced development environment. Hopefully next time we can be more prepared and our game will be as good, if not better than what we made.