Testing Steel Seal

Due to our weekly issues with numerous bugs, mainly with all our enemies AI, for the most part, we could only playtest our game by ourselves, after completing new features and correcting bugs we would all test our game individually.

The advantage of doing that was that we were all using devices of very different range and speed, in my case I have an old android phone that runs very slow and lags easily, this was perfect for me to judge the performance of our game.

Jake would usually ask his housemate to test it on his phone, which although I don’t remember the exact model, I was told it was a high-end device, so we were able to compare the big differences on how the game would run at different frame rates.

Eli used the approach of using an Android emulator, so he was able to test the game from his computer, and by modifying the settings in his app, he could simulate the game at different framerates.

Along the way almost every day I would ask my girlfriend to test new features or different sections of the game that were working well but needed to be improved. I would silently observe how she would use the application to see if it was intuitive enough for a person who almost never plays games, another advantage of this was that it would allow me to check the level of difficulty of the games and to see how her movement style would slowly change in the way she reacted to enemies after playing a few times.

Towards the last few weeks of production, we had a much more stable game that allowed us to test the games with friends, if we weren’t present to observe the test,  we would ask them to send us a report if they found any bugs so we could recreate the situation to track and solve the problem. Sadly we didn’t really make a form to fill out, and as I mentioned earlier because it took us longer than expected to have a stable playable version, we couldn’t playtest the game in class to get feedback from other students.

In the future, I would  try to make sure to have a more complete stage of the game to test so that I can test the game in person, there are things that you can notice only by observations, sometimes player would not answer online forms because they feel sorry for telling you if they didn’t like something in the game, and in those cases it is easier to notice their reaction when they see something they don’t like or don’t understand, or when they do like it and genuinely enjoy the game.


Choice Design

In the following blog, I will explain my design process and iterations, and how my choices were related to ou monetisation. As I have explained in my previous blogs, we decided to create and endless runner so we could have the chance to polish our game and make it feel and look like a professional product which was a big challenge in the time frame we had available considering the overall skill level of the team.

Initially, the system that I requested to my programmer for the procedural content generation would allow us to handcraft multiple sections that would be procedurally generated on different orders according to some variations that would affect our algorithm. With this system in mind, and looking for ways to incentivize players into traversing across the level constantly I designed a few different enemies with different behaviours, so we could create more dynamic gameplay.

First, we introduce the shark, it is the smallest of the predators but it moves a great speed, it charges in a straight direction from the right side of the screen towards the left side. This enemy is spawned in the game very often, we do this to keep players on their toes so that they have to be alert and paying attention to the environment in the game.

The second, is the orca, as the shark obviously this enemy only appears under the water, it is the largest enemy in the game and its movement constantly changes as it goes after the player, because of this I decided to make this enemy a lot slower than the shark, giving enough time at players to avoid them by swimming far from them or jumping out of the water.

Our third enemy was the polar bear, it is the only  predator out of the water, it constantly moves from one end of ice platform to the other, sometimes having up to two polar bears on the same platform, but always making sure they have and offset big enough between them so that players can jump in the center to avoid them. This enemy moves at a medium speed, it goes slower than the shark but faster than the whale.

I had designed two more enemies that I decided to remove later on from our design because of lack of time. These enemies were a bird of prey that would appear if the players stood too long over a platform without moving, it would move at a fast speed, but always on an arc trajectory, being the centre the position of the Y position of the player the moment the bird of prey entered the screen. The other enemy was a jellyfish, it would simply stay static slowly moving with the level, my idea behind this design was to create obstacles underwater, making players to be more active in the way they moved.


Following the pattern in the design of the successful endless runners we studied during our marketing research,  I started to design or monetization method. Being an endless runner I could not charge players for unlocking levels (“Which is a concept that I don’t enjoy from a player perspective”). Instead, I decided that our monetization should be aimed at two very important areas. First, we wanted to be a social game where players would try to beat their own scores but also the score of their friends and complete all the achievements.


Instead, I decided that our in-app purchase side of out monetization model should be aimed at two very important areas. First, we wanted to be a social game where players would try to beat their own scores but also the score of their friends and complete all the achievements. With this in mind, I created different power ups that would not only could be found during gameplay, but it could also be purchase on the store or at the beginning of each round. This power ups would give players an advantage and would help them complete their achievements and travel further in the game to get a higher score. Of course, they could also be bought with in-game currency as it would not be fair to only give this content to players how invested in the game.

