Here is a takeaways review for last month’s game jam. This builds off of the last entry in this series, from Game Jam #4.

This last game jam was a lot of fun, and I enjoyed it quite a bit.  There’s always a lot of good ideas out there, and I’m impressed at how imaginative and innovative people can be. Thanks to the Sacramento Game Jam meetup and 5th Planet Games for making this possible!

I entered this game jam with a couple objectives in mind. First, to use what I know, and second, to complete a game within the allotted time. Now let me tell you, both of these are challenges! When you enter a jam, you don’t know what other skill sets you have available, and with this being a social event, it’s difficult to consider working by your lonesome. But that’s exactly what happened, at least at first. I could have worked with Unity, currently a very soft skill, or in Java with a framework I’ve never used before. There was even an existing team using ActionScript (my skill of choice), but there were already quite a few members. All were -very- tempting, as I was really seeking out a collaborative effort, but in the end I started off by myself. Luckily, a designer found his way to me, and I became a team of two.

The end result was a nice prototype of a top down action game we titled “Alien Blitzer”. We had a HUD, as well as terrain and player/enemy graphics. The Flixel/Power Tools helped create a functional prototype relatively fast. It was really nice how things just slid in place towards the end. We were successful in the sense that we had a functioning prototype that included the core mechanics and game play. More can be read about the prototype itself in a previous post.

Lessons to apply to the next Game Jam

The outcome was no accident.  It was a result of experiencing two previous jams/hackathon where things didn’t go exactly as planned, some research, and most importantly, the application of these things. Just like the previous jams, there are a few key things that I have taken away from this jam through trial and error, and will continue using or improve on in preparation for the next game jam.

1.) Have an idea what you want to do

Have an idea what role you want to play, and what skills you will be offering. Going in without any plan can make it difficult to form a group, and can set you up for failure. This doesn’t mean everything must be set in stone, just have a rough plan. It’s tempting to be ultra flexible, and acquire new skills on the spot, but it’s more important to produce a prototype, so try your best to make use of what compatible skills are available. In addition, if you’re up to being a leader, be ready to be step up at the very start.

3.) Create a prototyping kit

Take your framework a step forward, put together a kit that’s fast and flexible, so setup takes less time and doing  comes sooner in the prototyping phase. To emphasis, these jams are meant for prototyping. The less time you spend implementing (coding)  something the better. This means you have more time to work on polishing mechanics, content, etc. A kit that at least has the basic environment setup, player controls, and a splashscreen would be great. It should be setup in a way where it’s easy to remove unneeded features just by removing a few lines of code, you don’t want to go too crazy.

I’ve started a Flixel/Power Tools/Dame kit on github.

4.) Bring a big pad of paper, and some writing utensils

Planning is really important, and it’s easy to become lost in the flurry of  activity. Ideas, goals, and thoughts can become meddled when they’re just floating in your head. Use something physical to keep everyone bound to one reality and understanding. This would include sketches, lists, or written words.  Something to avoid misinterpretations or deviations from what really needs to happen. Putting things down on paper helps out a lot, and I know for at least myself, it helps eliminate fuzzy logic that sounds good at first, but falls apart when it comes time for implementation (doh!).

5.) Map out your time

Time runs out fast, like super crazy fast!  It’s crucial to plan out how you will be using that time. Make milestones, set check in points to touch base either individually or as a team. Break out the project into parts, and then iterate through each part throughout the jam in cycles. Select the most relevant pieces first, estimate how much time it should take with some fudge room, and communicate that to all team members. When the time has past, evaluate the progress, and if the feature isn’t complete, decide if it needs to be rehashed, or if it’s best to continue plugging away at it. There should be a beginning, middle, and end to the complete development cycle. Make sure to segment time before the end of the jam so you’re not making a mad dash to get everything together last minute!

6.) Take snapshots

If you reach a milestone (wohoo!), backup your work (on all machines) so that if things go awry, there is something to fall back on. This should be something that can be done simply, and quickly. While version control systems such as Git or Subversion may sound like a good idea for something like this, they probably aren’t. You don’t want the overhead of working on merge conflicts or other possible version control specific snags. A simple copy and paste should do the job.

Conclusion

Taking steps to organize yourself and be more prepared are ingredients for a better experience all around. I look forward to seeing the results to the next jam, as I apply these new tidbits to my next game jam.

I’m curious if anyone has extensions of what I’ve mentioned here, or any additional tips.