To see the first part of the blog. Click here.
So after we decided on the idea of the game, which involves a lot of marketing research involving specific elements of what is not only cost efficient for us long-term wise, but also see the commonalities between the different elements of the mobile game in order to find a base for us to work up for. For instance, we looked at correlated data between the different marketing strategies between the different games that was researched, looked at how they work aesthetically and find something of a common ground between them.
This is why we decided to make the game more cutesy, more artsy and more simplistic. Due to the fact that these types of games are the ones most likely to be saturated in the market, and thus emulate the idea that something cutesy akin to the more “children-oriented” aesthetic in order to make the game fit the intended target market without it being too overcomplicated and oversaturated.
Unfortunately, we hit into a lot of major snags, mainly because we focused a lot on documentation as opposed to actually planning it on a timetable and create a project plan to accommodate the situation.
Because of that, we had to make due with a lot of schematics in regards to how we work out things. My partner eventually had to change the concept of the game completely to something more akin to a top-down golf game. And despite the fact that we change concept at a rather late point, we have not started production on it yet. So we decided to change the concept while it was early.
However, changes aren’t necessarily for the better.
In mid way during production, we weren’t able to work a lot on actually designing the game. There are a few issues I can point out, but this may not be the accurate answer to why this happened.
- Programmer has been set to program the code. And due to the nature of the code and the fact that the programmer has it’s own way of writing their code, there’s not a lot where we can factor in that would benefit him.
- We could not garner collaboration as early as we can. We ended up getting collaboration rather late in production, which is a massive detriment.
- Our project management took a nose dive and we weren’t able to keep a consistent check on our scheduling.
And these points will be brought up throughout the progress report as justification as to what aspects of our production process you should not emulate and for myself and designers to hopefully try to avoid in the future.
We tried to mitigate this issue, but all the issues aforementioned above happens due to the unpredictability of the people that we need to collaborate and/or work with. This ends up damaging our production time to a deep dive to the point where the game is not to the standards we wanted, ending up putting a quality far lower than the expected norm.
We even completed a milestone check for the game in order to assess how far we can go on a weekly basis, unfortunately, it was not up to date and it ended up being incredibly inaccurate.
|2016-11-04||Completed the Marketing Plan|
|2016-11-06||Marketing Plan is finished; Have a blog; start of production announcement.||Week 7 End|
|2016-11-08||Development announcement on Twitter and Facebook|
|2016-11-10||Pitch to the animation studio, Presskit is ready aside from images|
|2016-11-13||Announcing everything on social media sites. Presskit and store assets done. Beta needs to be done by end of week 8.||Week 8 End|
|2016-11-15||blog about some of the different elements that make up a level and why they are fun|
|2016-11-20||Game in beta (announcing the beta)||Week 9 End|
|2016-11-24||Game Released on Google Play, game release announcements for twitter, Facebook and on the Blog.||(This was delayed due to issues with the game, which involves ads.)|
|2016-11-29||Blog about how the game is doing in its first week, post on twitter and facebook.|
|2016-12-06||Release a patch/update for the game. Announcements on patch/patch notes.|
|2016-12-08||New Content and Bugfixes|
With those details, we were able to come up with a plan, but not until very late in production. This is because we weren’t able to take the initiative on working out a proper project plan, something that hopefully can be rectified in future projects.
Though for the things we did wrong, there were things we were able to learn and adapt from this:
- Interaction between User Interface in a mobile game is rather interesting and unique in its own way.
- Working together with designers to create the game that was intended to.
- Scoped down to something that we can release within the limited time.
Learning user interface is the most that I personally took from this project, as I learned a lot of aspects on how does the interaction between the characters in the game are developed and molded and how many mobile games replicate the style in order to bring out what we considered the standard in a mobile game. Of course, the collaboration and scope is something simple, but it is something that we could have thought a little more introspectively.
I was the one in charge of developing the user interface for the game and I find it a thrilling experience, since while there are elements that are out of my comfort zone, I find that it is something that I am willing to try passionately, and thus, why I have the intention to learn the basics on how user interface works on a more overa
ll general feel in order to broaden my knowledge on things.
Those details can be found on this page here.
That is mostly the development on my end on how things went wrong on the production of Sunshine Swings, as my partner is more focused on the physics of the game and I ended up trying to focus more on the user interface side of things.
The final part of this reflection or post-mortem will reflect on the final product in general and what I can do to improve myself in the future, critically reflecting on the aspects of production and what can I take away from this on a creative practitioners’ standpoint.