What is Steel Seal
This trimester, we were given 13 weeks to completely design, prototype and produce a commercial mobile game for the Android market. We were put into small teams with another designer, as well as a programmer. I was paired with Carlos Melo, another very talented game designer, and Eli Deeth, a skilled programmer. The only restrictions we had to conform to was that it had to be a 2D game, released to the Android Play Store, and that the game had to have some sort of monitization built in. The first three to four weeks was the prototyping phase, where all students made a basic prototypes to test ideas and concepts of games. From here, we gave our prototypes to peers to get feedback on the basic mechanics we were presenting. We then had to narrow it down to a single prototype which we would then produce into a fully functioning mobile game.
The game we designed was originally called Seal Surfer, which we had to change due to a name clash with another game. The premise was simple, you play as a seal and you have to collect food, and dodge predators. This is done by a single touch input. Touch and hold the screen to swim down, and release to swim up and breach the surface.
What Was Successful
Overall, I would consider the project a success. We released to the public in time for the deadline, and I am proud of the product we presented.
Scope and Final Product
From the start of the project, our scope was fairly manageable and kept within what we could achieve as a group. The main mechanics were simple and easy to implement, and features of the game were designed in a way that they could be edited fairly easily. As production continued a few things such as camera effects and shaders, one of our power-ups and sharing functionality was pushed back and altered due to the fact that we were running short on time. As a group we decided that these things are not 100% necessary to the games core loop, and they can be desirable's that can be added at a later date. The share function and camera effects have now been added into the game, after the core game loop was up to a standard we were happy with.
With our game, we wanted a consistent theme throughout. From day one we had a clear idea on what we wanted the game to look and feel like. When creating a theme for your game, it is important to keep it consistent so that each scene or screen looks like it belongs to the same game. With Steel Seal, all the colours in our game are bright and saturated and our icons are in bubbles. This consistent theme makes the game feel complete and familiar to the player.
What Could Have Been Better
The documentation for this project started out strong. In the first few weeks of design and production we created our Game Design Document. This document hit the deadline okay, but from there it didn't evolve with the game. Normally, a GDD is updated along with the game and is the bible we stick to when designing. Unfortunately, after the first iteration, there weren't a lot of updates to the document. It was also missing important information including exact prices for items in our shop, all the information about enemy metrics, including scale compared to the player and speed and information about our monetization.
This lack of information definitely had an impact on the project. For example, when our programmer Eli was implementing power-ups, he had to guess values which the designers had to go back and adjust later. This meant that myself and Carlos had to revisit power-ups that were already set-up. A similar case was with how much our power-ups costed in the shop. When Eli first implemented them, he referenced the document, but couldn't see it anywhere. This meant again, we had to take time to go back and change them instead of working on something else. All of this back tracking could have been avoided if our GDD was kept up to date and had all the correct information in it.
For future projects, to avoid this happening again, the GDD should be revisited at least once a week to update it with any information we may have glossed over, and update it with new information about our game.
Communication is an extremely important part of a project. Without communication, the project basically self destructs. Similar to documentation, communication started off strong with meetings in person and over Skype, as well as chatting through social media discussing ideas and changes we would like to see happen. Unfortunately though, the communication dropped off significantly around week 7. I would still communicate well with team mates in class, but out of class I didn't make contact with my team for a couple of weeks. This caused frustration for Carlos and Eli, not sure on the status of different things I was working on. Because I wasn't transparent with what I was working on at the time, this meant that Carlos took on extra work to cover for what I should have been completing. I will elaborate more on this in the workload sharing part of this post-mortem.
As mentioned previously, communication with team members is vital when you are working in a team. Without communication, things can get quite frustrating and cause problems within the project. For future projects, a set meeting time, either in person or over Skype is necessary. Once a week at minimum the team should organise a time that they are free that they can meet and discuss what they have done. These meetings should be run in the "stand up" format in which each person talks about what they have done this week, what they are planning to do before the end of next week, and what factors could possibly stop you from doing this. In doing this, it keeps each team member up to date with what the others are doing, and allows an appropriate amount of workload share amongst all team members.
Workload sharing was a problem from the start of our project, and should have been something addressed early on. From early on in the project, Carlos took on a heavy work load compared to myself, and this stayed consistent throughout the entire trimester. The reason for this came down to communication between team mates and skill sets each person had.
Carlos is a very talented artist, and he also is quite good at programming and design. Eli, being a programmer is very strong in C# programming. I am a game designer, so I am strong in design and balancing, but not so familiar with programming. Because we all have different skill sets, the work load had to be divided out among us. This is where things went wrong. Carlos worked fast and hard and got lots of work done. On the other hand, my work pace was a lot slower so I got a lot less work done in the same amount of time. Because I don't have any sort of art or graphic design background, and my programming skills are average, Carlos took on the role of main graphics artist as well as helping Eli program the game.
In future projects, to help split the workload up properly, I need to take on tasks I am not 100% comfortable with. By doing this, I am learning new skills as well as taking some of the work of team mates so they aren't as stressed.
Overall, the project was completed on time and released to the Android Store. There were definitely things that went wrong in the project, but there were also a lot that went right and the game itself turned out great. It is important to use this as experience and apply what I have learnt so that I don't make the same mistakes in future projects.