The second type of our in-app purchase would be static changes If I had enough time I would have like to create changes for the entire ecosystem of the game, from different skies, backgrounds, and small changes in the environment to even some changes on the enemies appearance. To make sure I could complete this work on time, I decided to constrain this changes to only new character skins, as it has proved to be a feature that players enjoy to collect and improve their experience with the game when they can choose their favourite appearance. In total, I made 19 very unique skins.

The other side of our monetization was the used of ads, of course, we wanted to produce as many ads impressions as possible, but at the same time, we needed to find a way to show the ads without interfering with their experience. I designed two different ways in which we could show ads multiple times a day to each player, but only showing them after the player requested it, this means that we would not be forcing players to watch the add, instead we would change their mindset to think that they wanted to watch the add, as every add they watch give them a high reward or incentive.

I created a “mini-game”, a  wheel of fortune, that players could play after they die by watching an ad, the wheel of fortune would randomly give them in-game currency, premium currency or an extra life to revive and continue from where they had died so that they could get a higher score.

I also made a “time reward” feature that would allow players to receive snacks after they unlock it by watching an add, this feature had two purposes, it would give allow us to show ads to players while giving them a rewards but it would also help us make players go back to play the game every 6 hours.

Tha main changes that I had to make were related to the performance of the app. It was critical for us to make sure that our app could be run on any type od Android device, from low-end to high-end devices. So anything that would improve the performance had to be done. The first change was the animation files. Initially, I used the default files from the software that I use to make my animations, it made the integration with Unity very easy and the animations were very smooth, but we had issues in the way the animations were running and Eli’s object pooling system. I had to modify all my animations so that they would not impact our performance, I could have to export them as sprite sheets, but these would have increased our build size exponentially, and it would also mean that the animations it would only be smooth if the game was running at a high frame rate. Instead, I converted all my animations to FBX, so that they could be used with Unity’s animation system, this improved our performance with only a very small reduction in the quality of the animations.

The other feature I had to redesign multiple times to increase the performance of our game was our social media sharing method. On the first iterations I was allowing players to share a video of their entire playthrough but the performance impact was making the game impossible to play, then I changed my system to make allow players to share a gif of their playthrough this time the frame rate drop wasn’t as high as with the first system, but it was still unacceptable. On my last iteration, I allowed players to share a screenshot of the moment they died along with their high score and their score of the correspondent game session. This was an ideal option for us as it didn’t have any effect on our frame rate and would still allow us to let players share their experience of the game in social media.


Every iteration and change of our design were meant to be in the change log of our Game Design Document, and sadly this was never finished. Because of the amount of work that I was already doing for the project, I decided to assign this task to the other Designer of my game as he had a lot fewer tasks assigned, but he never did it.


Procedural Content Generation on Endless Runner

The procedural generation on Steel Seal was a good attempt done by our programmer; it allowed us to have certain control over the type of enemies and the amount depending on the difficulty that was being set according to the distance that the player has travelled. The main reason why I wanted to make a game that had procedural level generation is that it would allow us to spend more time polishing our mechanics and aesthetics of the game to produce an overall higher quality. A procedural level generation system is a lot more complex than simply placing a level, it requires a great amount of time to create and set up initially, but it pays off in the long term because once the system is established you can leave the rest of the work to the algorithm, producing a large amount of variety in your level faster than is humanly possible.

Having said that my idea of level generation is far from what we had, what I was expecting to have to my disposal required a lot more control, I do not think that completely or almost completely randomness produce a good result, it is a lazy way of designing a game.

Total randomness leads to frustrating or non-solvable situations, time frames with too many enemies making it impossible to dodge or too many coins spread around the level that has no purpose if they can’t be picked up, or on the other side of the coin you may get sections where nothing happens on the screen, and you leave players in an empty void for a few seconds. You have no control over the difficulty, no control over the design and no control player’s experience.

