Spellblade Postmortem

Spellblade is a project developed at SMU`s Guildhall by a team of 4 students. Spellblade is a 2D top down Run-n-Gun game where player needs to protect his base from waves of enemies using a magical sword.

What Went Well

Testing one feature at a time

As we had a small team developing Spellblade, we needed to separate major tasks between developers and most of the time our work was completely independent from each other. Although this can accelerate development, we knew that working for a long time without integrating tasks could cause many bugs and rework. To avoid this, we created a working habit where we continuously integrated our assets. Every time someone finished an important task, we integrated it into a stable version of the game (updating code files and doing tests were really fast since we used Unity and its script-based engine). 

By using this controlled environment approach, we could easily see if that component was working properly. Breaking the test process into one feature at a time made the debugging process faster and easier. Overall, this heavily contributed to the next point.

Reaching beta with almost no bugs to solve

We set an internal goal of finishing every milestone without any unfixed bug. The team understood that it was important to deliver a fully playable experience by the end of each milestone so we could get as much useful information as possible during playtesting sessions and not only a bug report. 

This approach proved to be extremely positive for the project. We started the Beta milestone with almost no bugs to solve, leaving a lot of free time for us to do more polishing and to better balance the levels. The team also started the Beta milestone without the usual huge pressure tied with it. Without huge levels of stress, we could calmly look at Spellblade and see what we could improve to make the game experience even better.

Collaborative work environment

This was the first time we worked together. We did not know what each team member could do for the project. Knowing this, before starting development we introduced ourselves showing our skills and limitations. This was important to understand the resources we had and to show the team who could help with specific tasks.

Throughout the whole development of Spellblade, we constantly moved across the room to ask for help.  We also moved our tables or seats depending on what each team member was working at that time. Before starting to work, we checked how we could arrange ourselves in the room to improve our communication. (Using laptops really helped with this fast movement)

What Went Wrong

Adding new mechanics to cover flaws

Spellblade`s levels mechanics are similar to a tower defense game, where waves of enemies move towards the player base (the Lorestone) and attack it. The objective of the player is to kill the enemies in these waves using the correct magic spell before they can destroy the base. Although this seems simple, before we were able to test the levels and see if the game was actually fun, we needed all these systems working. Because of this and our short schedule, we were only able to see how fun the game was only when we reached the alpha milestone. It turns out that the game was not as fun as we thought.

Trying to make the game fun, we desperately came up with new features we could add to the game and try to make it better.  We developed them and made a new playable version. However, the game was still not fun and we lost a lot of time developing these new features. At this point one of our professor called for a team meeting. He helped us understand that we should not try to cover flaws by adding more features; we should look at our project`s basic mechanics and make them better.

In the end, we removed the new mechanics and did a lot of playtesting to see how we could improve what we already have. However, we could not recover the time we had lost adding unnecessary features.

Non-unified team vision

As this was the first project the team developed together, we tried to mix everyone’s ideas into one project. We were naive, thinking that this would make everyone more involved and happy with the project. It turned out that we had distinct ideas mixed in one design document. However, team members had a different idea of the project on their mind.

We were still able to start the development with this. However, when the game started to come together, features seemed not to work as expected. The development went like this for some weeks until we finally realized something was wrong. We had systems built for the game that would not fit the game needs. Finally, we needed a team meeting to clarify what Spellblade should be. However, we had once more lost time developing the wrong features.

Don`t worry, we can do it all!

Young developers tend to think they can do more than they can actually do. This was also the case in our team. As some team members had experience developing in Unity, we thought we could move faster than expected. This leaded to an over scope project.

Our biggest problem was that we forgot that making a game is not only about coding it. Going back to Software Development fundamentals, we should always keep in mind that we also need to allocate enough time for planning, testing and integrating. We designed the game thinking that it would be a perfect game, where we just needed to translate the design documents to the game engine and make minor tweaks. We ended up using a lot of available development time to make changes on the game and did not have time left to create all the features we wanted.

Lessons Learned

The importance of milestones

The development process of Spellblade proved to the team how structuring a project in meaningful deliverables helps to have a finished product on schedule. With time and technical constrains guiding the project we worked only on what was essential and possible in that milestone. As we moved along in development, we understood that we had to drop unnecessary features to ensure the must-have functionalities were up and running.

Schedule enough time to plan for each milestone

We used Scrum for this project, what encouraged us to plan at the beginning of each new sprint cycle. However, during the first planning sessions, we rushed to start making the game as fast as possible. This proved to be a bad habit. As we moved along the sprint, we realized we had not covered all the important topics for that milestone during the planning.

In later planning sessions, we increased the session`s length from one hour to three hours (we had only 15 hours to work on the project per sprint). Although this seemed like two hours of lost work, this turned into better and more agile working hours, since the whole team knew what the project needed for that milestone.

Use the right playtester for what you want to test

By the end of each milestone, we had a playtesting session with one or more testers to ensure the game was going in the right direction. During early stages of development, we needed to prove the control scheme and how easy it was for the player to understand it (you need a controller to play Spellblade). However, we had playtesters that were not familiar with a gamepad and they could not easily understand how to move using the left analog and aim with the right analog. Although this is one of the standard control schemes for modern console games, we had to drop it off since testers were having trouble playing the game. 

Near the end of development, when we playtested the game with console players, it turned out that the new control scheme was boring and did not give the players the freedom they needed. Finally, we went back to our original control scheme and tested it again with console players to see how we could improve it.

It is important to understand that a game needs to be accessible to as many players as possible. However, there are features that you need to test with your target audience to ensure the gameplay is good. 

_________________________________________________________________________

 To know more about Spellblade and other projects check my portfolio.