Midgard Saga is an isometric tactical role playing game with radial movement. Based loosely on Norse mythology, players control a group of four vikings on their quest for the ultimate pillage as they climb from the mortal realm, Midgard, to the realm of the gods, Asgard.
What Went Well
Communication among the team, including between disciplines was strong. Usually when an art asset was ready, design knew about it. When a bug was discovered, engineering was notified, etc. Communication is so important to a team and a project’s success, part of the reason why the game turned out the way it did was due to excellent communication
The Leadership on Midgard Saga was strong. Each lead maintained proper communication and did not get too involved in the development processes so much as ensuring the projects direction was solid.
The game changed from its inception as many do, but with each change, the vision remained solid, and the team always knew what the vision was. I attribute this to the excellent leadership and communication this team had.
What Went Poorly
Many on the team were punctual, and while we started earlier than normal, 8:30AM most days, punctuality is important to getting the day started well. On a scrum team of 15, we would start scrum without late individuals, which detracted from the purpose of stand ups in the first place that is having everyone report daily activities to one another.
The team used bug-tracking software in the beginning, and it worked great for a while until they stopped using it. There was a notable slowdown in bugs fixed, and a definite notice in repeat bugs that engineering, not to their own fault, had not remembered.
Projects have a beginning and an end, and on large projects, tracking is vitally important to ensure the project is not behind. Many on the team were very reluctant to the end to use the task tracking software, and often estimating how long it took them rather than recording the actual amount of hours after they had completed the task. This created some issues in that knowing when a task was complete, or how long it took the individual from their previous estimate to be more accurate in the future.
What We Learned
At the beginning, the team did not give much constructive criticism. After the team became more comfortable, the vision set further in place, and we were doing critiques, the team did this to a much further extent. By doing this, the team was able to take each asset/level/tool to the next bar of quality. I still believe criticism would have helped in the beginning stages of development, but we live and learn.
The team did a great amount of playtesting for Midgard Saga, but due to limited time and the fact the game lasted around 3 hours for a casual player, getting adequate amount of data for the entire game was hard to come by. For future games, I would recommend starting playtesting as soon as possible as we did; it helped a lot with finding bugs, and shaping the game’s direction.
From the beginning of development, the team routinely gathered feedback, which helped move the game forward dramatically. The art in all levels received lots of feedback from art experts; we routinely criticized the fun in the games design, and playtested regularly to find engineering faults. Doing all of this helped the game significantly.
To play Midgard Saga, go to our website at http://www.midgardsaga.weebly.com, or to our IndieDB page!