Dev Blog 6, Post Mortem
|
Edit: In my original post I didn’t describe how the final game turned out, so I’m making this edit to correct that. The game is a top down auto-scroller. The design is based on a concept document for a Shoot ‘Em Up (SHMUP) created by another team at the education. Their concept was based around having “mystery” be their main aesthetic, and that had a major influence on the design choices we made when turning the concept into a game. The player controls a fishing boat, which you journey out in with the goal of finding the legendary sea creature, the Umibôzu. Because of some of the issues with the development that I mention in this post, the story telling was an aspect of the game that suffered. The story is now told mostly through text and images that are shown before and after the players journey. The game starts with a tutorial segment where they must use the controls they are told about to progress. Those controls are: steering (with WASD), aiming and firing (with the MOUSE), activating the floodlight (with SPACEBAR) and activating the two power-ups (with Q and E). The floodlight, which I have written about before, is the mechanic that most sets the design of Umibôzu apart from other SHMUPS. For most of the game, the world is covered in a thick mist, which enshrouds both enemies and valuable pickups. The intent was that it would be necessary to reveal what was behind the mist to decide whether to shoot at it or move to pick it up, and that this mechanic would convey that feeling of mystery that we’re after. Again, because of some of our problems, the game-play never really panned out that way. A combination of the fact that the floodlight was hard to use, and that enemies and power-ups could be distinguished without it (because of the way they moved) meant that as a core mechanic, this didn’t really bring anything meaningful to the game. The player progresses forward at a constant rate, picking up ammo, fuel for their floodlight, a pipe bomb (that attracts enemies and then explodes) and a flare (that reveals what’s behind the mist in a large area for a short period). As they progress, the number of enemies they face grows. We have two enemies in the game, one shark that moves towards the player and damages them directly, and one octopus that stays at a distance and fires projectiles. Both are killed with a single shot from the players harpoon gun, which has a lower rate of fire and a moderately slow travel speed. After reaching the end of the map, players are presented with the rest of the story through text and images, and the game ends. End of edit.
Umibozu, post mortem This is the final post about the design of the game Umibozu, which me and my team have been working on for around 10 weeks. The game is done and in this post I will be writing about what my biggest takeaways from working on the game were. Our game is made in Unity, and I used Visual Studio to write scripts. For version control and sharing builds we used Visual Studio Team Services. Team Services is a part of Visual Studio, and it uses git as a plugin. Figuring out how to use git properly was tricky and time consuming. The knowledge of how it works and how to work with it efficiently is something I believe will benefit me greatly in future projects. Since git is so widely used this knowledge seems especially valuable. Of course, I’ve also become a lot more familiar with using Unity to create games. In terms of design for this project, I believe our group had a suboptimal design process. Since we were given a design concept to base our game on, it wasn’t obvious to us from the start that we needed a design document completed as soon as possible to base our design around. We erroneously believed that we could work based mostly on that concept. This meant that when I was implementing features in Unity and writing scripts, that I would also have to make decisions about what the design of those features should be. Then, when the group looked at the result, no one coud say that something needed to be changed, since we didn’t have a clear idea of what the design should be, and what was implemented was implemented, so why change it, when we didn’t have that clear goal for the design. The importance of a design document that is as complete as possible early on in development is one of the biggest takeaways for me from working on this project. In my opinion, the game we ended up with is not nearly as good as what I had envisioned when we started. On top of what I mentioned about not having a clear design, and not working towards an MVP, as mentioned in the previous post, a major contributor to the worse end result is poor time management. Towards the end of development we rushed to get a bunch of features in, which meant that they were sometimes poorly implemented. I believe with a little more work the game could be a lot better, and the largest improvement could probably be made in terms of level design. I won’t speak for anyone else in my group, but I am not satisfied with my own contribution to the game. The reason is that I simply did not put in enough work hours. The time I did spend working I was able to contribute a lot, but I simply didn’t spend enough time working. What I have learned is that I should be stricter with myself to follow the plan the group makes at the start of each sprint. I also know that I need to be better at keeping track of my work hours, since that is a major part of working efficiently with Scrum. I wrote about working towards an MVP last week, and that is another big takeaway for me. All in all, even thought we didn’t create the game I had hoped for, I am still very happy with the development because of all the things I learned during it. Hopefully I wont repeat any of the mistakes I made. Thank you for reading.  |
