Postmortem for Treasure Seeker

The Making of  Treasure Seeker

Introduction

We are here to introduce an RPG 2D platforming game that we have created, and named Treasure Seeker. To start, we jokingly referred to our group as “Team Team” and it stuck. In the beginning, several members made up Team Team, but only four remain standing. We are Adam, Julian, Owen and Thanh. Unfortunately, the rest of the original group did not survive the design of this game.

We started our journey together in early January and have worked together until the last fading moments of the semester. We used Unity to build our game and  downloaded Assets for the design. We mostly worked remotely, communicating through Discord.

Production

We started from scratch. Our initial group began with a pitch about making a Metroidvania game. Different students who were attracted to this idea came together and started brainstorming where we would take the game. Four weeks in, our initial playable version of the game was due. Unfortunately, it wasn’t ready for the submission. It wasn’t playable. 

For the first couple of weeks we tried to build the initial framework of the game so we could start implementing its features. This started off very slowly… we struggled. We came with the idea of having a runes system that would give the main character spells and abilities such fire runes to shoot fire, and a water rune for water attacks. Then, we imagined you would be able to combine different elements to make special powers. These ideas were eventually abandoned due to lack of time, resources and skill. We were back to square one. 

Player

The next step was the Alpha build. This was the first time our game came together and started being functional. We finally had a working character that could move around in the world we built. The first zone of the game was bright green with a Medieval village background. We created a basic wizard enemy who could move around and deal damage. It started off pretty simple and needed a lot of improvement, but we were happy to see the first bit of progress. There were still tons of bugs and things to fix and add, but we were beginning to feel hopeful. 

Wizard Enemy

As the Beta release approached we began to expand our world so there was more for the character to explore. In the Beta phase, we added a second zone to the game. It was a lot darker and more spooky. There were sky islands you could jump around on to give the player a more immersive experience. We also added a new enemy type: it was a simple bat that could deal damage on contact. 

Bat Enemy

Team Team completed an analysis using Nielson’s Heuristics Evaluation Sheet. Through the evaluation we determined that there was room for improvement in the application’s usability and development process. For example, in the category of error prevention, our game was crashing when certain keys were pressed. These bugs were due to errors in the code, and were frustrating and difficult to fix. This evaluation sheet also prompted us to examine the visibility of system status. Game design should keep users informed about what is going on, however, we realized that our game started very abruptly. When you start the game the player just appears on the screen and there are no instructions to guide the user, or inform them of their objective. Through this process we also examined the aesthetic and minimalist design. We found our game was simple and did not have a lot of distracting visual elements, therefore it was clear to see the primary objective of the game.

We also used the Critical Stage Analysis Sheet which helped us to define what worked well in our project, what was problematic, and what could be improved. Overall, we were happy that we used Unity. We were also happy that we created a simple design. The Critical Stage Analysis also asked us to identify what was problematic in our process. Lack of communication between our group members was the biggest problem. Group members were not clear on their specific tasks or goals, and we were lacking leadership and direction. The initial framework of our game was created by a student who left the program. We were left with a framework that we were not familiar with and didn’t fully understand. Finally, this worksheet asked us to outline what could be improved. We had bugs in our code which were problematic, but we were able to fix some of them. 

For both the Alpha and Beta stages Team Team made presentations to the class. The slide materials could have been improved with more time and effort. At this point, we had fallen behind, largely due to losing key members of our team. When we regrouped, we had to lower our expectations. We were forced to change our initial goals and focus on more realistic expectations for what we could achieve with the time that remained.

Where initially we planned on having many runes and spells to combine, we ended up having only two attacks. We had one attack that was a sword swing, and one that was a fireball. These could be used to kill the enemies. 

In addition, the final map was not as large and elaborate as we originally imagined. The design, the art and layout was very simple. 

Lessons Learned

Our finished product was not quite what we initially imagined. The final result was a lot more simple than we had planned. We took many different turns during the process of designing this game. 

Overall it is difficult to identify positives about the process of completing this project. Communication between group members was poor, people were often confused about what they were supposed to do, and often didn’t show up to meetings. There was much room for improvement. In future, teams should find a more stable and consistent way to work together to meet mutual goals. It would be helpful to be able to choose one’s own group members based on past performance and the contributions of students. 

On a positive note, we had a lot of great ideas going into this project. Some of our brainstorming sessions were lively and exciting. Although we were not able to fully realize some of our best ideas, we are encouraged that we might be able to tackle more sophisticated projects in future. As we gain more knowledge and experience, we feel we will be able to create games that fully serve our creativity.