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.