App Metrics

In Splop we did not factor player metrics into our design at an early stage and due to this custom metrics were never added. We luckily do have some metrics thanks to the Google Developer Console.

The metrics we do have access to are:

• Number of devices it has been installed on
• Number of devices it has been uninstalled on
• App rating
• Countries the game was downloaded from
• Total revenue

While all of these metrics can help shape our game they are often very vague.
We intend to eventually add our own custom metrics to the game, in the hopes of understanding our players better.

Some metrics we are considering are:

How many levels the player has complete?

This is to determine the number of levels people complete before they stop playing the game altogether. This will allow us to find any point in our game where the interest drops off. We can use this to fix any lulls in our gameplay.

How many stars does a player complete a level to on average?

This is to determine whether or not players strive to achieve 3 stars on every level, letting us balance the cost of opening level packs.

How many levels does the player complete in one play session?

This is to determine if players complete one level and then stop or if the players feel that a handful of levels is a natural stopping point.

How many times they have failed a level?

This will allow us to fine tune our difficulty curve.

How often they watch an add?

See how much people utilise the free in-app currency for our game, allowing us to increase or decrease the amount to fit with how much this cuts into the in-app purchases.

How much in-app currency do players buy usually?

Ensure our game encourages some spending, but not overspending.

How many levels do have they completed when they buy in-app currency?

At what point in our game do players feel it necessary to give themselves a boost. This will help us spread out the spending and understand the relation between difficulty and spending.

If they buy a powerup, which one?

This will help us determine if there is a completely unused powerup or something that is far more powerful than the others. We will be able to tweak the functionality of each powerup to assist with this.

How many power ups do they use on each level?

Do players require multiple powers to complete a level, if so how many? This will allow us to prevent any levels from draining the player of powerups to complete.

With this set of metrics, we will be able to fine tune many parts of the player experience and keep our game interesting and enjoyable for all our player, not just the ones that spend money.

 

Ethics In The Mobile Market

General Market

There are ethical choices in every market of video games. But one of the most complex sets of choices comes from the mobile market.

There is an ongoing debate as to if any in-app purchases in games aimed at directly at kids, is considered unethical. Our game is not marketed towards children at the moment so we will not explore this right now.

Many mobile games make their money off of what have become known as ‘whales’. These are super enthusiastic fans of a game who spend thousands of dollars on the game to progress rapidly. Many times this can go from being very supportive of the game they enjoy to becoming an unhealthy obsession.

We can help manage that though the choices we make during the design stages. Some choices are ethically sound and have a natural end point.

e.g. You can play throughout the entire game without spending any real money, however, there is a set of 10 cosmetic items that are available for purchase. 

In this case, the average user will either not purchase a skin at all or will purchase their favourite skins and ignore the rest. For the app to produce more money, more cosmetic items need to be made. The issue with this is that the amount of money spent on making the new content might out-weigh the money generated. As such with no continuous source of money, the app may not make enough to produce more content.

Some have no limit but are not manipulating the player to purchase more.

e.g. You can play through the entire game without spending any money, however, spending money provides items that make completing the game easier. 

In this case, the game can continuously make income from the players that want the advantage in completing the game.

Another situation is where the game is made to manipulatively make the player spend money but have a limit.

e.g. You can play through 9 levels of the game but to get to the 10th level you must either wait 3 days or spend $10.

This is where ethics start coming into question, however, there is still a limit. While this doesn’t foster the obsessive money spending, it does prey on players drive to complete the game by forcing them to make any real progress.

Finally, there is a form of manipulating players to spend endless amounts of money on the game.

e.g. You must compete against all your friends but if you have this potion, you do 50% more damage for 1 day. 

For the player to compete against anybody using the potion, they require the potion themselves. The potion then runs out, which they then need to buy again. This can very easily lead to excessive spending within a game, especially if there are a multitude of items like that. While many players don’t enjoy games like this, the handful that do can sometimes spend thousands on the game each.

There are more variations of these but this illustrates the effect that the design of the game can have on its players.

 

At times there are very vague lines as to what is ethical and what is not. Sometimes a system that created with consideration for ethics can be abused in ways people were not expecting. A case happened not too long ago were players were essentially gambling with skins in a popular online shooter. Now at first glance, that is fine, but combine that with the fact that the skins were often traded for real money and you find that your game promotes gambling. It is not always easy to tell if what you are implementing is going to have consequences, but at least keeping these things in mind when making decisions can have a big impact on at least a few of your players.

