Postmortem: M.O.O.S.E.

M.O.O.S.E. (Magnetically Operated Object of Synthetic Energy)

A small team of five developers produced M.O.O.S.E. in over 450 man-hours at the Guildhall@SMU. In the game, the player play as Milton the moose, a member of the Moose Commando Squad, and infiltrates the secrete base of the evil duck genius Dr. Bernard Mallard,  navigating environmental puzzles and hazards with magnetic energy. This postmortem represents what went well, what went wrong, and lessons learned during the development of the 2D puzzle game demo. M.O.O.S.E. taught us the value of scope, Scrum, playtesting, team dynamics, and general game production.

Figure 1: Main character concept by Ricardo Orellana

What Went Well?

Scope

Before heading into the project, we consulted previous cohorts who helped us focus our game design down into a manageable project for the seven-week course. We concentrated on one major mechanic, magnetism, and played it against environmental puzzles. By focusing on magnetism, we were able to create many unique puzzles that required the use of the same ability in new and interesting ways. Scoping the project correctly enabled us to find the fun factor of M.O.O.S.E. quickly and gave us the time to create a consistent, economical, and polished product.

Figure 2: Magnetic gun concept art by Ricardo Orellana

Scrum

During M.O.O.S.E.’s development, we found Scrum to be extremely helpful. The daily Scrum kept every team member up to date on the current issues and the progress of the game, and gave them more autonomy on their tasks.

While the daily Scrum is a great way to keep track of what task each member is responsible for, we found the most useful tool of Scrum to be the Scrum board. The Scrum board provides a visual indicator of the tasks that are complete, incomplete, and in- progress. With the Scrum board, we can easily see how many tasks, in the form of sticky notes, remained for each milestone. As each milestone approached its end, sticky notes of incomplete tasks would pile up and provide a sense of urgency for the team. The Scrum board pushed the team to work quickly and efficiently, serving as a great motivator and progress indicator for the team and project.

Playtesting

We playtested M.O.O.S.E. almost every week, and the feedback we received was extremely valuable. It allowed us to spot the flaws in our games that we would have overlooked otherwise. Game designers are often the worst judge of their own work, because they spend so much time on the game and become too close to it to see its imperfections. Playtesting enabled us to take a step back and look at our game objectively, giving us time to readjust elements of the game and polish the product as much as we can.

What Went Wrong?

Stress/conflict resulting from working with unfamiliar members

M.O.O.S.E. was the first time our team has worked together. Because of our inexperience working with each other and the small room the group was crammed in, tempers and emotions can flare. Around our Alpha milestone, the stress from other classes combined with stress of working on the project ignited some conflict with group members. Luckily, we were able to set aside our differences, came to a mutual understanding, and finished with a strong Release to manufacture build. Ultimately, the conflict provided an opportunity for growth for the team.

Figure 3: Dr. Bernard Mallard concept art by Ricardo Orellana

Initially having one level designer slowed development progress

We had a very small team for M.O.O.S.E., with an artist, a programmer, and two level designers. Due to one of the level designers being the team lead, he had to compile a lot of documentation and had very little time to do level design work. This gave us one fulltime level designer. Though the designer was extremely talented, the amount of level design work was simply too much for one person. Because of a lack of human resources, our game progressed slowly in the beginning.

Figure 4: Environmental concept art by Ricardo Orellana

Eventually, we received an extra level designer about halfway through development. This was a tremendous help. Levels were completed faster, and we had more free time to experiment with different level layouts. Having an extra level designer also allowed us to implement an after-credits bonus level for our game, which was well received by testers.

Unfamiliar game engine

The biggest challenge we faced when developing M.O.O.S.E. was learning to use the SMU’s proprietary engine, GuildEd. When we got our hands on GuildEd, it was an early bug-filled version. Because of this, we soon discovered that the engine has many limitations that were very difficult to overcome. Simple things like jumping and triggering sounds became difficult due to the buggy physics engine and collision systems. To make things more difficult, we did not have access to the source code, which meant our programmer had to find many indirection solutions to basic problems. As a result of the buggy engine, it took us a long time to get the magnetism mechanic working properly.

However, because we scoped the game well, we did not have to worry too much about the code of other features, which allowed us to bug fix and refine the magnetism mechanic as much as possible, which ultimately gave us a mechanic that was well received.

Lessons Learned

Through M.O.O.S.E. our team learned a lot about game development and ourselves. The game was definitely a challenge for us, and we have all grown as a result. Going forward, we believe Scrum can again be a valuable resource by providing a progress update for the project. Additionally, team dynamics must be closely monitored and observed, as a dysfunctional team can spell disaster for the entire project. It also helps to research a game engine and learn its limitations before starting development, because it will save a lot of time and headache further into development.