Blog Post 6: Post Mortem Supplementation
|
End Result Now that we are reaching the end of this course and that is also the final days of the project, where everything must be finished, cleaned up and preferably as little bugs as possible with no game breaking bugs. At the end of the course we had a play test to see what people thought of the game and the result was pretty surprising with most people thinking that the game was a 8/10. Personally I am not very satisfied with the product due to a lot of creative differences in our group which led to a lot of problems when it came to the game. These issues could have been evaded if we had similar mindsets and thoughts on things but some things can not be solved sometimes. Due to these creative differences we had lack of “fun” in our game. The game ended up being very dull with not enough content to make the game enjoyable, and the replay value of the game would be very hard since there isn’t much to re-experience. The game lacks a ton of content to make it more fun in any way, there is the element of randomness in the game where you don’t exactly know where everything comes from every time but since there isn’t much content to experience, there isn’t any replayability to the game.
The game was Umibozu, the game everyone else also made, and we had originally planned for it to be 3-4 different levels with different feels. The first level would take place around the beach / coast area which then continues into a more open sea / ocean area and then ends up in a very quiet and “spooky” final area. In the 4th level you would then encounter the boss, Umibozu, but the player would not be able to defeat it, only be able to run from it and slow it by firing at it. In the end we ended up changing a lot of this into more of a story-driven game with more emphasis on the game feeling rather than the experience of the game and here was where most of the problems started to arise, mostly in terms of creative differences. In the end the game ended up being a mix of both which didn’t work at all since the game didn’t give a strong enough feeling as well as being empty when it comes to mechanics. We ended up making 2 levels and the third one being the one where you encounter Umibozu. Our UI elements were very unclear as well, we had a lantern in the players top right corner of the screen which told them the energy of their light, and if it ran out they would die, and many players thought that it was incredibly unclear what it was. There were even a lot of people who didn’t even know they had it which we could have improved if we had done our testing better and had implemented thing in time for the playtests. A lot of this is because of the creative differences in our group, that people wanted other and couldn’t come to an agreement on what would have been the best for the game. Due to this a lot of things were being done in the way others wanted it which led to things being implemented without any proper reasoning behind it. These things could have been avoided if there had been a better group structure, where we could have talked more to come to more agreements and not moving forward until we have decided on something together. Throughout the course this happened a lot, we never really had any proper sprint plans and not any proper standup meetings in our group either. Since we never had a lot of communication in our group we could never fully work at a good speed as a group and a lot of the potential that could have been added was never due to never talking as a group. From this I learned the importance of having a good communication in the group is highly important since it is from that you get most of the working structure and can discuss more things so that everyone can come to an agreement. Not having a good working structure leads to poor communication between individuals which leads to delays and just general communication. Another issue that we had a group was the creative differences which led to a lot of differences in the end product, there were things that we could never agree on and so it led to others in the group taking the initiative and doing what they want. This led to a lot of design falling apart since others were doing work and in the way they thought was the best. In the end of the course a lot of the design work fell apart due to this. There were a lot of things that didn’t fit the end design and a lot of things that had to be cut since we wasted time. In the end, what I learned was the importance of communication between individuals as well as the importance of proper sprint and standup in the agile workflow. Since we never had any proper communication and planning the work we did slowly collapsed and stopped working towards the end, and then in the end other work members were forced to fix things which others had designed due to this. Design What I learned was a lot since I read up a lot about different things such as the level design, the design of the enemies and the feeling of certain levels. When doing research on the level design I read up on Christopher W. Totten’s article “Designing Better Levels Through Human Survival Instincts” (2011) as well as Micheal Stuart Licht’s ,”An Architect’s Perspective On Level Design Pre-Production” (2003). Through this I tried designing a system which used safe spaces in stacks of attack where the player could hide to give the player a better feeling of stress as well as making the player learn. When trying to design the enemies in the game we mostly stuck to the ones in the original, but we then came to the conclusion that we needed more enemies as well as more variation to the enemies which led to me making a bit more research on how to add and design enemies by reading Garret Bright’s “Build a Bad Guy Workshop – Designing enemies for retro games” (2014). When reading this I tried to find out how to add more enemies to the game without ruining it and making to many since having more enemies in the game would lead to the enemies having certain properties to them, to make them unique and give them a reason to add them. In the end we ended up not adding any more enemies, but I learned a bit from this read which will probably help me in the future when creating more enemies. Throughout this course I also made a lot of research on Umibozu, in preparation for the boss fight so I read the article “Umibōzu – The Sea Monk” by Zack Davisson (2012) to see how to make the game feel like the player is meeting Umibozu as possible, since we wanted this game to have more of a feeling rather than a fun game. In the end we ended up doing the entire boss fight in a different way and my design for this boss was never used. In the end the product is an empty game with very few mechanics and a poor game feel due to a lot of differences between different individuals as well as different goals for others, some of us wanted the game to be a story driven game which would give the player a feeling to remember, while others wanted it to be a fun game which would be remembered for it’s fun boss fight or the great mechanics the game featured. In the end there are mechanics which has a very low usage and even some which aren’t usable at all. There are also a lot of things that are unclear and not portrayed towards the player well, such as an unclear UI and explanation of the controls. These thing are like this because of poor communication skills between different members and as mentioned plenty of times, creative differences. Since I was the lead designer, I was in charge of the main design of the game in terms of mechanics, but I let others come with feedback and other ideas if they didn’t think mine were good, but certain members completely ignored my role in the project and just did everything themselves which led to being a very oddly design which had to be fixed before we continued with the game. – Tomas Savela  |
