Post-Mortem
|
As the shoot ’em up project closes up, it is time to reflect on the process we went through. Going into it none of us had any real experience creating games. The idea of the project was to learn how the process worked and how we as a team cooperate to digitalize the vision we had starting out. As well as this we were expected to “learn by doing”, essentially creating a game with the purpose of learning how to create a game. In a sense it’s great, as it really has helped us understand the process better. The biggest take away we had from this project was that the focus when making a game should always be on the MVP (Minimum Viable Product). What we found with this project was that we often found ourselves having to cut things rather than work on what we could definitely finish and then add to this. This of course affected planning and execution as certain things proved difficult due to lack of previous experience creating games. As such, we ended up behind schedule several times and it could have been avoided with the MVP in mind.
Our version of Umibozu ended up quite close to the original concept document. We had a shark enemy, which would stay idle until within certain distance of the player. At that point it swam straight toward the player and circled, doing damage every so often. The other enemy was an octopus, which shot projectiles toward the player and kept relative distance. The player was traditionally WASD controlled and the floodlight would rotate continuously and slow down slightly when it was activated. It wasn’t until the final playtest where we actually changed the floodlight to follow the mouse together with the harpoon. We created a full level, with three different segments and a return to a crossroads, to create the feeling that you were going in circles and were in fact lost. We also had two powerups, one of which was a flare that lit up a large part of the screen and slowly decreased in size. The other was a bomb, which had similar features to the pipe bomb in Left For Dead, attracting enemies to it and blowing up to kill them. We managed to complete our GUI with a main menu, pause menu and HUD along with indicators for aiming and ammunition. All in all, the game was quite finished, but unfortunately we did have some things we weren’t happy with and things we wished would have been more polished.
When we started working on the project, we were completely new to the process. The process was different from what most of us had done before, despite Scrum being the framework for it. It was difficult to create a structure where we would continuously playtest and develop certain areas and we would end up only playtesting when we were close to deadlines and on certain occasions at the end of weeks. This hampered our iterative process as we could not continuously develop certain aspects, something we will definitely improve on in our Arcade Game. As for the actual development of the game, we learned a lot about version control and merging, something we had massive issues with at several points in the project. We learned how to use a .gitignore list and that way managed to work better together when it came to my view of the game as well as my lead designers view of the game.
As a result, the day of the final playtest we ended up with a game that was eventually not as balanced as we would’ve hoped. The positives were that although we thought a difficult game would be discouraging it seemed to have quite the opposite effect, which was an interesting piece of information. We worked hard and were happy to have a game that worked and although I can’t speak for all my teammates we all seemed quite proud. The negatives were that a lot of features we had planned to implement had to be dropped along the way, which gave us a game that was quite different from the initial plan. This was largely by choice, but admittedly many of the dropped features could’ve made it if the process was focused more on the MVP as previously mentioned.
As shown there is pride, but also disappointment. We were happy that we managed to come forward with something we liked, but it wasn’t as good as we would’ve wanted. The important thing to remember, which we all forgot over the course of the project, is that when we make our first game we can’t evaluate our performance solely on production value. In fact, we can’t really evaluate our performance solely on production value in this program. As we were taught in the first term, we are not here to learn how to succeed, but to fail as quickly as possible and change accordingly. As such, the best feedback we got on our final playtesting session came from a second year project management student. He told us that the first game isn’t going to be good, it’s about the level of bad the game is. You had to try making the game as low on the 1-10 bad scale you can, and you’re at around a 3.
In conclusion, I am happy with the outcome of this project as it highlighted the MVP as my focus point as the producer, as well as the fact that I should’ve put higher emphasis on the iterative process as part of the scrum framework. Furthermore the issues with version control and merging helped me further understand the value of prior knowledge of the software you work with.  |