Post Mortem - Game Jam!

Since the Jam is pretty much over by now, I figured I would write a post mortem summarizing my thoughts on the process and some suggestions for the next one.

**Warning- This is will be a long post. You have been warned!**

Here is a two sentence summary if you don't want to read it all: We set out to make a sidescrolling platformer involving a chicken with a laser gun attached to its chest as the main character. The principles behind it were good, but a lack of communication and disorganization fowled us up!

I guess to start off I'll go through the different steps; Brainstorming, Team Forming, Development, and Compiling.

Brainstorming:

Review: The brainstorming session for the game jam started out pretty well. We had the idea for everyone to write down two nouns(To decide the main theme/character) and put them into a hat, then everyone write down a game mechanic and put that into a separate hat. By doing this we got some interesting, yet wildly different nouns to try and make a cohesive theme for the game. The first nouns we drew were: Frogs, Chickens, Laser Gun, Trees, Space/Moon, and Generic Genitalia (Which we promptly discarded...) From there we came up with a protagonist of a frog riding a chicken that had a laser gun attached to its chest...pretty thrown together right? The setting we decided on was a moon base, and the trees were converted into broccoli to use as the pickup to replenish health.

After we were done with that hat we started drawing game mechanics from the other one. We pulled: Jumping and Maze/Puzzle. There may have been another (Possibly sidescroller) but I don't quite remember...  Anyway, we came up with a sidescrolling platformer as our game style.

This whole process was pretty cool, and helped us get some ideas that we (probably) wouldn't have come up otherwise. In addition to adding diversity to our brainstorming this also helped with keeping the creative authority dispersed throughout the group as opposed to one person trying to force their view of the game onto the rest of the group. We'll save that for a later game jam.

Suggestions: Overall this method worked pretty well, but there is one minor thing I saw that could have been improved. That would be having a little narrower range on the nouns, or being a little more serious about what nouns we are writing. I know we, as a class, like to have fun and joke around a lot, but we had some pretty ridiculous nouns that weren't really helpful in deciding a theme for the game. Other than that I liked the idea of drawing random ideas from a hat and deciding from there.

Team Forming:

Review: This was the beginning of the disorganization that would plague the rest of the Jam. We loosely broke up into an environment, level design, and a code team. Each team broke up to decide what assets/classes needed. This was pretty chaotic... Each group had a different variation for the game, and there was very little communication between the teams. At one point in the night the level design team asked the coding team a question and the response was, "We have that in the game?" The level design team was mostly responsible for adding new things, but there wasn't very much talking to each other once the initial concept was made. We finally got a list of all the assets and classes that would need to be made and dispersed for the night.

Suggestions: The first thing I would recommend is once everyone has chosen a team that each team decides a team lead. All the team leads can get together and discuss what has been done, what needs to be done, and pass off completed assets to the respective teams. The team leads would also help keep the teams on track and organized. The second thing would be having a more organized meeting for choosing teams and dividing assets. This would help with keeping the view of the game consistent between the groups, as well as providing a better understanding of what each team member will be responsible for.

Development:

Review: This was, for me at least, the vaguest part of the Jam. I only knew what two or three people were supposed to be creating. It wasn't until near the end of the development stage, when the blog was started, that I found out that we had assets ready to be implemented. There was very, very little communication within the team. This led to some people not working on anything after the first asset, since they didn't know what else needed to be done. That led to us missing important assets, like the switches, force field, and some of the code. Overall, this step felt the least organized and probably the step that needed the most improvement.

Suggestions: I think just having the team setup from above would help immensely. If we also have a blog setup to track progress, having the team check it somewhat regularly to get an overview of what has been completed, as well as what is still left to be completed.

Compiling:

Review: This was a mess... the major hardship was getting all the assets and putting them into one package. The reason this was difficult was because a lot of references were broken in the code due to the paths being hardcoded in the code. There was also the problem of having missing textures, or unwraps that didn't quite work in UDK. Some of these things kept the game from truly being testable since it would only run in the editor and not in the 'full' game environment. This is also where we found out that we wouldn't be able to implement the HUD due to a lack of knowledge in how the HUDWrapper class works and not being able to figure out a workaround. During this process, we ended up creating some last minute models and classes to get the game to work more like we had originally imagined.

Suggestions: I think this might work better if each team would put the assets they created into the level themselves. That way the people who are more knowledgeable in that area are the ones implementing them, instead of one/two people at the end trying to learn on the fly how to make things work. This was most apparent when the animations were being implemented, and Andrew had to quickly learn how to set up the anim trees and implement them in the level. To facilitate this it would be helpful to have a place where the current build of the game could be accessed by anyone(Or just the team leads) and still be up to date, instead of trying to pass around the level to whoever needs it.

Overview:

Overall, this project had little to no supervision to help with keeping the different groups organized and compiling a cohesive package. Having a actual team and team lead will probably help with all aspects of the Jam. Also with more communication we'll be able to identify what assets still need to be made, and assign them to people to get them done. With a little more planning I think the next one will go much smoother.

Thank you for sticking around till the end.