informa
3 min read
Blogs

Quest for Mjolnir Postmortem

Postmortem of my first team game at the Guildhall at SMU.

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.

Image of the main character of Quest for Mjolnir throwing his weapon.

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.  

Latest Jobs

Treyarch

Playa Vista, California
6.20.22
Audio Engineer

Digital Extremes

London, Ontario, Canada
6.20.22
Communications Director

High Moon Studios

Carlsbad, California
6.20.22
Senior Producer

Build a Rocket Boy Games

Edinburgh, Scotland
6.20.22
Lead UI Programmer
More Jobs   

CONNECT WITH US

Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter

@gamedevdotcom

Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Register
Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Subscribe
Follow us

@gamedevdotcom

Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more