Quest for Mjolnir Postmortem

Quest for Mjolnir Logo

Quest for Mjolnir is a game I developed with three other students at the Guildhall for our Team Game Production 1 course. It is a side-scrolling beat’em up game developed with the TorqueX engine.

What Went Well

Development of Quest for Mjolnir was an overall very good process. The most important factor in that was that as a team we got along very well. I do not know that there was ever a real conflict on the team, much less one that distracted the team from working.  Members of the team were fully invested in making our game fun, so no one was slacking off or getting behind in their work. At the end of the project, we had a fun and unique game that makes us as developers proud.

What Went Wrong

I think that there are certain tasks in game design that until you experience them first-hand, you do not fully appreciate how much they help your project. Keeping up with the documentation was one of those tasks on our project. We put a lot of effort into creating the initial documents, but after that, we mostly left them as they were. The problem this caused did not really show up until after our Vertical Slice milestone was due. Playtester feedback told us that the melee attack in the game was boring, but the ranged hammer throw was much more entertaining. We quickly realigned our focus on the hammer throw, but left all the changes out of the documents. Pretty soon, we were getting lost in the details of the hammer throw. If we had just gone back to the documentation and written out all of the things we wanted to put into the hammer throw, we would have saved hours of work trying to balance everything in our heads.

Koko throwing his hammer

Then at the end of the project, we had to turn in fully updated documentation, but since we only had old documents, we had to spend hours of development time updating everything. If we had spent the time to update documents as changes happened, we would have had a two or three meeting days that could have been spent on bugtesting instead.

What We Learned

Near the end of development, our programmer had implemented all of the planed features in the game and was focusing solely on bugtesting. As he would play the game, he would find areas of the game that could be improved with a new feature. Most of these new features took less than twenty minutes for him to implement, and they made the game better, but they made me realize something. At some point, you have to say no. Even if the feature is easy to implement and it makes the game better, you will never reach a shippable product unless you put your foot down and stop adding features to the game.

Quest for Mjolnir was a great learning experience for me as a Team Lead/Producer. It was the first time that I had a chance to work with programmers, artists, and designers all in the same project. Seeing the interaction between these disciplines was a great experience.