I would like to remember that it is a blog mainly for us and this is an important point. But if someone likes reading it or it helps someone we will be very happy. Lest’s start.
This is our first post-mortem in all of our lives so it could be a little bit rare.
A post-mortem is a tool to remember what I did in the past
What is a post-mortem? A post-mortem is a tool to remember what I did in the past: the best, but specially the worst. And here is what we did good and bad in Gummy:
- Good communication skills
I think we have this important skill. This sounds topic, but this is true. Communication is really important. Sometimes we need to block resources, an scene or whatever. We have used Sourcetree as repository and version control and sometimes we had some conflicts or we lost parts of the game. Obviously Sourcetree is very useful, but we are no expert with it and we commit lot of mistakes. The point is avoiding the proud and communicate. This is not about proud, is about teamwork.
- Suitable technical requirements
From the beginning, we didn’t want to make a complicated project or we couldn’t handle it at technical requirements. We perfectly knew which were our skills and which were our disadvantages and we adjusted the project to them. Also we were thinking that the meaning of this is to have a challenge to learn.
- Good product/aim definition
To avoid getting lost in the process, we defined the deadlines and what we wanted to get with the project. In our case it was very important to know that it wasn’t a project to get famous or money, but a project to start as a team, learning how to work together and every new thing.
- Original sounds
In this point we had a problem, because we had to decide if we got the sounds through the internet (losing time and originality) or create them. That was the moment when we looked for another team mate to help us with the sounds. The result was pretty good and we obtain the extra of originality what we desired.
- Do what your Beta-testers need
When we went to social events we “force” our families and friends to play Gummy and got their impressions and thinkings about our little game. Of course we didn’t make everything they said, but we do wrote down everyting. That made Gummy a better game than we planned at the beginning by ourselves.
- Divide your product: Soft-launch + Global launch
Many times we want our games are the best games we are capable to make and without bugs, but the fact is that this moment never arrives and we have to finish sooner or later. A good way to cut our game is trying a soft-launch in some strategic countries and test it. Once we got the feedback during a week we prepared a global launch with bugs fixed and the content our target needed until we can see today in the game.
- Learning how to make a game we won’t like to play
Nope, we don’t usually play games like Gummy. We wanted to make a game we don’t like to play, because we wanted to prove ourselves we love making games even if they are not for us. We also have to be professionals making videogames.
- We didn’t write every important task
It’s pretty good to define the most important tasks of the project and the first ones at the beginning, because when you are fully concentrated at work it’s very easy to waste time guessing what to do at every moment. If you have a checklist with every task you will save a lot of time. If you don’t have a detailed list of your tasks your game could get dramatically delayed and affected, like it happened in Gummy.
- Bad task definition
In order to the tasks what we wrote down, we didn’t define them really good (their meanings, their dependencies, how to resolve them before start to do them, …) All of this took us into a deadly way where things got broken more than fixed. And this is when this point introduce the next one.
- Delay of the deadlines
Despite making this project in our free-time (we both have other jobs), we defined deadlines but we weren’t able to meet them, at least at the beginning. We had to to change three times our final deadline. It is not really bad for us not meeting deadlines, but it is important for us to have them in order to finish the project, but we changed the deadlines without any consequences and this is not a very good way to work, that is a risk. If you don’t have a consequence for changing a deadline you learn that you can change it every time you need it and the project would never come an end.
- Low knowledge about the tools
We wanted to learn many thing, included the tools: Unity5 and Sourcetree. We were not expert not started, we were just a pair of noobs. But we wanted to learn and we tried it. We lost a lot of time because we had to learn and fix stupid bugs because we didn’t know what we were really doing. Also sometimes we lost part of the work (Sourcetree, I’m watching you). It’s not good idea to learn a tool like this (the engine or the repository version) while you are in the middle of the job, but it’s better to do it when you are in a project like this than in a project AAA.
- Bad name for ASO
Lastly, and the most important, the choice of the title. We did a bad choice of the title, we didn’t know what other games exists with a similar name, with a similar gameplay, with a similar visual style… Also we don’t know nothing about ASO in Google Play and our position was very low (like the 100th or something like this).
We hope this could be interesting for you and thank you for read.