Depth – postmortem
|
Hiiiiiiiiiiiiiiiii! Welcome to the last blog post assigned to me by school. In this post I am meant to write a postmortem of my groups now finally (!) finished game. I will discuss what went right, what went wrong, and then close with a conclusion, but I will start with a brief description of the product we ended up with. Depth is a platform shoot ‘em up, where you play as a research submarine escaping a long and narrow underwater cave. The player is chased by a large whale-like creature, and the chase is obstructed by several smaller enemies and cave walls. The aesthetic goal of the game is for the player to feel like they are on their last leg, or in other words, that they are barely surviving by a thread. We interpreted this to mean feeling under constant pursuit, in danger, constantly pressured and overwhelmed. It has a coherent pixel art style, and a low-key threatening soundtrack, which can be more described as sound rather than music. The player can shoot small torpedoes to destroy obstructive enemies in their way. They have unlimited ammunition, but the trigger needs to be released between firing. The player also has a speed boost which can be used for two seconds and then needs to recharge for ten seconds before it can be used again. The player is slightly slower than the creature, which means that the speed boost needs to be implemented in order to escape. However, the architecture of the cave walls are narrow, which means that a misplaced speed boost can send the player crashing into the walls and therefore slowing them down rather than speeding up. Because of this the player needs to perform with accuracy and make quick decisions in order to win the game. There are also checkpoints present in the shape of underwater mines, which means that the player doesn’t necessarily start over from the beginning, should they loose the game.
the alpha version of Depth
the final version of Depth What went well
During the production of Depth it goes without saying that certain aspects of the production went well, where as other aspects went worse. But most of all I am so very proud to have a working, playable game, which is actually fun to play! During the final play-test we got a lot of feedback saying how fun and challenging the game was, and I also heard witness testimony stating that many players stayed for a long time at our station. Even if I should disregard this, I personally enjoy playing the game, although I am not very good at it yet haha. I believe this is in part thanks to us taking the feedback we received from play-testing into account, as well as focusing on making a short, polished game with fewer assets rather than a complicated one. We also achieved most of our aesthetic goals.
As Lead Artist I feel almost obliged to mention the graphics of our game as my personal proudest success. I believe that the assets made by me and Ben (I mention him in like EVERY previous blog post in case you don’t know haha) are both coherent in style, as well as skill level. An they are (mostly) beautiful! I believe this coherency to be due to the limitation of pixel art, in combination with mood boards provided for most assets, as well as frequent communication. Additionally, I have received help from Ben when I have struggled with aspects of my work load, and I hope that he felt supported by me as well.
I personally experienced that we tried hard to support each other in the team, although there is always room for improvement. As I’ve already mentioned countless times, I received help from Ben on multiple occasions, and I tried to be transparent with my vision from the beginning in order to lessen the risk of him making assets I would object to. I also did my best to make sure Ben didn’t feel like he had a too heavy work load by encouraging him to assign tasks to me if he needed more time. Although I personally was very little help in Unity, our programmer (Wiktor), was supported by both Ben and our designer (Hampus), in Unity collab to ensure that too much work was not pushed on one person. Our project manager (Edvin) took care of tasks such as power presentations and credits.
What went wrong
I think that most of us in the group wanted to bring our very best to the table, however this might have caused tunnel vision on our varied minors. For me it was very important to make a ”good looking” game, since I regard visual aesthetics as a major priority. However, as we are often reminded by our teachers, we are all majoring in game design and not in our minors. Most of my time went into making sure the assets looked good, whereas had I taken some of that time to learn more about unity, I could have helped making the game longer or with a more smooth and challenging gameplay. It is true that I am pleased with what we accomplished, however, I would have liked to see more levels. In addition, as our teacher Mika pointed out, making obstructions which slows the player down, such as entangling seaweed, could have helped to emphasize the feeling of being pursued by one ultimate danger which would be in line with our aesthetic goals. As our game is now, the player take damage from the obstructions, which makes it feel less like a chase and more like escaping damage from all directions. This seemed obvious when it was pointed out to me during the last play-test, however the main thing I had been concerned with until then was how unpolished the final creature animation was.
As I have mentioned in my blog post about SCRUM, I didn’t feel like we lived up to the requirements. And since it was part of our assignment to work with SCRUM I feel like it’s appropriate to bring up here. I also believe that had we managed to work with SCRUM efficiently from the start, we would have had less wasted hours and less frustration in the group. We completely lacked any retrospective sprint meetings and our daily stand up meetings were badly organized, however this improved with time. We also failed to fill out the backlog individually in the beginning, although also this aspect improved over time. I believe part of this is due to individual personal reasons like lack of communication, lack of commitment to the SCRUM aspect of the assignment etc. Although I think we would have benefited from getting taught SCRUM in more detail earlier in the program so that we would be better prepared to implement it during this course.
On numerous occasions the tasks which was assigned to me ended up taking much longer than estimated. I think this was mainly due to the fact that we were all in many cases performing tasks for the very first time. This made it difficult to accurately estimate what problems might occur. This could have been avoided, albeit not completely, had we put more effort into a more precise risk assessment.
Conclusion In the end we ended up with a fun and visually pleasing game. Although I have mentioned many problems with our game in this post I think it is important to remember that problems and even failures are to be expected during the development of a game. Taking into consideration that we are all first-year students with no previous experience in the field I think we did a very good job. And most importantly, any failures or challenges has turned into our most valuable lessons. The lessons I will bring with me to the next production as an individual, will be to focus less on the visuals and more on the game design in general. I intend to study more of the materials provided to us by our teachers (especially about SCRUM and level design), and to familiarize myself more with Unity in order to be an efficient asset to my new team. This has been the most challenging, but also enlightening experience in the program so far, and I can’t wait to start making arcade games!
Byyyyyyyyeeee!!!
 |
