From Fire Post-Mortem

Introduction

From Fire is a fast-paced, continuous running 2D platformer that focuses on a young shaman who has discovered a dark force invading his tribe’s sacred burial grounds.

Bearstronauts Productions, a team of 6 developers, created From Fire over the course of 650 work hours in SMU’s proprietary GuildEd engine. This post-mortem gives a summary of what went right, what went wrong and what the team learned over the course of development.

Trailer by Xavier Strong

What Went Well:

Leadership Transfer

At the start of the project, Bearstronauts Productions had a software-developer acting as the team-lead. The problem was that this lead was also the only programmer on the team, if their duties as lead cut into programming tasks then they were left with no one to delegate work to. After a few weeks of production, our lead became to succumb to the stress of acting in two very major roles simultaneously so we had to make a change. The largest discipline on the team was level designers, of who there were three, making it the obvious choice to pull a new lead from. The team selected a new lead, and the old lead gladly stepped down, happy to have a lightened workload and time to focus on coding. The new level-design lead ended up being a good choice for the role, as he had the time to take up many of the documentation and leadership faculties with two other level designers to delegate to. Since the new lead was in the design department it also helped that they were the one everyone was coming to with questions, since he was already responsible for integrating many of the elements of the game in his levels.

Highly Motivated Team Members

From the start of the project, the members of Bearstronauts Productions were highly motivated to work hard and see the game succeed. The high level of motivation in the team meant that many team members were willing to put it some extra hours if it meant that the game would be able to have an additional feature for the approaching milestone. On an individual level, motivation also helped team-members to be more receptive to feedback about their performance; if a personal change meant the success of the game, then they were willing to work towards it.

What Went Wrong:

Not Enough Incubation Time

Due to the overall brevity of the project, Bearstronauts Productions did not have the freedom to allocate a lot of time to pre-production. The lack of time to flesh out details in pre-production meant that many alternative ideas were not fully explored in favor of exploring an idea that was brought to the group with more initial details. The lack of successful group brainstorming hurt initial buy-in and resulted much of the pre-production being the work of one team-member. Another result of a short pre-production was that a lot of risks were not fully considered, such as inexperience with the game genre or the limitations of the engine.

Disregarded Opinions

At points, the motivation team-members had to see the game succeed hurt the openness with which they received new opinions from the rest of the group and external playtesters. Many group members had a strong desire to press forwards as fast as possible, at the cost of not taking the time to adapt based on advice. This stance ended up resulting in a lot of rework later on in the project and a rougher Alpha than was hoped for.

What We Learned:

Diplomacy

As the project progressed, team members gained a deeper awareness of the effect their actions had on their team-members. For some of the group members, this was their first time working on a team and so it was a new experience for them to adapt to. Early on, developers were letting their stress show visibly and brushing people off at times, but by the end of the project, everyone had reached a greater level of conscientiousness and self-awareness that led to increased trust and communication between all team members.

Early Integration

Even when it seems like integration will be risk free, problems can and do arise. With week-long sprint, Bearstronauts Productions often felt like it would be okay to push integration back to the last day before the milestone; however, it rarely went well and never with less than an hour of overtime. Late integration should be avoid at all costs, it’s better to build up a backlog of features that will be pushed into the next sprint than to try to force nearly-complete features in at the deadline. By Beta and RTM, Bearstronauts had adapted and the team was integrating at least two days before  and only doing small incremental builds that weren’t necessary to the game on the day prior.