It is important to have a balance between procedurally generated content and handcrafted design or authored content. By combining these two elements you can ensure that each section of your level is possible to be complete or conquered, it is interesting, and it has an appropriate level of challenge for the current difficulty.

For the authored content, designers should handcraft a large number of sections or templates for the game, think about them as a mini level design. By doing this, designers can make sure to produce good content with a lot of variety, balance and fair difficulty, that engage players. Of course, it is important to create enough variations and content so that players are not able or at least takes them a lot of time to see the patterns, as you want each playthrough to feel like a unique experience to your players.

What I mean with avoiding players to see the patterns, I am only talking about the layout of the levels; you want that so that they focus on mastering their mechanics and abilities, the use of power-ups. They learn how to read the behaviour of the environment and the unique properties of each enemy so that they can adapt and react predicting to each unique situation. If you manage to get this, you will dramatically increase the replayability of your game.

A perfect way to describe this balance between procedural generation and authored content is what you can see in games like Spelunky, Jetpack Joyride, Bananakong, etc.
Each one of these games have different systems but share the same core concept idea in their level generation, the designers produce a large amount of content that is introduced in the game randomly but following a list of rules and intervals between a minimum and maximum range

I believe that if we had implemented this system, our game would have been a lot better and would have retained many more users. Simple things as having control over the combination of enemies, the offset in between them and platforms, and creating patterns with our snacks would have allowed us to control better the flow and movement of the player.

For example imagine if we could design patterns for the snacks, this way we would influence the player in moving the way we want, while we teach them how to play the game by using both parts of the screen, we guide them to a safe location over an ice platform, and we make them feel like they achieved something every time they successfully pick up all the snacks in the pattern. You can’t expect this control with complete randomness, this is something we designers have to produce.


Use of Analytics and Data Collection

The use of analytics and data collection on video games is one of the biggest tools we can use to learn from our audience, it helps us understand the characteristics and behaviours of people who play our game, it also helps us learn more from our own design as we can use that information to see what is being successful in the game or what players don’t like. By having access to this information we can not only improve our design, polish our games and introduce or remove features as required; we can also improve our marketing strategies more effectively, this is why there are companies that pay incredibly high amounts of money for users data.

It one that the implication of this data sometimes is handled and use in an unethical matter. A great example of this is a case of a company that designed an algorithm that predicted and targeted pregnancy. “If we wanted to figure out if a customer is pregnant, even if she didn’t want us to know, can you do that? ”. A famously known case of the use of this algorithm is the time that the retail company Target used the data to deduce that a 15-year-old girl from Minnesota was expecting a baby. So they started sending her coupons for baby-related items, and it wasn’t until them that her family found out about her pregnancy.

Image result for ethical analytics

There is a fine line between what’s acceptable and not. Nowadays most people have become comfortable with putting their personal information on public sites like social media such as Facebook, Instagram and Twitter, but when a company manipulates that data is when people complains. For example, something that many have caught on, including myself are occasions where I buy something online or even in person at a retail shop and almost immediately we start getting email ads about related products, including the banner ads from your browser start showing products related. Some people may not care, but many would agree that it is creepy to see how we are constantly under surveillance. The problem is that many companies can get away with that because the law has many grey areas big data collection and it will remain this way as wee keep agreeing to terms and conditions without actually reading them.

Knowing all this, the ethical way of using your player’s data should only be for improving your product and their experience; you must always request for their permission the same way that you ask them if you can give them phone notifications that are required by a feature in your game. The good news is that this is automatically done by Google Play Services plugins and Unity Plugins when you use them, as they prompt the players asking for permission when they first install the app, but you always should make sure that this function is happening.

To be able to use your data and analytics accurately and effectively you would require gathering information of many users for an extensive amount of time; sadly Steel Seal doesn’t count with such volume of data. I have used the Google Play Console and the Unity Developer Analytics Cloud to gather this information.

From my Google Play dashboard,  I can see that every time our app has been installed by 50 users, 46 are from Australia, one from Belgium, one from the United Kingdom, one from New Zealand and 1 from Russia. From those installs, there are currently 35 still active on their devices leaving us with 15 that deleted our app. This means that analysed we have had a 70% retention of users that install our app. It also shows that there were 21 users how visited or Google Play store but didn’t install the app; this means that they either didn’t lake what they saw or it didn’t grab their attention; this could have happened because we didn’t have a video that shown a play through of the game. We could not get more information about the demographics of or users because the system required more data to calculate the analytics.