Splop

For Splop we identified that we would not be able to produce enough content in the time we have. As producing ‘skins’ would require remakes of almost all our art. As such we decided to go the second route I mentioned, and have items in the game that can make finishing the game easier, but there is no real need to do so.

We attempted to make our power-ups require some form of planning to use. Our first power-up is the Jelly Bomb, this allows you to destroy any single jelly and gain its worth in points. This may seem like an immediate boost to use, however destroying a jelly at random could prevent you from collecting it with the same colour, doubling your score. Or it could block off a path that you would have been able to take with another jelly. Our second power-up Telesplopper allows you to move any jelly to any open spot on the field. This can be used to set up new pathways, maximise score and so on. Finally, the Oopsie allows the player to undo their last move, removing any points they earned for it. This is designed to be used to when the player realises that they could have taken a better path or when the player has accidently moved the wrong jelly.

We purposefully designed each powerup to have some level of planning to use effectively. No power-up gives an advantage freely. This is to prevent a player from buying an endless supply of power-ups and simply breeze through the game without thinking. One power-up that was considered for a while was a ‘double points’ for 3 moves. This, however, encourages an endless spending cycle. With enough double point power-ups, the player will have double points the entire game. If the player has double points the entire game, then they will most likely win with no planning, making moves at random.

Our power-ups are built in a way, that even with an infinite supply of them, you still need to plan out your actions. This limits the advantage you can gain from power-ups.

During our level creation, we decided very early on that every level should be completable without any power-ups, even if it takes a couple tries. This was to stop situations of games having levels that are near impossible without spending money in our game.

We also added the ability to view ads to earn the in-app currency. This was so that players, that choose not to spend real money on the game, could gain access to our power-ups if they are struggling on a particular level.

In the later stages of the game, we decided to introduce an in-app currency, this was to allow the players more choice in what powerups they purchased. Previously the player would have to buy ‘packs’ of powerups to make it worth their money. Introducing the in-app currency meant they could spend smaller amounts of money on the individual powerups that they felt they required.

Each area of monetization in our game was looked at from an ethical standpoint and a few things, like what power-ups we implemented, and how you purchase the power-ups, where changed to suit the ethical stance we had for the game.

 

Management Styles

Over many projects, we have worked with many different teams. Each team and project would require a slightly different management style. Up to now, we have usually resorted to a SCRUM management style. With set meetings, discussing what we had done prior and a set of goals in order of priority, adjusting to what we needed. This, however, is most effective for shorter projects, like those that we have been doing before.

There are many other management styles and it is important to use the one most suited for your team, as well as the project.

This project was set to a much longer time frame than we are accustomed too. Initially, we resorted to the style we were very familiar with, which was SCRUM. As the project progressed we realised that the SCRUM methodology was taking more time out of the meetings than it was saving through the planning. This was due to the constant communication between the team. At no point did we need to make the team aware of what each member was doing, as we were all constantly working together to solves problems with each other. We then adapted to the AGILE management methodology, as it was more in line with how our team functioned. Setting separate tasks before each deadline and working through them together or working on separate tasks at the same time, to allow us to help each other at any time.

Unfortunately, our time management system was still set up for SCRUM, not having the quick flexibility we needed for the AGILE management style. In the future, we will be working in HacknPlan, a free web service that has the flexibility we would have needed. This, along with combining our two separate time management documents (GANTT chart and TODO lists), would have made time management a far smoother process.

Player Choice

Through our mechanics, player choice is built into the very core of our game. There are very few situations where there is only one option for the player to take. The real game comes from planning out which choices will result in the most points.

While the gameplay is built around choice there is also one other aspect that comes into play: the power-ups. The power-ups are a limited supply item that gives the player far more control over the field. Letting them do a set of tasks, such as, Destroying a particular Jelly, Moving a Jelly from any position to any other open position on the board and undoing your last move.

While the first two allow you to shape the board to suit you, the last one lets the player undo a mistake they have made executing a large plan. We attempted to make our power-ups desirable to the players however designed the game in a way that the entire game is completable with a perfect score without any power-ups.

