Due to the last part of the reflection being more generalized, personalized and too vague, I will actually cover some more informative information in general thoughts on several aspects in the blog that I missed or lacked in details and provide thoughts on the subject matter as well as providing thoughts on how to rectify them in the future.
So, during testing, I attempted to formulate a basic plan. Simply test the game manually on my own without outside assistance. This presents a few glaring problems.
- Only my feedback is taken into account, so there is not a lot of information that I can gather from what I can do alone.
- Some issues with how I tested are very concerning. Most of the playtests are based on the limited range that I can do. I can’t test them on phone often because of the time taken to create a build is more time consuming and follows to the third problem below.
- A lot of times, issues and bugs regarding the lags and the game physics prevent the game from being tested to its fullest potential, leading to a lot of time taken off just to simply bounce the ball back.
These issues happened because the fact that I do not have proper outside sources to test them for me and I do not want to give outsiders a broken game without doing proper checks on it, which may be a mistake as well. So the gist of it is that I do have a plan, only that it was executed very roughly, with mixed to negative results.
My response to these issues are not something that you should do and hopefully something that I can rectify in the future. The fact that I only relied on my feedback along and did not communicate this to other people who may have the resource and opportunity was something that I was missing out.
I ended up not taking the initiative of asking for feedback or ask for more testing resources, even though I tried to at some level.
The basic idea is to ensure that initiative is taken so that I would have more idea on what to change and helpfully get the game to be designed better. Though the bug issues can’t be fixed because of management of tasks and delegation. Designers were focused on design and programmers were focused on programming and that’s a natural thing. But because the programmers have issues figuring out the physics of the game and the camera control, it ended up being a big mess of time chunked out where we couldn’t do anything because we were not allowed to touch the code. If anything can be done to rectify this, it’s either to find alternatives or cut several elements that have the problem in the first place as a last resort, but we ended up not doing that, which may have been a mistake.
So gist of it is, don’t do any of those things or if it does happen again, remove that feature to the extent that it doesn’t affect the gameplay. Adapting and rectifying these issues can only be done if it happens midway through production, so this is integral in getting myself and possibly designers to hopefully find a way around this issue.
So the key thing that comes up in project management is that I covered some parts of the basic issues that we come up in this part of the blog. But the big conundrum that comes up is that there are a lot of things that went wrong here.
- There is no proper schedule. The best schedule we have is a google sheets chart that is not even regularly updated, something that we lack the drive to check and re-do, which seems more an excuse than a lack of actual effort or result. Simply put, doing this isn’t exactly the most fun job to do and personally seems like it ends up having a result that may not necessarily seem useful to the naked eye. But that mindset is an awful representation of how project management is seen and I knew it.
- A lot of the task list that we tried to provide were also not up to date, there were lack of direction in the game during production midway and due to the nature of the game’s concept changing up to roughly in between 1/4th of the production week, we have literally little means of breaking down our tasks to ensure that we would work as efficiently as a team. Even as manager at 1/2th of the production week, I was incapable of working out the time schedule between the different work process until I confirmed it with my partner, whose knowledge is well accounted but still not enough to provide a clear project plan and the execution is lacking as a result of it.
The ways to rectify this can be summed up in the previous blog where we create a hack and plan and commit to it. Commitment is the key word here because this word is the thing that we need to solve this problem. The fact that we weren’t able to commit to a schedule and lacked the drive to properly layout a project plan on a weekly basis ends up hurting the production for the game and the results, because we were all under the mindset of “this stuff wastes our time, so let’s just not do it and work on the game instead”. And while this mindset has its merits, it also covers up a lot of issues with how each person does their work and lack of knowledge of how one communicates/works is a horrible and terrible way of doing our work. If we want to try and solve this problem, commitment is the first step.
The next step is to ensure that the schedule is adapted to fit the issues that come up with the game. When a problem arises, make a note, try and attempt to update the schedule using that information and ensure that everything is laid out in a way that could benefit you. It may not mean anything at first glance, but you’ll be more thankful you did take those notes of production in mind for future reference. Hopefully, I can take those words to heart and try to rectify it the best I can. (Doesn’t mean that this problem is going to go away until the first step is taken)
Analytics and Statistics (in Metrics) – What is the current status of the game?
The game currently, as of this post, we had a monthly active user base of about roughly 70 players with only 12 active users that fluctuates in between end to November up to December.
While these shows a lot about how many have played the game and how regularly they played, this statistics did not tell us a lot on the player behavior, with the exception of how long they played before they stopped as the fluctuations dropped in 2 days at between November 24th to November 26th, November 28th to November 30th, November 30th to December 2nd and December 8th to December 10th. There are fluctuations in between them dropping and adding due to the fact that they won’t play past 1-2 days, understandable due to the content can be completed in mostly 1 day if need be.
On the retention base, we can see from the chart above that the fluctuations between the retention time only happened in 4 different areas. This would mean that we failed to keep the attention of the players long enough, being it a short game and all.
What’s interesting to note is that based on monetization, there are a lot of non-spenders playing the game and almost little to no spender playing. Fairly so as our revenue focus is less on the in-app purchase and more on the ad videos, which don’t play for the most part due to programming issues.
Overall, it is useful only on how the sales progressed. It tells us that its not a popular market value and it doesn’t hold up long enough for people’s interests. What statistics that I preferably want is data on what the player’s interest content, specifically which levels they enjoyed most. The unity analytics do not cover a base to base level basis on how much they interacted with the game, which is something that I personally find wanting to know more than how much people download the game or how many stayed playing. Regardless, the metrics is useful enough to keep track of basic information without disclosing on their privacy on the far deep end.
And that is most of what I have added. This may be the last coverage and unless there are points that needs addressing in another addendum, I may cover so depending on feedback. With that, this concludes the post mortem report.