From my Unity Developer Analytics Cloud, the data seems to be more detailed, it shows that we have had a total of 116 users, which differs from the 50 users described by Google Play Analytics, the reason is that 50 users have installed the app in 50 devices but those devices have multiple email accounts, each one of them is being looked at as a separate user. For example, I have 4 different emails connected to my mobile, every time I changed my email on Google Play the game would prompt me to create a new user and would track my scores and achievements as a new user.

Another very useful section from Unity’s Analytics is the segment builder, it shows the life cycle profile of users int different days sections since joining the app, the demographic of those users, the amount of users that have purchased products, the  segmentation by gender, the platform in case of having a game for both Android and IOS, and more.

If we had a larger audience, we could have analysed this data more effectively, and design updates in response to what users seem to enjoy, or modify ou time reward feature depending on the hours that most users tend to connect. Three things that we can clearly deduce from all this is that  the game needs to get more exposure, we should do more marketing and try to gather more new users constantly, the game doesn’t have a short retention but players are not playing the game so often, and there is no use for us to have our game installed in devices but are never being played, and lastly the game have only sold one product (Greg bought our cheapest product to test our in-app purchase), this means that players don’t see real value in the products we are selling. Before changing the prices we first need to make sure that players can see the value in what it’s being sold otherwise no matter how much you drop the prices, people will more likely not buy it.



Ethics, Social and Economics Implication of Monetization

Because we made a game that is free to play it means that anyone that can access Google Play can have access to our game, no matter their age, race or religion. In terms of race and religion, you should always make sure to avoid making fun or offending people as simple as that, in the same way, that wee need to think through our daily life, it is important to be aware that what may not be offensive to you it could be to others, and we always should look for ways to respect each other our beliefs, ideas and opinions.

Now here I would like to focus on age factor of our players. On the one hand, developers that create free to play games that use ads as their main source of income will tell you that kids are their best clients as they have more time available to play games and don’t mind watching ads as long as they get a reward, of course, this would not be a problem if you make sure to notify both your publishing store in our case Google Play but mainly to the producers of the ads that are being shown in your game which in our case is Unity Ads, that you are aiming your game at children of 13 years of age or less, by doing this Unity ads will filter the type of ads they can show in your game, removing anything with extreme violence, blood, gore or any adult content.

Image result for coppa apps for children
One of the main things you need to have in mind if you develop and app directed to children under 13 years of age and collect their personal information you will fall under the COPPA rules, and for those of you how many not know COPPA stands for “Children’s Online Privacy Protection Act”. It is a law to protect the privacy of children under 13,  and it was created in 1998 by the U.S. Congress.

If you do fall under the COPPA rules, you have to make sure to comply with them by doing the following:

1) Post a clear and comprehensive online privacy policy, describing your practices for personal information collected from the children.

2) Provide direct notice to parents and obtain verifiable parental control.

3) Give parents the choice of consenting the studio to collect the information but prohibiting the disclosure of that information to any third party.

4) Provide parents access to all the information collected to from their children and allow them to review it and delete it if they want to.

5) Give parents the option of preventing further use or collection of their child’s personal information.

6) Maintain the confidentiality, security and integrity of all the information collected from the children.

7) Retain the personal information collected only for as long as it is necessary to fulfil the purpose for which it was collected and then delete it.

After some research, I realised that the App store follow have more extensive and detailed guidelines regarding their privacy policy on apps directed to children under 13, and these are their policies for those cases:

24.2 Apps primarily intended for use by kids under 13 may not include behavioural advertising (e.g. the advertiser may not serve ads based on the user’s activity within the App), and any contextual ads presented in the App must be appropriate for kids.
24.3 Apps primarily intended for use by kids under 13 must get parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce.
24.4 Apps in the Kids Category must be made specifically for kids ages 5 and under, ages 6‐8, or ages 9‐11.

In the second policy, they mention the term “parental gate”, this is something that has become very common on websites and mobile games, it is a technique to confirm the age of the children, for example:

