Flixel Jam 2 Post Mortem

Last week's Flixel Game Jam came and went successfully. I have to admit, we didn't get as far at this Jam as we did in the last Flixel Jam. You can check out the fruits of our labor here. The idea was to create an RTS/Strategy game where the player casts miracles to convert dinosaurs to the player's faith. Along the way, the minions of L. Ron Hubbard seek to thwart you. It seemed like everyone had fun and learned something, but a few factors contributed to delays.


Brainstorming for two hours.
At the beginning of the last Jam, we brainstormed ideas very informally. We threw ideas out there and chose the one that sounded the most feasible. While this wasn't the most inclusive process, but it was quick. Luckily, no one was very adamant about contributing.

In contrast, during this Flixel Jam, we attempted a formal brainstorming technique we had learned during the Global Game Jam. It goes like this:

1. Everyone individually comes up with a random list of concepts, things, and mechanics for 15 minutes.
2. These lists are compiled and sorted into categories such as Mechanics, Places, and Things. Preferably this should be done on sticky notes for easy sorting.
3. Then each person combines sets of the sorted concepts into game ideas and pitches them to the team. They must answer three details about each idea: Visual Aesthetic, Game Mechanic, Game Flow, and Game Story.
4. Group members then discuss and pick the best idea that can be executed in the limited time available.

One thing we realized after we ran though this process was that it's meant for smaller groups. We had around 10 people attending this Jam. Sorting and pitching the 100 ideas that came flooding in after step two became unwieldy. Even after we moved the process to a Google Doc Spreadsheet, pitching the ideas took too long when everyone had to have a chance at compiling and pitching ideas.


AHHHHHHHH!

By the time we did choose an idea, we were so desperate to move forward, we came up with a mechanic and a story/premise, but did not establish the game flow/loop. Without this, we didn't have as much direction by the end of the day.

I can't really say which method would be superior for next time. It depends on how many people will be involved. If we're splitting up into groups of less than five people, we can probably do the more formal method.

Less experienced programmers.
After we were done brainstorming someone asked who was the lead programmer. Since I was the most experienced with Flixel the task fell upon me. Last Flixel Jam we had a few fairly hardcore programmers who had played with Flixel for a good amount of time before hand. Comparatively, most of our programmers had limited experience with Flixel. In the time we had, I attempted to give a sloppy crash-course explanation to how Flixel works. I suppose this programmer deficiency comes with the random collection of Jam participants and the six hour time limit. There simply isn't enough time to learn a new language and develop a complete game in that time. Programmers need to show up prepared.


Photo by Dmitri Wolf.

Starting unprepared.
SVN, Flex SDK, Flixel, Flash Develop - for programmers all those things need to be downloaded and installed before we begin. Getting everyone set up ate up another hour of our time.

For the next Jam, we should post on the Flixel Jam site that all participants should be set up with the proper software and be ready to go when they arrive. Furthermore, if programmers want to make a significant contribution, they'll need to play around with Flixel to become familiar with it before showing up as well.

Despite the challenges we faced we managed to put together a prototype that shows off the group's unique sense of humor and the basic ideas behind our original concept.