I worked with two of my classmates, Jaymee Mak (who also has a postmortem of the game on her blog) and Danilo Reyes. The game we came up with is called The Temptation of San Antonio the Vampire (which I'll call San Antonio for short), and can be played here. I was responsible for programming and asset integration; Jaymee was responsible for story, environmental art, project management, voice acting, audio and UI; and Danilo was responsible for character modelling/texturing as well as animation integration.
How did the Jam work? It was quite simple: each team in the Jam was given an image to serve as inspiration for their game, and had from Friday afternoon till Sunday afternoon to finish a game inspired by that image. We were give lucky image #13 - The Temptation of Saint Anthony, by Salvator Rosa:
Creepy, right? Well, this ultimately led to us brainstorming a game about a vampire who is drawn to garlic, even though it is poison to him. He is shunned by his family, and ultimately decides to try and reach a rehab clinic for garlic-addicted vampires. Things aren't so simple, though, as he must first traverse a garlic- and hiker-filled forest. Depending on how the players play the game, there are three different endings that they might reach.
What I Learned
So how did development go? As I suggested above, for me the most important learning experience about this game jam was learning how it feels to work in a team. This is a new experience for me, at least when it comes to any kind of creative endeavor, but luckily I was working with two good friends.
Learning to work with other people means a lot of things; one of those things is learning to coordinate development efforts so that things get done when other people start needing them. Art should be done when the programmer is ready to implement it, code frameworks should be done when the UI designer is ready to implement the UI, audio hooks should be in place when the voice over dialog has been recorded.
This sounds obvious, but as a lone developer, I have long been used to just doing whatever needed to be done right at that moment. Working with others requires frequent and clear communication, and while it's something I feel I need to improve, I felt that we did well in that regard. This experience was a good starting point!
More technically, this was also my first really motivated exposure to the Unity engine. We had previously been given some assignments to do in Unity, but they tended to have relatively fixed constraints; this was the first time I had to use Unity to transform free ideas in people's heads into a game that could be played.
So, down to the nitty-gritty of the postmortem. What are three things I felt we could have improved upon, as a team?
- Communication. I said we did quite well in this regard, and we did - but there is always room for improvement. A clearer order and assignment of tasks, and more frequent communication of the status and needs of each developer, probably would have helped smooth out the process and assisted in prioritization.
- Time Estimation. We had some difficulty estimating precisely how long certain things might take to complete, and this skewed our plans somewhat. We ended up completing the game on time, for the most part, but we did have some difficulties - an intractable bug that took me hours to solve, difficulties learning the Mecanim system, unforseen difficulties creating player models, and a few other things. We should have assumed more time for error, the so-called 20% more than we think we need.
- Design. We started out with rather vague ideas of what our game would end up being, and several factors - player challenge, item placement, gameplay outcomes, etc. - ended up being designed more or less on the fly, after some deliberation. Having a clear, concise and complete design from the start would have helped remove the weight of design decisions later on in the development process.
- Task Planning. While our design changed a bit throughout development and our estimations didn't always line up with reality, we did have a pretty solid idea of the specific elements that were going to be in the game, and we planned out quite thoroughly when what should be done. For individual components, this worked great, and we were able to complete everything on time, in large part because we strove to stick to the plan we had made at the start of the jam.
- Teamwork. As a team, the three of us got along really well, and we all did our best to make things work out. We didn't have any significant conflicts and were open about communicating problems with each other. We also went ahead and had a personal postmortem meeting over a nice meal, which helped us all evaluate and understand how the project went after the fact.
- Thematic Focus. We discussed what we wanted to do with the game at the very start, and once we had decided to do a narrative-focused exploration game, we committed to it. This commitment focused our design efforts and drove us to create what I think ended up being a successful instance of a narrative-driven exploration game.
My conclusion is that game jams are fun and educational; how could it be anything else?
But more specifically, participating in this game jam was a good idea, in large part because of the team-oriented nature of the experience. I hope that the experience will carry over into future team efforts I am involved in - specifically the final project at VFS, a 4-6 month ordeal that will hopefully result in a really cool little game!
If you are interested in checking out the twelve other games made during the third Hat Jam, check out this post on the VFS Arcade website!