On the other hand, Google Play doesn’t have many rules for this matter, they only reference COPPA in their terms of service policy:

Age Restrictions. In order to use Google Play you must be 13 years of age or older. If you are between 13 and 18 years of age, you must have your parent or legal guardian’s permission to use Google Play. You must not access Google Play or accept these Terms if you are a person who is either barred or otherwise legally prohibited from receiving or using the Service or any Products under the laws of the country in which you are resident or from which you access or use Google Play.

Now let’s talk about money, another important thing to have in mind with free to play games aimed at children is the ability to purchase digital content in your game with real money. There have been many reports of parents complaining about surprise charges to their credit cards from their children spending money on the App Store or Google Play, and of course, the first reaction of many is to blame someone else, the problem mainly relies in that most people don’t read the terms and conditions anymore, not for the device, not for the selling platform and not for the games itself.

From their part, parents should make sure to educate their children, surprise right? They should also make sure that their children don’t have access to their credit cards. But ok, here we need to discuss the blame that relies on developers, and what is the right thing to do from our end. I think that even if your game is only released on Google Play you should consider using a “Parental Gate”, every time they want to buy a product you should test them to see that they are not little children, I know this alloying from a user perspective, but we should make them fill out the credit care and all the details when they want to make a new purchase, I know this may be annoying but at least it will make the process more difficult to children.

I came across a company called Itavio, this company offers a solution with and SDK, the idea is that by using their services you can monetize your audience more effectively with permission already established by the parents. When you integrate the app, you get featured and promoted around their community of parents. With this service, parents can give their kids an allowance for your game giving them permission to play and pay.

Image result for itavio

Steel Seal In-Depth Marketing Report

When developing our marketing report I  was able to understand that this had to be separated into two sections, a Marketing Strategy and a Marketing Plan,  it is very common for people to confuse the difference between them as they are both processes that need to work together for the success of a project.

A Marketing Strategy is shaped by your business goals, it explains what has to be done in order to achieve those goals. For example for our project, the majority of our project strategy was pre-established  by the brief requirements, the fact that it had to be a freemium game that had to be to commercial standards and released to Google Play was our ground base for our Marketing Strategy, on top of that each project started being shape towards a different direction as we had a concrete design with a a specific genre, and art style, and finally when we decided out target audience and developed our personas. Every each one of these parts of the development process changes your marketing strategy. For example for our game in particular it was extremely important to have social sharing features as it was shown in our research that it was a characteristic that our audience enjoy in the games they play. Another great example would be our decision in the way we spread across our Time Reward mechanic and the prices of all of our in-app purchase products.

So sum up a Marketing plan consist of things like:

-Your target audience.

-Your business model. Is it premium or freemium?

-Your platform or store.

-The geography. Where is this game being launched?

-Your marketing channels. Where are you going to promote your game? According to you target audience how important is it for you that your game is shown in social media?

On the other hand we have the Marketing Plan, which is essentially the HOW do you execute your Marketing Strategy and reach your goals?, what things you need to do to get there? What is your plan to complete your Marketing Strategy?

After understanding our target audience and analyzing our personas there were many things we were supposed to prioritize to improve the chances of success of our game. As we progressed on through our development I created an eleven pages long Marketing Plan that was distributed among all the other groups, because of it’s level of detail. I researched the requirements for promoting our game in all the platforms and media that my research showed that would be suitable to our game. I also prepared the descriptions an information that would have to be posted on this platforms so that we had them available and ready to use in the moment we needed them.

For Example I created our entire description for Google Play, including a short description of 80 characters, a full game description of 800 characters with a list of features, a “how to play?” section and a disclosure notice for the parents to let them know that our game had the ability of purchasing optional content using real money, that they would have access to features that would link them to external social network sites, that they would see ads from other games and finally that they would be able to see user-generated player names on our leader boards.

I had also had completely fill out a presskit of our game so that we could contact game writers if we had the chance, and lastly I designed and edited images to the standard of Google Play and Presskit, sadly most of this data wasn’t really used because of lack of time.


Monetization, Ads Implementation and Sharing to Social Media Methods

