S03 – Imii Studios – Failure through Production p.3

I quoted the following:

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.

I did not say that the next part is the last one.

Anyways, digressing aside, moving forward to the key aspects of production in Sunshine Swings. They will be split into 3 components to cover up some of the basic elements of the things I said before in more detail and cover more of the behind the scenes of the game’s overall development.

Marketing Plan

When we develop the marketing plan for this game, which involves not only researching how to promote our material, but also to ensure that we format the game the way we wanted it to without it being to unfitting for a mobile game. So we had a base structure to work with. You can find all the necessary details here:

  • Title needs to be less or equal to 3o characters.
  • A short description of less than 80 characters.
  • A long description of less than about 4000 characters. Which involves a short synopsis, all the game features that are available in the game, and some of what the game contains (in-app purchases, other features, etc).
  • Contact Details
  • Privacy Policy
  • Post screenshots of the game or edit them in order to make them marketable. This involves:

a. Minimum of 2 screenshots up to 8 screenshots (24-bit PNG or JPEG with min 320 pxl and max 3840 pxl and the maximum dimension of your screenshot can’t be more than twice as long as the minimum dimension.)

b. 512 pxl by 512 pxl icon 32-bit PNG with a maximum file size of 1024 KB.

c. A feature graphic of JPEG or 24-bit PNG (no alpha) with Dimensions of 1024px by 500px

d. Promo graphic and Banner Assets (Promo video is optional).

  • Select a category fitting for the game.

As for how the format is created, I just researched other games and see what sticks with how they market their screenshot images, use that as a base template and design the overall feel of the game. The key thing is to show what your game is about in no less than a sentence and no less than roughly 80-100 characters (unless you want to bore the reader if you wish). In addition, based on the persona we provided, which is that of an 11 year old child and a 35 year old married woman, we tried to provide aesthetics which would be more friendlier and more cutesy without it being too completely going off onto the scale of “overly girly”. So I tried to provide a base color palette of green for the most part with orange as the title to well contrast the game’s overall feel and atmosphere of the game. The result is as you see below:

These are all some of the necessary things we need to do in order to even release the game and allow the game to be put on Google Play. We had made a base for it weeks back in advance during production, developed a privacy policy provided from a template/base we can find and try to alternate what details we need for our game.

The gist of the marketing plan in a nutshell.

We were able to create the privacy policy based on a base we can find and work it off to create them for the game which you can find here.

And based on the decision we had to make, we had to create draft to edit the game and then re-submit the screenshots and the icon to ensure that we got the game fitting to what we wanted. And as a result, we integrated it into the game based on the base document from above.

The game is released on the basis that we would be able to provide the game with the amount of details we need and we tried our best to provide the details with what we wanted.

Project Management

For our project management, we were able to provide a schedule, however, how we execute the project plan is a bit cluttered and messy. We do not have a proper schedule. The closest we have is a milestone that we created and posted in the last blog on part 2. This leads to one of the things we did do wrong, we weren’t keeping up to date on the scheduling of the game and providing enough attention to how we manage the project. This is mostly because of conflicting schedules between different members of the team and the fact that we didn’t create a proper task list on what to do on the creation of the game.

Next time, to mitigate this, we all should have our own task list or create a hacknplan account as part of an alternate solution, which involves what we need to do in order to provide the game with what we need. We also need to ensure that how we schedule is more proper and just lay it out. We can afford to switch or alternate the way we schedule based on the situation and go with it. To put it bluntly, motivation to sift through the schedule constantly is the key aspect to improve this issue. Also, initiate a planning document outlining what you should do and can do during this time to ensure you can work consistently and ethically, something that a lot of us are probably not easily going to do because this is no short of the word “responsibility”.

How we try to provide progress through our project’s overall situation is via source control Using source control, we were able to provide our game with recent updates. Thankfully, unlike the last projects that I have personally done, this time there were little issues with the commit that was made, thus it was more controlled and there were little issues on having to reset the build to a specific point, improving over the last few projects I did where, in hindsight, I failed to even keep the build to its current state.


Now we’re getting into the meat of how we develop the game’s levels and feel for the game. Testing, in all honesty for this project, is a living nightmare.

For starters, there were issues and bugs that we couldn’t fix due to the game’s level system and that there was a lag that caused the game to have physics issues. This slows down testing considerably, but there were some issues with some of the game’s level structure. I will condense them down so that they do not need to be overly long in detail.

  1. Level 1 and Level 2 has issues with how the game’s overall difficulty is shown and it is shown to be rather unbalanced in terms of level difficulty order. So that was rearranged.
  2. Level 4 has no variety in them. So the idea is to introduce a trap that can help to introduce the player with the use of the sandpit and to make use of it in the future (or it may slow them down depending on the placement of the sandpit.
  3. Level 7 has some issues with the speed up, the ball isn’t moving based on the interactions with the speedup area. Thus, the game was finished in less than a few moves. Adding water to the mix allows them a chance not to rush things but also to make the player think about the choice on whether to flick the ball either too slow or too fast, finding the right balance.
  4. Level 13 specifically has some balancing issues due to the number of moves left, depending on the amount of base moves you have left. However, this is the last level before moving to the more thematic and refreshing levels, hence the game is slightly up in the difficulty curve. Though whether we should leave it or the levels were too unfair is debatable.

These are the ones I noticed so far playing the game. And there may be more unbalanced elements during testing that I may not even notice. So that could be a conundrum that can come up if there were other people testing them. There were testers that we had to come up with and tested and some were more complaining about the work-ability behind the game’s lag issues. But that’s something that my partner is more familiar with, as he tested it out with the target demographic.

But as for how we execute the game’s level design, my partner had to design the levels on paper and tested them. In my case, for the post-game update coming soon on level 16 upwards, I designed it specifically more on player choice and a lot to do with not rushing forward flicking around the physics around in exchange for more moves. Although some of the placement of the balls seems unfair, it tries to fit within the difficulty curve of the level as much as I can. Although as I’ve tested it, they are also somewhat annoying to move around. But because of a spammable feature that can be used, I added the game to fit the overall criteria and upped the difficulty curve as intended to ensure the game is designed within the boundaries of what is given to ensure players plan out carefully on where to swing, just like a real golf.

Here are the sketches that I’ve made as a base before making some changes to them (they were intended as level 21 and 22 before deciding to restructure them and make it as an example for level 16 and possibly 18 or 19:

And these are some of the aspects of the game that I have tested in the overall scope of things, from what I know for now. With all of the more core components mentioned, I will then cover some of the more aesthetic choice changes in the next part of the blog, before concluding the blog with overall thoughts and reflections, as mentioned in part 2.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s