Something that would have been very useful to measure would be what choices player made and when. Not the fiscal moves on each level but rather the timing of power-ups, when they purchase them and what item the purchase, while we have access to the real money transaction metrics, once the player has the in-app currency, we have no knowledge of how they use it. This is something we hope to add in the future. This will help us in knowing if power-ups are preferred, what levels they are most commonly used on, how many powerups people buy at once and so on. All of which would help us tune the effectiveness of each powerup. Keeping track of the player’s choices allow us to refine the experience of the game to fit how we would like the players to play.

This would also allow us to tune the game in an ethical way, understanding how much money players spend, and then limiting it in some way if we feel it is too much. Then fine tuning the amount if in-app currency the players can earn without spending money is also possible. Currently, the app does not have the player base to make large judgments with these numbers yet, but having the information would at least help us start.

Post-Mortem Splop

This is a post-mortem for Splop.

Splop was the first dive into the mobile market for everyone in the group, and we have come away with a lot of new experiences because of it.

For Splop our team worked very well together being able to produce things when we needed them to a decent quality. This stemmed from a good amount of familiarity, from working with or around each other for some time. Sometimes you are unable to choose the team you are working with. If you do have the ability to choose, then select teammates that have a diverse skill set that are useful in creating the product. Especially in areas where you know that you are lacking.

The programming structure of our game was not perfect. Due to our programmer having to create two projects of the same size in the time it should have taken only one, some areas of the project were directly translated from our early prototypes. This ensured the game worked, however, made making tweaks difficult during the polishing stages. In the future having a member of the design team work as a programmer as well, simply to take a large part of the simple workload off of the programmer. This is to let them focus on the areas that actually require their expertise, while not being bogged down by simple tasks that were merely time-consuming.

At one point we ran into an issue where we completely forgot to implement a very important section of the game. The issue came about, due to two assets being named the same thing. The ‘Shop’ (to spent real money on the in-app currency) and the ‘Shop’ (to spend in-app currency on the power-ups within the game). The in-app currency was something we added later in the development cycle, and we adapted the in-game shop to trade real money for the in-app currency, instead of the powerups directly. While usually, it would have been easy to pick up that a store has not been implemented, when going over our checklists we would simply say the ‘Store’ is done. To prevent something like this happening in the future, a naming convention will be set early in the project with an effort to ensure that every asset has a descriptive name and there are no duplicates.

Finally, I would say that Splop is a success. It has had a number of people playing it, and while there had been some issues pointed out, it was still rather well received. Splop has so far been one of my favourite projects yet.

Getting Splop Out There

There are a few ways to get a game’s name out there. It is important to know who you are marketing too. In a previous blog, I talked about personas, And this is a key time to use it. Advertising the latest in Rubik’s Cube technology on the back of an Italian cookbook, may not be the most effective what to advertise. Another issue is budget, how much can you spend on your campaign. For Slop we allocated a total advertising budget of $0.00. This obviously limited our options. As such we focused on free platforms, relying heavily on word of mouth and asking as many people to play our game as possible.

From then we needed to make the play store as accessible as possible. Part of the reason the game was named Splop was due to searchability. Not many games have the same or even similar names, making it very easy to find for anybody looking for it.

After researching many games’ store listings, we modelled the store’s descriptions with all the types of information that others have. Paying close attention to whether or not the information is important to our personas.

Handling the team

How we managed Splop in more detail. While initially, we intended to follow a SCRUM management style, with semi-weekly meetings instead of daily. We ended up following a management style closer to the AGILE, producing parts quickly and then refining them.

As a team, the designers worked very closely with the programmer, using a GANTT chart to manage our major deadlines with a TODO list that listed the most immediate tasks in order of priority. Continuous contact between all of us helped keep the project running smoothly. Some considerations had to be made for our programmer as he was busy with another project at the same time.

 

The next set of people we were working with were our animators: Hayden Graham, Nathaniel Howard and Jadzia Venour. While they had access to our GANTT chart we created a separate asset list in an order of priority, with set deadlines. We conversed on discord occasionally, however, that was just to help with iteration and never a set schedule. Keeping it as a document on google drive allowed us to keep it up to date easily.

For the animators, we prioritised a small set of assets:

• The 4 Jellies
• The floor texture
• The wall texture
• Publishing materials

One immediate issue with the first crop of art was the presence of the games name on the app icon.

This took away from the character, which we wanted as the face of our app.

This was quickly fixed in further iterations.

Later on in the project, many animators were looking for collaboration work, however, we had most of the art that we had intended to have by then. So we decided that we could utilise the extra artists to produce generic shapes in our art style, squares and circles as these would allow us to produce UI elements in the future very easily. This can currently be seen as our level graphics on the level select menu.

For audio assets, we had a full range very early on, produced by Adam Upton. Partway through the trimester connection with him broke down. We did not contact him enough about iterations and such. In the future, we will keep in constant contact with all of our collaborators even when their work for the project is mostly done.

Overall the management for this project did go well, however working between two documents did cause some confusion between them. In another project, we used a website called hacknplan, which combines the best aspects of both GANTT charts and immediate TODO lists. Including making separate sections for each discipline. This would have been far easier to work with and will be used in future projects.

 

Personas

Personas are an important part of developing nearly anything. Keeping who it is meant for in mind, helps you remove any excess features and highlight things that they may find important.

For Splop, we created two personas:

A large factor for the audience we are marketing towards is the fact that the game is free to play. Knowing that they enjoy the game before they choose to spend any money on it is highly valued. Recommendations are a powerful way to market the game, so people often will download the game after a friend has recommended it, or they see a positive set of comments and scores. Our games has a focus on a completionist mentality, where the player tries to achieve 3 stars on each level.

While not all the information about our personas is completely relevant to the app, having them paint a better picture as to who the person is, making it easier to design the game towards them.

The personas were created keeping in mind that puzzle games have a solid foundation within the mobile market.

Our art-style was based on one of our personas game preferences, while the other persona had no strong feelings towards the art-style.

We structured our art style towards the games often played by these personas particularly looking at the overlapping games between them.

Both of our personas have no drive to spend money within the game but are will to do so when they feel that it will give them a small boost when needed.

This is why money is used to buy power-ups within the game where they can choose to spend it when they feel the need to.

 

Splop Marketing

Splop was heavily influenced by the current trends of the mobile market.

While people often think of games like Crossy Roads and Flappy Bird as the lead in the mobile market, the most consistent game at the moment is Candy Crush and its variants. So we decided to lean towards a puzzle style game over an action or reflex game. After creating a couple of personas from the data we gathered on the player base of games like Candy Crush and Flow Free, we moved forward with our design idea keeping them in mind.

We discussed at length on what type of monetization we will be focusing on and decided that “In-App Purchases” are the most effective way of monetizing our type of game. Upfront payment for the game would have severely limited the number of people that would play a game from an unknown developer such as ourselves. With the option of viewing ads in place of spending money. This was to allow people that choose not to spend money the ability to obtain more power-ups without spending money.

After testing the game out for a while, spending real money on power-ups was odd as we had to bundle power-ups together for it to even be worth the minimum amount of money you can spend in the google play store. To fix this we added an in-app currency. This allowed the player the ability to choose what power-ups they would like easily instead of getting them to spend money on power-ups that they would not like.

 

Splop Testing

The main importance for Splop was bug testing, then followed by level progression. As we were working on a new platform we had many issues with saving on the mobile device. And as we were a small team we could only bug test by ourselves up to a point where playing through the game took an extensive time before we could test one or two features. In hindsight, ways for the developer to cheat would have been a good idea to speed up playtesting time, I have already added this to other projects that I am currently working on.

We created a Beta build and distributed it to a number of people, getting as much feedback from them as we could, attempting to fix bugs as they arose. What we didn’t account for initially is that many people who were testing the game also already knew the rough working so the game as we have been developing it for some time and talking to people about it. It seemed fine at the time as none of them had played our levels or had access to power-ups before.

This all caused the issue that we got no real feedback from the tutorial, and when we fully released the game this became an issue, as people did not understand the fundamental system of movement. Due to time constraints, we could not completely re-vamp the tutorial system how we wanted to, but instead added animations and a simpler swipe to move alongside the original selecting the jelly and then selecting a place. People playing with this have been able to grasp the movement very quickly however still with some trial and error. We intend to add a completely reworked tutorial to make players more accustomed to the game quickly without the need of trial and error.