Image result for freemium game southpark
After a lot of research, we came to the conclusion that the top grossing mobile games in the market have a free to play model, which means that are games that offer the majority of their content for free and obtain revenue by using Ads and In-app purchase where people can extend the content of the game, play more times or speed up their improvement in the game by using power ups or something that would allow them to get further and go up in a leaderboard.

Image result for mobile game southpark

Another great advantage of freemium games is that it save developers from worrying about people that paid the money to buy your game and end up un satisfy, freemium games with in-app purchase usually extend the content that players have available wich means that they already know what to expect before they pay. The structure of freemium games have been re-used for many years, players usually understand the system and knows what to expect, the main challenge for game developers have been how to make in app purchase more appealing to wider audiences and how and when to use Ads in your game without being intrusive interfering too much with the player’s experience .

Image result for free to play games southpark

Free mobile games must be rich in content, they need to target a wide audience and have a lot of replayability to survive, these games need to make sure to grab as much attention as possible as only a really small percentage, less than 5% of players would ever purchase anything from your game, which is why showing Ads to players is so popular, as you get money from players watching your ads and then installing the games from your ads, which means that they had no need to put money out of their pocket, but again the earnings from a single install is incredibly small and many players even skip the ads.

This means that for both methods of income, numbers of players are extremely important. The dream of every developer is that their games become viral to have great success. This will likely not happen unless you game have ways for players to socialise,  allowing players to share their experience with the game adds and an extra layer of complexity to the formula, it makes the experience more personal, increase replayability, and give you free marketings, as players share your game for you.

Image result for free to play games southpark

Our in-app purchase process was very simple, we model our system from many popular freemium games on today’s market. We have an in-game currency or soft currency which we call snacks and a premium currency or hard currency which we call pearls. Players can game a lot of snacks by playing the game and watching ads, but this currency has a lot less value than the hard currency, which you can only get in a small percentage by watching ads, or you can pay real money for it. Both currencies allow you to purchase multiple skins and power-ups in the game, something that we are missing in Steel Seal that is typical of freemium games is the ability to exchange hard currency for soft currency (Which I requested to my programmer when he was creating the shop, but he didn’t do because he didn’t understand the system as he doesn’t usually play mobile games).

Image result for free to play games southpark
We had to different rewards for watching Ads, the first was by giving players the chance of using our “Wheel Reward” which had a random chance with multiple probabilities of getting different values of soft currency, a small value of hard currency or to revive your character in the previous position, allowing them to get further in the game for a chance to increase their high score which is set to track the furthers distance travelled and that can be compared with your friends and people from around the world how play your game by using Google Play Leaderboard system. The other method of watching ads is used to unlock a Time Reward that notifies players to their phone when it is available every 6 hours, this method is used to not only reward our players for playing our game but as a way to pull them into playing the game again every 6 hours.

As I mentioned before this freemium system relies on the amount of players playing your game and because of that, I added a variety of methods that players could socialise with our game. The first two methods are the most simple ones, by adding two buttons to the main menu that hey could use to like us and follow us on Facebook and another one they could use to give us a ranking in Google Play, these buttons simply redirect player to the URLs of our game’s online presence. The second two methods was by creating Achievements and a Leaderboard that they could share with friends and compare with other people, these are part of Google Plays plugins, and not only helps with making players play your game more to beat their high score or complete all the achievements it creates competition between friends, that enhance the overall experience.

The last method which is also very important but many games often are missing, is the ability to share to social media and many other methods screenshots of your game, Initially I had planned to allow them to share video or gifs but because of performance issues with both of those cases I decided to use screenshots instead.


I was responsible for implementing all the social sharing methods and I designed the shop and in-app purchase system as well as our entire reward structure for watching ads, I am very proud of my work on these areas, as I learned so much after very extensive research while analyzing the reason behind this structures in the player’s psychology and how it is used in the most successful mobile games. Being aware of some kids that could that could potentially play our games and after researching the ethical implications of In-app purchase systems and social sharing withing mobile games I added the following statement to our Google Play’s description, as my research showed me how many successful games do to advise parents about the presence of these systems in their games before they get installed:


This game may contain:

– The ability to purchase optional content using real money.
– Promotional material for other games.
– Links to external social networking sites intended for users over the age of 13.
– The ability to see user-generated player names and social leagues.